SSL/TLS checker

The certificate: issuer, validity dates, and the hostnames it covers through its subject and subject alternative names.

Coverage against the hostnames you actually serve. A certificate valid for `example.com` but not `www.example.com` produces a browser warning on half your traffic.

Protocol versions accepted. TLS 1.2 and 1.3 are current; TLS 1.0 and 1.1 are deprecated and their presence is worth knowing about.

Whether plain HTTP redirects to HTTPS, and whether `Strict-Transport-Security` is sent and with what parameters.

A certificate valid, not near expiry, and covering every hostname served.

TLS 1.2 and 1.3 offered, deprecated versions not.

HTTP redirecting to HTTPS in one hop, on every hostname and on deep paths, not only the home page.

HSTS present with a meaningful max-age.

A certificate expiring within days. Automated renewal exists precisely because manual renewal is forgotten, and an expired certificate makes a site unusable rather than degraded.

A hostname not covered — usually `www` after a migration.

HTTP answering 200 rather than redirecting, which leaves the insecure version fully live.

HSTS with a long max-age published before the configuration was verified, which is hard to undo because browsers honour it for its full duration.

It does not attempt exploits. It is not a penetration test and does not probe for vulnerabilities.

It does not assess private key management, which is not observable from outside.

It does not judge the application: a perfect TLS configuration in front of a vulnerable application is still vulnerable.

`transport.certificate_details` and `transport.certificate_coverage` read the certificate and which hostnames it covers. `transport.tls_versions` and `transport.cipher_suites` report what the server offers.

`transport.https`, `transport.http_redirect`, `transport.hsts`, `transport.hsts_directives` and `transport.hsts_preload_list` cover the protocol and header half.

`transport.mixed_content` reports HTTP resources referenced from HTTPS pages, which is what usually breaks a site immediately after a migration to HTTPS.

Almost never through the cryptography. The failures that take sites down are operational, and they repeat.

Automated renewal that stopped silently. The renewal job runs, the validation challenge fails because a redirect rule now intercepts the `/.well-known/` path, and nothing reports it until the certificate expires ninety days later. Checking expiry externally is the only signal that arrives before the outage.

A hostname added without being added to the certificate. A new subdomain points at the same server, the server presents the existing certificate, and every visitor to the new name gets a warning.

An incomplete chain. The server sends the leaf certificate and omits the intermediates. Desktop browsers frequently recover by fetching them; some mobile clients and most API clients do not, which produces the report that the site "works for everyone except one person".

Clock skew on the server, which makes a valid certificate appear not yet valid. Rare, and baffling until it is identified.

A renewal that succeeded without the service being reloaded, so the new certificate exists on disk and the old one is still being served.