SSL certificate checker

What the SSL checker reports

When a browser opens an HTTPS site, the server presents a certificate to prove its identity. The checker connects to the server the same way and completes the TLS handshake, then reports what came back: who the certificate was issued to, which names it covers, who issued it, when it is valid, the chain up to the root, and the TLS version and cipher in use. It sends nothing after the handshake, so no page is requested.

How to use it

1. Enter the hostType example.com, paste a URL, or add a port, as in mail.example.com:993. The default is 443, and 8443 works for a web server on an alternate port. Public IP addresses work as well, and the last question below lists the mail, LDAP and DNS-over-TLS ports.
2. Read the verdictThe headline reads Valid and trusted, Expires in N days (30 or fewer left), Expired N days ago, Not valid yet, Self-signed certificate, Browsers won't trust this, Certificate is for a different name, or Only supports outdated TLS. A list of problems follows, most with a suggested fix.
3. Open the detailsIf something fails, the Chain tab lists each certificate with its issuer and expiry date, so you can see where a link is missing or has expired. The other tabs show the certificate itself, the connection and the names it covers.

Common certificate errors, decoded

• Works in my browser, fails in curl or an API client. Suspect an incomplete chain first, since browsers can fetch a missing intermediate and many libraries cannot.
• SNI matters. Servers hosting many sites choose a certificate from the name the client sends (SNI). The checker sends the name you entered, as browsers do. For an IP address it sends no name, so the server shows its default certificate.
• Old TLS versions. LookupOwl connects with TLS 1.2 or 1.3 first. If a server refuses both, it makes one more attempt that can only use TLS 1.0 or 1.1, just to learn which version the server speaks and read its certificate. You then see “Only supports outdated TLS”, with the dates and names from that certificate. The chain is not checked for trust over that connection, and the result is never a pass. Enable TLS 1.2 and 1.3 on the server, then check again. If even the older attempt fails, you get a short message saying the server refused every version we can speak, instead.
• Revocation is not the same as expiry. A revoked certificate can still look valid by date. The checker reports whether the server stapled an OCSP response, but it does not ask the CA about revocation. Some CAs, such as Let's Encrypt, have stopped running OCSP, so “No” under OCSP stapling is normal for their certificates.
• Trust follows one root list. The verdict uses the public root certificates bundled with LookupOwl's software (the Mozilla list). Chrome, Apple and Microsoft keep their own lists, so a rare certificate can be trusted by one and not another.

Installation problems to look for

• The certificate is on the web server but not on the CDN or load balancer. The public name ends its TLS at whichever layer answers first.
• Renewed but still serving the old certificate. The service needs a reload or restart, or there are several nodes and one was missed.
• Only the bare domain is covered. A certificate for example.com does not automatically cover www.example.com. List both names in the SANs.
• Wildcard expectations. *.example.com covers shop.example.com, but not example.com or a.b.example.com.
• Forgotten services. Mail servers (SMTPS 465, IMAPS 993), LDAPS and DNS-over-TLS endpoints have certificates too, and they expire just as quietly.
• Internal names. The checker only reaches public hosts. Private, loopback and internal names, and single-word names like intranet, are refused.

How the check works

LookupOwl looks up the host, checks that every address is public, connects to one of them on the port you chose and completes a TLS handshake. It sends the server the name you entered (SNI) and, on ports 443 and 8443, offers HTTP/2 and HTTP/1.1 (ALPN). On port 587 it first asks the mail server to switch to TLS with STARTTLS. It records the certificate chain, the protocol, the cipher and whether a stapled OCSP response arrived, then hangs up. If the server refuses TLS 1.2 and 1.3, one more attempt that can only use TLS 1.0 or 1.1 reads the certificate and the version, and that result is marked unverified. The trust and name checks are done by the TLS library itself, against its bundled roots. A handshake gets about nine seconds, fresh checks of any one host are limited to 20 a minute across all callers, and results are cached for up to ten minutes. Check again fetches a fresh one.

# The same thing with OpenSSL
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject

Standards

• RFC 5280: the X.509 certificate and path validation profile. RFC 9525: service identity checks (replaces RFC 6125).
• RFC 8446 and RFC 5246: TLS 1.3 and 1.2. RFC 8996: deprecation of TLS 1.0 and 1.1.
• RFC 6066: Server Name Indication, and the certificate status request behind OCSP stapling. RFC 7301: ALPN. RFC 3207: STARTTLS for SMTP.
• RFC 6960: the Online Certificate Status Protocol (OCSP).
• CA/Browser Forum Baseline Requirements: the rules public CAs follow, including certificate lifetimes.