You manage websites – maybe a handful, maybe dozens – and you know SSL certificates matter. But when you actually open a certificate’s details in your browser or on the command line, the wall of fields, dates, and cryptographic strings can feel overwhelming. Understanding what each field means is the difference between catching a misconfiguration early and scrambling to fix it after users start seeing warnings. This guide breaks down every important SSL certificate detail so you can read them with confidence.
Where to Find Your SSL Certificate Details
The quickest way is your browser. In Chrome, click the padlock icon in the address bar, then “Connection is secure,” then “Certificate is valid.” Firefox and Edge have similar flows. You’ll see a structured view with tabs for General, Details, and the certification path.
For a more complete picture, the command line is your friend. Running openssl s_client -connect yourdomain.com:443 followed by openssl x509 -text -noout dumps every field in plain text. This is the approach most sysadmins prefer because it shows exactly what the server is presenting – no browser interpretation layer in between.
The Key Fields and What They Mean
Let’s walk through the fields you’ll actually encounter, in the order they typically appear.
Subject (Common Name / CN). This is the domain the certificate was issued for. On older certificates you’ll see a CN like www.example.com. Modern certificates rely more on Subject Alternative Names (SANs), but the CN is still present. If this doesn’t match the domain your visitors are accessing, browsers will throw an error immediately. One common mistake: issuing a certificate for example.com but forgetting www.example.com – or vice versa.
Subject Alternative Names (SANs). This extension lists every domain and subdomain the certificate covers. Wildcard certificates show entries like *.example.com. Always check that every domain you expect is listed here. A missing SAN is one of the most frequent causes of SSL certificate errors in multi-domain setups.
Issuer. This tells you which Certificate Authority (CA) signed the certificate. You’ll see the organization name and often an intermediate CA name. If the issuer looks unfamiliar or the chain doesn’t lead back to a trusted root, browsers won’t trust the certificate. This is directly tied to certificate chain correctness – a misconfigured intermediate is a surprisingly common issue.
Validity Period (Not Before / Not After). These two dates define when the certificate became active and when it expires. Most certificates today are valid for 90 days (Let’s Encrypt) or up to 398 days (commercial CAs). Keeping track of these dates across multiple domains is exactly the kind of task that becomes unmanageable without automated monitoring. For a deeper look at how validity periods work, see our guide on SSL certificate validity periods and expiration dates.
Serial Number. A unique identifier assigned by the CA. You’ll rarely need this day-to-day, but it becomes critical during revocation events – it’s how CAs and browsers identify exactly which certificate has been revoked.
Signature Algorithm. This shows the cryptographic algorithm used to sign the certificate. You want to see SHA-256 with RSA or ECDSA with SHA-256 here. If you ever see SHA-1, that certificate is obsolete and browsers will reject it.
Public Key. The key size and type matter. RSA 2048-bit is the current minimum standard. RSA 4096 offers more headroom. ECDSA P-256 keys are smaller but equally secure – and faster during TLS handshakes. This is worth understanding because it affects both security and TLS performance.
Extensions. Several extensions carry practical weight. Key Usage and Extended Key Usage define what the certificate is allowed to do – typically “Digital Signature” and “Server Authentication.” Authority Information Access (AIA) points to the OCSP responder and the issuer’s certificate URL, which browsers use for real-time revocation checks. Certificate Policies indicate the validation level – Domain Validation (DV), Organization Validation (OV), or Extended Validation (EV).
A Myth Worth Busting: EV Certificates Are “More Secure”
A persistent misconception is that Extended Validation certificates provide stronger encryption than Domain Validation certificates. They don’t. The encryption strength depends on the key size and the TLS configuration – not the validation level. EV simply means the CA verified the legal identity of the organization. The padlock looks the same. The handshake is the same. Major browsers have even removed the green address bar that once distinguished EV certificates. Choose your validation level based on trust signals you need for your audience, not on a belief that DV is somehow weaker cryptographically.
Reading Certificate Details in Practice: A Real Scenario
A few years back, a colleague noticed that one subdomain out of thirty was showing a certificate warning in staging. The certificate looked fine at first glance – valid dates, correct issuer. But when we checked the SANs, that specific subdomain simply wasn’t listed. The wildcard covered *.app.example.com, but the problematic host was api.internal.example.com – a different subdomain level. A wildcard only covers one level deep. That’s the kind of detail you catch by actually reading the SAN field instead of assuming the wildcard handles everything.
This is also why automated SSL monitoring matters. SSLVigil checks not just expiration but also chain integrity, HSTS headers, Certificate Transparency logs, and OCSP compliance – the kind of multi-layered verification that catches issues like a missing SAN or a broken intermediate before your users hit a browser warning.
FAQ
What does “Certificate chain is incomplete” mean?
It means your server is not sending the intermediate certificate(s) needed to link your SSL certificate back to a trusted root CA. Browsers may still work if they have the intermediate cached, but some clients – especially mobile browsers and API consumers – will fail. The fix is to configure your web server to serve the full chain.
How can I check if my certificate uses a strong enough key?
Run openssl x509 -text -noout on the certificate and look at the “Public Key” section. RSA keys should be at least 2048 bits. ECDSA P-256 or P-384 keys are also considered secure. Anything below RSA 2048 is outdated and will be rejected by modern browsers.
Does the certificate’s signature algorithm affect my site’s security?
Yes. SHA-1 signed certificates are considered broken and are no longer trusted by any major browser. Ensure your certificate uses SHA-256 or stronger. If you’re renewing through a modern CA, this should happen automatically – but it’s worth verifying, especially on legacy systems.
Wrapping Up
Reading SSL certificate details isn’t just a troubleshooting skill – it’s a preventive one. Knowing what the subject, SANs, issuer, validity dates, key type, and extensions actually mean lets you spot misconfigurations before they become incidents. Make it a habit to inspect certificates after every renewal, especially when managing multiple domains. And if you’d rather not do it manually across dozens of sites, that’s exactly the problem automated SSL monitoring with tools like SSLVigil solves – continuous checks, instant alerts, and monthly security grades delivered straight to your inbox.