TLS HANDSHAKE DOSSIER / CERTIFICATE OBSERVATION LEDGER
Record the certificate data exposed by one TLS handshake
Enter a host or URL-like string. The editor extracts its hostname; the server applies its public-target boundary, then records certificate and negotiated-connection fields from one HTTPS HEAD request on port 443.
- Host extracted in the editor
- HTTPS HEAD · port 443 · SNI
- 8-second request timeout
Certificate observation ledger
HOST OR URL-LIKE STRING
EDITOR → URL HOSTNAME EXTRACTION
SERVER → assertPublicHttpUrl(https://${domain})
HTTPS HEAD :443 → SNI servername = PUBLIC HOST
CERTIFICATE + NEGOTIATED TLS FIELDS
Local and private targets are excluded before the request. A public-looking input is not a statement that a connection will be permitted, established, or answered.
One input, one bounded handshake observation
The route documents the implemented request path rather than a general website examination. It does not follow redirects and does not inspect page content.
1. Extract the hostname
The editor accepts a host or URL-like string. It first tries URL parsing and sends the extracted hostname; when that parsing fails, its fallback only cleans the entered string before the request.
2. Apply the public-target boundary
The server calls assertPublicHttpUrl with https://${domain}. Local and private network destinations are excluded. This boundary does not say that every public host is allowed or reachable.
3. Send one HTTPS HEAD request
The server requests HEAD on port 443, uses the submitted public hostname as SNI servername, and applies an 8-second timeout. rejectUnauthorized is false so certificate data can still be read when the chain is not authorized. Redirects are not followed.
Returned-field matrix
The ledger renders fields emitted by the server for the observed connection. Values describe that request and its peer certificate; absent or failed requests do not become broader diagnoses.
- domain — Submitted domain
The domain value returned in the result.
- issuer — Issuer
The certificate issuer organisation or common name when supplied.
- validFrom · validTo · daysRemaining — Validity dates
Certificate validity dates and the computed whole days remaining.
- protocol — Negotiated protocol
The protocol reported by the connected TLS socket.
- cipher — Cipher
The cipher name reported by that socket.
- keyStrength — Certificate key bits
The certificate bits field, or 0 when it is unavailable.
- certificateChain · warnings · valid — Chain, notices, and valid
Each chain row has subject, issuer, and validity dates. The result also supplies valid and generated warning text.
Read result and status context narrowly
The editor shows the returned result or one status message. Those states describe this request path, not general host availability or a page diagnosis.
Returned observation
When a response exposes a peer certificate, the ledger can render the returned fields, chain rows, score, rating, and notices.
No peer certificate
The server can report that no certificate was found; its message notes that TLS may not be enabled or the domain may be unreachable.
Connection status
Name resolution, refused connection, timeout, certificate, and other request errors are shown as request status context. A timeout is set at 8 seconds.
How the 0–100 heuristic is assembled
The server’s calculateSecurityScore function starts at 0 and uses only the following limited inputs. Ratings are excellent at 90+, good at 70+, fair at 50+, and poor below 50.
- valid — 30
Adds 30 only when the time window contains now and the socket is authorized.
- daysRemaining — 20 / 15 / 5 / 0
More than 90, more than 30, more than 0, or expired; notice text changes with the band.
- protocol — 25 / 20 / 10 / 0
Matches TLSv1.3, TLSv1.2, older TLS strings, or another value.
- keyStrength — 25 / 20 / 10 / 0
Uses the 4096, 2048, and 1024 bit thresholds.
- cipher — 0 or −10
AES-GCM adds no points, AES can add a notice, and names containing 3DES or RC4 subtract 10.
This bounded heuristic is not a safety promise, compliance review, vulnerability check, trust decision, certificate certification, or assessment of the overall configuration.
Scope of this certificate ledger
The page records an implemented TLS request and its returned fields. It is deliberately narrower than a website, redirect, availability, or configuration examination.
- No redirect following
- No webpage-content inspection
- No general reachability conclusion
- No compliance or vulnerability review
Continue with adjacent network and webmaster tools
These tools answer separate questions through their own request paths and returned data.
- DNS Lookup
Read records returned by the configured resolver path.
- Ping Test
Record browser HTTP request timing context for a public target.
- What Is My IP
View address information returned to this browser by its lookup path.
Questions about this TLS observation
Does the checker accept any public host?
No such conclusion follows from the public-target boundary. Local and private targets are excluded before the request; a public-looking input can still fail validation, connection, or response.
Why can certificate data appear when valid is false?
The request uses rejectUnauthorized: false so the peer certificate can be read even when the socket is not authorized. The valid field still depends on the certificate time window and socket authorization.
Does the checker follow redirects or examine a website?
No. It makes one HTTPS HEAD request to port 443 and does not follow redirects or inspect page content.
What does an excellent, good, fair, or poor rating establish?
Only the limited score bands in calculateSecurityScore. The rating is not a conclusion about compliance, vulnerabilities, trust, certification, or the overall TLS configuration.