FREE THOUGHT · FREE SOFTWARE · FREE WORLD

Check any site's SSL/TLS certificate: whether browsers trust it, the names it covers, when it expires, the chain the server sends, which TLS versions it still accepts, HSTS, and whether http:// redirects to https://. If something is wrong, you get the Apache 2.4 config that fixes it.

Hostname, optionally with :8443. Only public addresses can be checked; results are cached for 5 minutes.

Next: check the security headers and the http → https redirect chain.

Your certificate is the one thing standing between your visitors and whoever is sitting on the wire between you. When it expires at 3am on a Sunday, nobody gets a warning except the browser's big red page. I built this checker so I could look at a site's TLS the way an attacker does: what it offers, what it leaks, and what it forgot.

What the SSL checker tests

Type a hostname. The server opens a real TLS connection to it and reports back:

  • The certificate: subject, issuer, every name in the SAN list, serial, key type and size, signature algorithm, and the exact days left before it dies.
  • Name match: whether the hostname you typed is actually covered, wildcards included. *.example.com covers www.example.com but not example.com and not a.b.example.com. People get this wrong constantly.
  • The chain: whether the server sends its intermediates. A missing intermediate works in Chrome on your laptop (it fetches the gap) and fails in curl, Java, older Android and half the bots on the internet.
  • Protocol versions: which of TLS 1.0, 1.1, 1.2 and 1.3 the server accepts. 1.0 and 1.1 are dead; if they still answer, turn them off.
  • HSTS: whether Strict-Transport-Security is sent, its max-age, includeSubDomains and preload.
  • The HTTP side door: whether plain http:// redirects to HTTPS, and with which status.

Lock it down in Apache

This is the baseline I run. Modern clients only, server cipher order left to the client since everything in the list is strong:

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLUseStapling          on
SSLStaplingCache        "shmcb:logs/ssl_stapling(32768)"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Then make plain HTTP a dead end that only knows one word, 301:

<VirtualHost *:80>
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>

Start HSTS with a short max-age like 300, confirm nothing breaks, then raise it. Once you're on the preload list, getting off it takes months.

Check it from your own shell

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
openssl s_client -connect example.com:443 -tls1_1 </dev/null   # should fail

FAQ

The checker says the chain is incomplete but my browser is fine.

Browsers cache and fetch intermediates for you. Everything else doesn't. Point SSLCertificateFile at the fullchain file, not just your leaf cert.

Why does it say the name doesn't match?

The hostname isn't in the certificate's SAN list. The old Common Name field has been ignored by browsers for years. Reissue the cert with every name you serve, including the bare domain.

Can it check servers on my LAN?

No, on purpose. It only connects to public addresses on standard ports, and refuses private, loopback and cloud-metadata ranges at every step. A tool that fetches URLs for strangers is a gift to attackers unless it's paranoid. Mine is.

Next: run the same host through the security headers checker and the redirect checker.