Get a PEM from a live site: openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509
Subject Alternative Names
Full details
Fingerprints
——What a certificate actually proves
A TLS certificate is a signed statement saying "the entity controlling this public key is authorized to use this domain name". It contains: a public key, the domain(s) it's valid for (Common Name + Subject Alternative Names), the issuing Certificate Authority's signature, and a validity period. Browsers verify the signature chains up to a trusted root CA pre-installed on your device.
What it doesn't prove: that the site is run by good people, that your data is safe once it arrives, that the site does what it claims. It only proves that traffic between you and the certificate's named domain hasn't been read or modified in transit. "HTTPS" is a privacy-of-transport guarantee, not a quality-of-service one.
Reading the fields that matter
- Subject CN (Common Name) — the primary domain. Historically the only field that mattered; today browsers ignore CN entirely if SAN is present.
- Subject Alternative Names (SAN) — the list of domains this certificate covers. A modern certificate from Let's Encrypt commonly covers
example.com,www.example.com, and any wildcards. This is the authoritative list; CN is ignored. - Issuer — the CA that signed this cert. Let's Encrypt, DigiCert, Sectigo, etc. Browsers ship with a list of trusted root CAs; the chain has to lead back to one of these.
- Validity Period — Not Before / Not After. Most public certs are now max 13 months. Let's Encrypt is 90 days by default. Apple/CA Browser Forum aims to push the max down to 47 days in 2027.
- Key Algorithm — RSA-2048 is still common; ECDSA P-256 is more modern and produces 40% smaller signatures. Ed25519 isn't widely supported by CAs yet.
- Signature Algorithm — how the CA signed this cert. SHA-256 with RSA or ECDSA. SHA-1 was deprecated in 2017 and no modern browser trusts a SHA-1-signed cert.
Three types of validation — only one means anything anymore
- DV (Domain Validation) — the CA verified you control the domain (by requiring you to publish a token in DNS or at
/.well-known/...). The vast majority of certificates today. Let's Encrypt is DV. No visible UI difference in browsers. - OV (Organization Validation) — the CA also verified the organization name. Slightly more involved process. Increasingly rare; no UI difference from DV in modern browsers.
- EV (Extended Validation) — the CA performs in-depth verification. Used to show a green company name in the address bar (Chrome/Firefox/Safari). Browsers removed that UI in 2019-2020 because studies showed users couldn't tell the difference. EV still costs more but provides no UX advantage today.
Common issues to check
- Expiring soon. Less than 30 days = renew now. Less than 7 days = production fire drill. Automate renewal (Certbot, acme.sh, certmagic) — manual renewal cycles cause real outages every year.
- Wrong SAN list. Cert for
example.comonly doesn't coverwww.example.comorapi.example.com. Get a cert with all subdomains in the SAN, or use a wildcard*.example.com(covers one level only — notfoo.bar.example.com). - Self-signed in production. A self-signed cert (issuer = subject) is fine for internal services if your clients trust it, but never expose to the public internet. Browsers will reject it.
- Weak key (RSA-1024). Anything under 2048-bit RSA is considered weak. Modern CAs won't issue them, but legacy infrastructure sometimes still has them.
- Chain incomplete. Your cert is fine but the intermediate CA cert isn't served, so some clients can't verify the chain. Test with SSL Labs and ensure the full chain is in your
cert.pem, not just the leaf. - Hostname mismatch. Cert valid for
example.comserved onapi.example.com. Browser refuses connection. Re-issue with the correct SAN.
Common use cases
- Audit a certificate's expiry date before relying on it
- Verify a certificate covers the right Subject Alternative Names
- Inspect the issuer chain to confirm it leads to a trusted CA
- Compare two certificates by fingerprint
Frequently asked questions
How do I get the PEM from a live website?
Run <code>openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509</code> in a terminal. The output between <code>-----BEGIN CERTIFICATE-----</code> and <code>-----END CERTIFICATE-----</code> is the PEM. Alternatively, in browsers click the padlock icon → certificate details → export.
Why does my cert have a 90-day expiry?
Let's Encrypt issues 90-day certificates by design — short lifetimes force you to automate renewal, which catches problems early. The CA Browser Forum is moving the public-cert maximum down to 47 days by 2027, so automation is increasingly mandatory.
What's the difference between CN and SAN?
CN (Common Name) was the original "this cert is for this domain" field. SAN (Subject Alternative Name) replaced it. Modern browsers ignore CN entirely if SAN is present. Always rely on SAN for what the cert actually covers.
Is the certificate uploaded anywhere?
The PEM is sent to our server for parsing (X509 parsing in pure browser JS is heavyweight and slower). We don't log certificates. For private certs you don't want any third party to see, use <code>openssl x509 -text -noout -in cert.pem</code> locally instead.
My cert says "Issuer = Subject". What does that mean?
It's self-signed. The certificate signed itself, so no external CA validates it. Fine for internal services where you control both ends; never use for public-facing HTTPS — browsers will reject.