What Actually Happens in the 200 Milliseconds Before the HTTPS Padlock Appears
The lock icon appears in under two hundred milliseconds. Before it does, several hundred lines of cryptographic protocol have already executed. A negotiation has happened, identities have been verified, keys have been exchanged, and both sides of the connection have committed to a shared encryption scheme that neither has ever used with the other before. None of this is visible. The padlock is the only signal you get.
Most people know that the padlock means the connection is encrypted. Far fewer know what the chain of steps actually is, what the certificate in that chain says, or what causes the padlock to disappear and be replaced with a browser warning. Understanding those steps changes how you interpret SSL certificate information -- and why the details that an SSL checker surfaces are worth reading.
Step One: The Client Sends a Hello
When your browser connects to an HTTPS website, the first thing it sends is a ClientHello message. This message contains three categories of information: the highest TLS version the browser supports, a list of cryptographic cipher suites the browser can use (ordered by preference), and a randomly generated string of bytes called the client random.
In TLS 1.3, which is now the current standard and what most modern connections use, the browser goes further: it also sends a key share, a precomputed public value for the key agreement protocol it is guessing the server will select. This is an optimization that reduces the handshake to a single round trip. The browser is, in effect, betting on which cipher suite the server will choose and sending the corresponding key material upfront, rather than waiting to find out.
Step Two: The Server Responds and Presents Its Certificate
The server replies with a ServerHello message that confirms which cipher suite was selected, provides its own random byte string (the server random), and sends a ServerCertificate message containing the server's X.509 certificate.
That certificate is not just a proof of identity. It is a structured document containing a specific set of fields: the Subject (who the certificate is issued to, expressed as a domain name or set of domain names), the Issuer (which Certificate Authority signed the certificate), the Validity Period (Not Before and Not After dates defining the window during which the certificate is valid), the Subject Public Key Info (the server's public key, typically RSA-2048 or EC P-256), and a list of Subject Alternative Names (SANs), which are all the domain names the certificate is valid for.
That last field matters more than most people realize. Since 2017, when Google Chrome 58 stopped checking the Common Name field for domain validation, the SAN extension is the only field browsers use to verify that the certificate covers the domain they are connecting to. A certificate with a correct Common Name but missing SAN entries will fail validation in every modern browser.
The server also sends the certificate's full chain, including the intermediate Certificate Authority certificate that sits between the server's certificate and the root CA that your browser trusts.
Step Three: Validating the Chain of Trust
The browser does not simply accept the server's certificate at face value. It performs a validation procedure called chain-of-trust verification.
The browser checks whether the server's certificate was signed by a Certificate Authority it recognizes. But root CAs -- the authorities at the top of the hierarchy -- do not issue certificates to websites directly. Root CA private keys are kept offline, typically in hardware security modules in physically secured facilities, and are used as rarely as possible. Instead, root CAs sign intermediate CA certificates, and intermediate CAs sign end-entity certificates like the one your web server presents.
So the browser walks the chain: it verifies that the server certificate was signed by the intermediate CA listed in the certificate's Issuer field, then verifies that the intermediate CA certificate was signed by a root CA that exists in the browser's built-in trust store. If any link in that chain is missing, unsigned, or signed by an entity the browser does not trust, validation fails and the connection is blocked.
This three-tier hierarchy -- root CA, intermediate CA, end-entity certificate -- exists for a practical security reason. If a root CA were compromised, every certificate it had ever issued would be compromised, and revoking trust in that root CA would break a significant fraction of the web. The intermediate layer limits blast radius: if an intermediate CA is compromised, only certificates issued by that intermediate need to be revoked, and a new intermediate can be quickly issued from the root.
Step Four: Key Exchange and the Beginning of Encryption
Once the browser has verified the certificate chain, the cryptographic key exchange completes. In TLS 1.3, this uses an ephemeral Diffie-Hellman key exchange: both sides use the key shares they have already sent and received to derive a shared secret without that secret ever being transmitted over the network. The shared secret is the input to a key derivation function that produces the actual encryption keys for the session.
This ephemeral approach has a property called forward secrecy: even if the server's private key is stolen in the future, it cannot be used to decrypt past sessions, because the session keys were derived from ephemeral values that no longer exist. TLS 1.2 supported ephemeral key exchange but allowed non-ephemeral configurations. TLS 1.3 mandates it for all connections, eliminating the category of configurations that lacked forward secrecy.
The Finished messages that close the handshake are the first data encrypted with the new session keys. They contain a cryptographic proof that everything preceding them was received and processed correctly. If either side's Finished message does not verify, the handshake fails.
What an SSL Checker Is Actually Reading
After this entire procedure, what ends up visible to any external observer is the certificate itself -- the Subject, Issuer, validity dates, SANs, key type, and chain. An SSL checker connects to your server the same way a browser would, performs enough of the handshake to receive the certificate and chain, and then reads those fields.
Expiry dates need to be monitored because an expired certificate causes immediate connection failure -- modern browsers do not offer a continue anyway option for expired certificates. A certificate that expires and is not renewed takes a website offline for HTTPS connections until it is replaced.
Chain completeness is another practical concern. If a server is configured to present only its end-entity certificate without the intermediate CA certificates, some clients will fail to validate the chain even though the root CA is in their trust store. The browser needs the full chain to walk from the server certificate to a trusted root.
The SAN list determines which domains the certificate covers. A certificate issued for example.com may or may not cover www.example.com or subdomain.example.com. Connecting to a hostname not listed in the SAN field produces a name mismatch error, which looks to users identical to a not-trusted error, even though the underlying cause is different.
What a padlock tells you is that a certificate was present and a chain of trust validated. What it does not tell you is whether the certificate covers all the domains you expect, when it expires, which CA signed it, or whether the cipher suite negotiated provides forward secrecy. Those details are what the SSL checker surfaces.
Conclusion
ToolHQ's SSL Checker reads the full certificate and chain for any domain, returning validity dates, issuer, SAN coverage, and protocol details -- the information that the padlock icon doesn't show you.
Frequently Asked Questions
What is a Subject Alternative Name (SAN) in an SSL certificate?
An extension that lists all domain names the certificate is valid for. Since Chrome 58 in 2017, browsers only check the SAN field -- not the Common Name -- when validating which domains a certificate covers.
What is forward secrecy and why does it matter?
A property of TLS connections where session keys are derived from ephemeral values that are discarded after the session. Even if the server's long-term private key is later compromised, past sessions encrypted with those ephemeral keys cannot be decrypted.
Why do SSL certificates have a chain of three levels?
To limit damage from compromise. Root CA private keys are kept offline and rarely used. Intermediate CAs do the day-to-day certificate signing. If an intermediate is compromised, only its issued certificates need revocation -- not all certificates from the root.
What happens when an SSL certificate expires?
Browsers block the connection immediately with an error screen. Unlike outdated cipher warnings, expired certificate errors give no option to proceed. The site becomes unreachable over HTTPS until a new certificate is issued and installed.