Reading an SSL Certificate, Field by Field

An SSL certificate, more accurately a TLS certificate today, does two separate jobs. First, it lets your browser encrypt the connection so nobody sitting between you and the server can read the traffic. Second, and just as important, it lets your browser confirm that the server on the other end really is the one it claims to be. Encryption alone does not prove identity, which is why a certificate is issued by a certificate authority that has verified, to varying degrees, who actually controls the domain.

• Common name: historically the primary domain the certificate covers, though modern browsers rely on the SAN list below rather than this field alone.
• Subject alternative names (SANs): the full list of domains and subdomains this one certificate is valid for. A certificate for example.com with a SAN of *.example.com covers every subdomain too.
• Issuer: the certificate authority that verified the domain and signed the certificate, such as Let's Encrypt or DigiCert.
• Valid from and valid until: the window during which the certificate is considered current. Certificates outside this window are rejected regardless of anything else being correct.
• Chain status: whether the certificate can be traced back to a root certificate that browsers already trust.

Frabs' SSL Checker lays these fields out directly rather than making you dig through your browser's certificate viewer, along with the number of days remaining before expiry so a renewal deadline does not sneak up on you.

Certificates differ in how much the issuer actually verified before signing. A domain validated certificate only confirms that whoever requested it controls the domain, which is enough for encryption and is what the vast majority of websites use today, including ones issued automatically and for free. An organization validated certificate additionally confirms the requesting company is a real registered business. Extended validation goes further still with manual checks, though modern browsers no longer display this distinction as prominently in the address bar as they once did. None of these levels change how strong the encryption itself is, only how much identity checking happened before issuance.

Your browser does not maintain a personal list of every trustworthy website. Instead it trusts a small set of root certificate authorities, and each of those roots signs intermediate certificates, which in turn sign the actual certificate your site presents. Your server needs to present the full chain, its own certificate plus any intermediates, so a visiting browser can follow the links all the way back to a root it already trusts. A server that only sends its own certificate without the intermediate will often work in some browsers that cache the missing link elsewhere, while failing in others, which is a common and confusing source of it works for me reports.

A certificate that is signed by itself rather than by any recognised authority will encrypt traffic perfectly well, but no browser will trust it automatically, because there is no chain leading back to anything the browser already trusts. These are common on internal tools and development servers, where the person setting things up controls both ends of the connection and can accept the warning themselves. They are not appropriate for a public facing website, since every visitor would be shown a security warning before being allowed through.

Run your domain through the SSL Checker, and read the result against the fields above. Confirm the SAN list actually covers the hostname visitors use, that the chain status shows as trusted rather than unknown, and that the days remaining figure gives you enough runway to renew before anything expires unattended.