How to Check SSL Certificate Status and Expiry

SSL certificates are the foundation of encrypted communication on the web. Every HTTPS connection starts with a certificate handshake that verifies the server’s identity and establishes an encrypted channel. When a certificate expires, is misconfigured, or is missing entirely, browsers display prominent warnings that erode visitor trust and block access to your site.

Regularly checking your SSL certificates prevents unexpected outages. This guide explains what to look for, how certificate chains work, and how to use our SSL Certificate Checker to audit any domain’s security configuration.

What an SSL/TLS Certificate Contains

An X.509 certificate (the technical standard behind SSL/TLS) carries several pieces of information that browsers verify during the TLS handshake:

• Subject: The domain name or organization the certificate was issued to. The Common Name (CN) and Subject Alternative Names (SANs) define which domains the certificate covers.
• Issuer: The Certificate Authority (CA) that signed the certificate. Browsers maintain a list of trusted root CAs, and the certificate must chain back to one of them.
• Validity Period: The “Not Before” and “Not After” dates define when the certificate is valid. Certificates issued by Let’s Encrypt are valid for 90 days, while commercial CAs may issue certificates valid for 1-2 years.
• Public Key: The cryptographic key used during the TLS handshake. RSA 2048-bit and ECDSA P-256 are the most common key types in use today.
• Serial Number: A unique identifier assigned by the CA. Useful for tracking specific certificates across renewal cycles.
• Signature Algorithm: The hashing algorithm used to sign the certificate. SHA-256 is standard; SHA-1 is deprecated and flagged as insecure by all major browsers.

How Certificate Chains Work

A certificate chain (or chain of trust) connects your site’s certificate to a root CA that browsers trust. The chain typically has three links:

1. End-entity certificate: Issued to your domain. This is the certificate your server presents to visitors.
2. Intermediate certificate: Issued by the root CA to a subordinate CA that signs end-entity certificates. Most CAs use intermediates to protect their root key.
3. Root certificate: Pre-installed in operating systems and browsers. Approximately 150 root certificates are trusted by major platforms.

Your server must send the end-entity certificate and all intermediate certificates. Root certificates aren’t sent because they’re already trusted locally. If an intermediate is missing, some browsers may attempt to fetch it, but others will reject the connection outright.

Use the SSL Certificate Checker to verify that your certificate chain is complete and valid.

TLS 1.2 vs TLS 1.3

TLS 1.3, finalized in 2018, replaced TLS 1.2 as the recommended protocol version. The key differences:

• Handshake speed: TLS 1.3 completes the handshake in one round trip (1-RTT) compared to two for TLS 1.2. It also supports 0-RTT resumption for returning visitors, reducing latency further.
• Cipher suites: TLS 1.3 removed all legacy cipher suites. Only five AEAD cipher suites are supported, eliminating weak configurations that plagued TLS 1.2 deployments.
• Forward secrecy: TLS 1.3 mandates ephemeral key exchange (ECDHE or DHE), meaning past sessions can’t be decrypted even if the server’s private key is later compromised. TLS 1.2 allowed static RSA key exchange, which doesn’t provide forward secrecy.
• Removed features: Compression, renegotiation, and several extension types were removed to reduce attack surface.

All major browsers support TLS 1.3. If your server still negotiates TLS 1.2, upgrading to TLS 1.3 improves both security and page load performance.

Understanding HSTS

HTTP Strict Transport Security tells browsers to always use HTTPS when connecting to a domain. Without HSTS, a user typing “example.com” in the address bar sends an initial HTTP request before the server can redirect to HTTPS. During that unencrypted request, an attacker on the same network could intercept the connection.

HSTS is sent as a response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000: Browsers remember to use HTTPS for one year (31,536,000 seconds).
• includeSubDomains: Applies the policy to all subdomains, preventing HTTP connections to any subdomain.
• preload: Signals intent to be included in the HSTS preload list maintained by browsers. Once preloaded, the domain enforces HTTPS on the very first visit, before any headers are received.

After enabling HSTS, test it with our SSL Certificate Checker to verify the header is present and correctly configured.

Certificate Transparency Logs

Certificate Transparency (CT) is a public audit system where Certificate Authorities must log every certificate they issue. These logs are append-only and cryptographically verified, making it impossible to issue a certificate in secret. CT logs allow:

• Domain owners to detect unauthorized certificates issued for their domains.
• Security researchers to identify mis-issued certificates and hold CAs accountable.
• Browsers to require CT compliance, rejecting certificates not logged to multiple CT servers.

Google Chrome requires all certificates issued after April 2018 to be logged in at least two independent CT logs. Our SSL checker queries these logs to retrieve certificate metadata without needing direct server access.

Common SSL Errors and How to Fix Them

ERR_CERT_DATE_INVALID: The certificate has expired or is not yet valid. Renew the certificate and restart your web server. For Let’s Encrypt, run certbot renew and reload the server configuration.

ERR_CERT_COMMON_NAME_INVALID: The domain in the URL doesn’t match any name in the certificate’s SAN list. Reissue the certificate with all needed domain names included.

ERR_CERT_AUTHORITY_INVALID: The certificate chain is incomplete or the certificate was issued by an untrusted CA. Ensure your server sends all intermediate certificates.

NET_ERR_CERT_REVOKED: The certificate was revoked by the CA, usually because the private key was compromised. Obtain a new certificate with a new key pair.

Mixed content warnings: The page loads over HTTPS but references HTTP resources. Update all resource URLs to use HTTPS or protocol-relative paths.

Frequently Asked Questions

How do I know if my SSL certificate is about to expire?

Check the “Valid To” date in your certificate details. Most monitoring tools and our SSL Certificate Checker show the exact number of days remaining. Best practice is to set automated alerts at 30, 14, and 7 days before expiry. If you use a hosting provider with managed SSL, they typically handle renewal automatically, but verifying the process works correctly after initial setup prevents surprises.

What happens when an SSL certificate expires?

Browsers display a full-page security warning (such as “Your connection is not private” in Chrome) that visitors must actively bypass to reach your site. Most users will leave rather than click through the warning. Search engines may also drop the page from results or flag it as unsafe. Expired certificates don’t immediately compromise encryption if the connection was already established, but new connections will fail or require manual override, making the site effectively inaccessible for normal visitors.

Is TLS 1.3 backward compatible with TLS 1.2?

Servers can support both TLS 1.2 and TLS 1.3 simultaneously. During the handshake, the client and server negotiate the highest mutually supported version. This means enabling TLS 1.3 doesn’t break access for clients that only support TLS 1.2. However, TLS 1.0 and 1.1 should be disabled on all servers, as they were deprecated by the IETF in 2021 and aren’t considered secure anymore. Modern browser versions released after 2020 have removed TLS 1.0 and 1.1 support entirely.

Do I need a separate SSL certificate for each subdomain?

Not necessarily. A wildcard certificate (*.example.com) covers all first-level subdomains. A SAN certificate can list specific subdomains. Both approaches eliminate the need for individual certificates per subdomain. However, wildcard certificates don’t cover nested subdomains (e.g., a.b.example.com), so those require explicit SAN entries or their own certificates. Evaluate your subdomain structure before choosing between wildcard and multi-domain SAN certificates.