SSL Checker

Enter the domain in the box above. The certificate's valid until date and the exact number of days remaining are shown first, ahead of every other detail, because that is the fact an expiry check exists to establish. The result is read from a live TLS handshake against the server, so it reflects the certificate the server is serving right now rather than a cached record.

From a terminal, curl https://dnsx.dev/ssl/example.com returns the same data as JSON with no API key and no email address required. With OpenSSL installed, echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates prints the notBefore and notAfter dates directly.

Public TLS certificates have been capped at 398 days since 2020, and the CA/Browser Forum has adopted a schedule that shortens the maximum lifetime to 200 days in 2026, 100 days in 2027 and 47 days in 2029. Renewal windows are getting narrower, which is why monitoring days-remaining matters more than it used to.

The SSL grade condenses four measurements into one letter: whether the certificate is currently valid and matches the hostname, whether the chain to a trusted root is complete, which TLS versions the server accepts, and the strength of the cipher suites it offers.

An A means a valid, correctly chained certificate with only modern TLS enabled. Anything at B or below indicates at least one concrete defect: a deprecated protocol still accepted, an incomplete chain, or weak ciphers. A failing grade normally means the certificate is expired, self-signed, or issued for a different hostname.

A certificate chain is the ordered path from the server's own leaf certificate, through one or more intermediate CA certificates, to a root certificate already present in the client's trust store. Each certificate is signed by the one above it, and a client only trusts the leaf if it can build that path all the way to a root it already holds.

Root certificates ship with the operating system or browser; intermediates do not. The server is responsible for sending them. A server that omits an intermediate produces the single most common TLS misconfiguration: the certificate itself is entirely valid, but clients that have not independently obtained the intermediate cannot complete the path and reject the connection.

TLS 1.3, published as RFC 8446 in 2018, completes its handshake in one round trip instead of two, removes RSA key exchange, static Diffie-Hellman, CBC-mode ciphers and compression outright, makes forward secrecy mandatory, and encrypts more of the handshake itself.

TLS 1.2 remains secure when configured carefully, but it permits a much broader set of cipher suites and therefore has to be configured carefully. TLS 1.0 and TLS 1.1 were deprecated by RFC 8996 in 2021 and should be disabled entirely; a server still accepting them will not earn a top grade here.

Almost always a missing intermediate certificate. Browsers cache intermediates they have encountered on other sites and some will fetch a missing one from the URL in the certificate's Authority Information Access extension, so a browser that has already seen the intermediate succeeds. Command line clients, mobile apps, Java runtimes and most language HTTP libraries do neither, so they fail against the same server.

The test that removes the ambiguity is a fresh client with an empty cache, or the chain view above, which reports the chain exactly as the server sent it.