SSL Certificate Checker

SSL Certificate Checker reads the live TLS/SSL certificate served by a domain and shows its expiry date, issuer, subject (CN), alternative names (SAN), TLS protocol and key sizeat a glance. Because it inspects the certificate the server actually presents, you see exactly what sits behind the browser's padlock.

The most important signals are the days remaining until expiry (D-day) and whether the chain is trusted. A near expiry means it is time to renew; a trust failure (authorized=false) points to a missing intermediate certificate or a hostname mismatch. Just enter a domain — no protocol or path needed.

Expiry and renewal cycles

Publicly trusted certificates typically last from 90 days (Let's Encrypt) to a year. An expired certificate triggers a hard red browser warning that blocks visitors, so watch the renewal state from about 30 days out. This tool shows the days remaining as a large D-day, flagging 30 days or fewer as a warning and an expired certificate as danger.

Chain trust and hostnames

A certificate is never trusted on its own; the one the server sends is verified through a chain that leads up to a trusted root. Common failures include:

• The server does not bundle the intermediate certificate, leaving the chain incomplete
• The requested domain is not listed in the certificate's CN/SAN, causing a name mismatch
• The certificate has expired or is not yet valid

When trust fails, the authorizationError code (for example expired, self-signed, or name mismatch) helps you narrow down the cause.

The role of SAN (alternative names)

Modern browsers only use the certificate's SAN (Subject Alternative Name) list for hostname validation. Even if a domain appears in the CN, it will not be trusted unless it is in the SAN. Wildcards (*.example.com) and multi-domain certificates are common, so confirm that the domain you are checking is actually present in the SAN list. To read the SAN from a certificate file you already have, paste it into the SSL Certificate Decoder, and to confirm which protocols the same host accepts use the TLS Version Check.

authorizationError code reference

When trust verification fails, Node's TLS stack returns a standardized error code. Here are the codes you will see most often, what each actually means, and how to fix it.

A worked example

Suppose you check www.example.com and get back:

• Subject (CN): example.com / Issuer: R3, Let's Encrypt
• SAN: example.com, www.example.com
• notAfter: 78 days remaining / Protocol: TLSv1.3 / Key: EC P-256
• authorized: true

Reading it: the issuer is a public CA (Let's Encrypt) and the connecting host www.example.com is in the SAN, so hostname validation passes; 78 days leaves room before renewal; TLS 1.3 with ECDSA means the key strength is sound — everything is healthy. By contrast, if the SAN had only listed example.com without www, authorized would be false with the error ERR_TLS_CERT_ALTNAME_INVALID.

Common pitfall

The most common misconception is "as long as the expiry is far off, it's safe." Even with 100+ days remaining, installing only the leaf certificate without the intermediate produces authorized=false. Worse, your own browser caches intermediates it has seen before, so it can lull you into thinking "it opens fine for me." Always read the D-day and authorized status together, and on install upload the fullchain (leaf + intermediate), not just the leaf.