server-assistedSSL / TLS audit
Certificate chain, expiry, revocation, trust and security headers — graded checks with plain-language fixes. Free, no signup.
How this audit works
We open a TLS connection to the host from outside your network, exactly as a browser would, and read what the server presents: the certificate chain, the protocol versions and cipher suites it agrees to, and the security headers it returns. Nothing is installed and no credentials are needed — everything checked here is already public.
Revocation is checked against the CA itself, not just the certificate file: a stapled OCSP response, the CA's OCSP responder, and the certificate revocation list. This is the one failure the expiry date cannot show — a revoked certificate stays inside its validity window and still completes a handshake, while browsers refuse the site with ERR_CERT_REVOKED.
Each check is graded pass, warn or fail, and the grade is the worst of them. A warn usually means the configuration works today but will bite you later: a certificate expiring inside 30 days, HSTS without subdomains, TLS 1.0 still enabled for a client that no longer exists.
The grade has two tiers. F means browsers refuse the site right now — the certificate is expired, revoked, self-signed, issued by an untrusted CA, or does not cover this hostname. Nothing else can offset that. Everything below F is scored: a failing check weighs three warnings, and the total moves the letter from A down to D.
Does the audit change anything on my server?
No. It performs a normal TLS handshake and one HTTPS request, the same traffic any visitor generates. Nothing is written, and the connection is closed as soon as the response headers arrive.
The certificate is valid but the browser says ERR_CERT_REVOKED. What happened?
The CA pulled the certificate before its expiry date — because of a key compromise, a superseded reissue, or because the CA stopped serving the customer. The certificate still looks fine in the file and still completes a TLS handshake, so most tools call it valid. This audit asks the CA directly, through OCSP or the CRL, so a revoked certificate shows as a failing check with the revocation date and the reason. The only fix is a new certificate; a revocation cannot be undone.
Why did my site get an F when only one check failed?
F is not a score, it is a state: browsers refuse the site. Only five findings produce it — an expired certificate, a revoked one, a self-signed one, an untrusted issuer, or a certificate that does not cover the hostname. Each of them means visitors see a full-page warning instead of your site, so a perfect TLS configuration around it changes nothing. Fix that one check and the grade jumps straight back into the A–D range.
Why does my certificate show as valid in the browser but fail here?
Almost always an incomplete chain. Browsers cache intermediate certificates from other sites you visited, so a server that forgets to send its intermediate still works for you and fails for a fresh client — including mobile apps and curl. Serve the full chain and the check passes.
My grade is B because of security headers. Is that a TLS problem?
No, and that is the point of showing them together. The certificate can be perfect while the site still ships without HSTS or a Content-Security-Policy. Those are one-line server changes that raise the grade immediately.
How often should I re-run it?
On every certificate renewal and after any change to the reverse proxy or CDN. Both are the usual sources of surprise: a renewal that drops the intermediate, or a proxy that quietly re-enables an old protocol.
Can I check an internal host?
No. The probe comes from the public internet, so the host has to resolve and answer publicly. That is deliberate — a tool that could reach internal addresses would be a scanning service for someone else's network.
Related tools: Security headers, HTTP headers and DNS health.