How to Check an SSL Certificate's Expiration Date (Without OpenSSL)

If the site is one you can visit right now, the fastest way to check certificate expiry is the padlock icon in the address bar — no tools required. In Chrome, click the padlock (or the tune icon next to the URL), open “Connection is secure,” then “Certificate is valid” to see the details panel. Firefox shows the same information behind the padlock → “More Information” → “View Certificate.” Look for the field labeled Valid to or Expires on — that's the certificate's notAfter date.

1. Click the padlock or security indicator to the left of the address bar.
2. Open the certificate details view (wording varies slightly by browser).
3. Find the validity period — most browsers show both Valid from and Valid to, sometimes labeled Issued on / Expires on.

This is the quickest path when you want a one-off answer for a site that's currently loading in your tab. The catch: it only shows the certificate the server is serving at this exact moment, to your browser, over your current connection. If you need to check expiry for a site you can't reach — behind a firewall, not yet deployed, or on a staging host that isn't publicly resolvable — the browser has nothing to inspect, and you need one of the two methods below instead.

The command-line equivalent connects to the server directly and pulls the certificate over the wire. It's the standard answer to how to check ssl certificate expiration date for anyone comfortable in a terminal, and it works against any host and port, not just port 443 in a browser tab:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

notBefore=Feb 10 00:00:00 2026 GMT
notAfter=May 11 23:59:59 2026 GMT

Be honest with yourself about why this command is annoying rather than pretending it's simple: openssl s_client opens an interactive TLS connection and, left alone, it just sits there waiting on stdin instead of exiting — which is why the echo | in front is piping in an empty line to close it automatically. The -servernameflag is easy to forget and, when it's missing on a host using SNI (nearly every host today), you can get the wrong certificate back — say, the server's default cert instead of the one for the domain you actually asked about. And s_clientalone doesn't print human-readable dates at all: it dumps the full connection handshake and the raw PEM certificate, which is why a second invocation — openssl x509 -noout -dates — is piped in afterward just to parse that PEM into the two lines you actually wanted. Three separate details, in one line, none of them obvious from the flag names — which is exactly why this is a command most people look up again every single time instead of memorizing it.

The OpenSSL command above needs something to connect to. If what you actually have is a file — a .pem or .crtpulled from a server config, a certificate a CA just issued that you're about to deploy, or one leg of a chain you downloaded to debug — there's no host to dial, and running s_client against nothing doesn't apply. This is the case a certificate decoder — the browser-based, no-command-line alternative to the OpenSSL method — is built for.

1. Open GenKitLab's Certificate Decoder.
2. Paste the full -----BEGIN CERTIFICATE----- block, or drop the .pem/.crt file onto the page.
3. Read the parsed Valid To field directly — alongside subject, issuer, SANs, and key size, decoded in the same pass.

Here's the detail that explains why pasting a certificate into a plain text viewer never works: the expiry date inside a certificate isn't stored as a readable string like "May 11 2026". It's an ASN.1 Validity structure, and its notAfter field is encoded as either UTCTime (two-digit years, used through 2049) or GeneralizedTime (four-digit years, required from 2050 onward) — both packed binary formats, not text. A tool that just displays the raw bytes of a PEM file shows you base64; to get a human date out, something has to base64-decode the certificate, walk the DER-encoded ASN.1 structure to find the Validity field, and then convert that UTCTime/GeneralizedTimevalue into a normal date. That parsing step is the entire job of a real ssl certificate decoder — it's not optional formatting, it's the only way the date becomes readable at all.

# raw ASN.1 (DER, base64-encoded in the PEM) — not human-readable
30 1e 17 0d 32 36 30 32 31 30 30 30 30 30 30 30 5a
                 ^^ UTCTime tag        ^^ "260210000000Z"

# decoded and shown by the tool
Valid From:  2026-02-10 00:00:00 UTC
Valid To:    2026-05-11 23:59:59 UTC

GenKitLab's decoder does this parsing entirely in your browser using the Web Crypto and native ASN.1 decoding APIs already built into the JavaScript runtime — nothing you paste is uploaded to a server, which matters if the certificate belongs to an internal system or hasn't been deployed publicly yet. In that sense it's a straightforward openssl alternative for this one job: no terminal, no remembering flag order, no piping one command into another — paste the cert, read the date.

• Use the browser padlockwhen you just need a quick answer for a site you're already viewing, right now, over a normal public connection.
• Use OpenSSLwhen you need to check certificate expiry for a live host — especially in a script, a monitoring check, or a CI job where a browser isn't available — and you're fine re-deriving the flag combination or keeping it in your notes.
• Use a certificate decoderwhen you're starting from a file rather than a live connection — a cert from a config, a chain you downloaded, one you're about to install — or when you'd rather read a parsed Valid To field than assemble a two-command OpenSSL pipeline from memory.

For the full breakdown of everything else a certificate contains beyond the expiry date — subject, issuer, Subject Alternative Names, key algorithm and size, serial number — see the companion reference, SSL Certificate Decoder: Reading Every Field, or open the Certificate Decoder directly and decode one now.