Is your certificate about to fail, or has it already?
Enter a hostname. This opens the same connection a browser does, reads the certificate you are actually serving, and tells you what a visitor sees. No signup, no email required.
Every test, explained
A certificate can fail in more ways than expiry, and most of them are invisible from the browser you happen to be using. Here is what each test looks at.
Expiry — how long you have left
Every certificate carries a start date and an end date. Past the end date, browsers stop asking questions and show a full-page warning instead. Most visitors leave at that point rather than click through it.
So the tool reads both dates and counts the days. Under thirty days is worth knowing about. Under seven means automated renewal has already tried and failed, more than once, without telling anybody.
It also catches the opposite problem: a certificate whose start date is in the future. That one is almost always a clock, not a certificate. Check the server time and the NTP service before reissuing anything.
Hostname coverage — does it match the name you use
A certificate is issued for specific names. If the name in the address bar is not one of them, the browser reacts exactly as it would to an expired certificate, no matter how valid the certificate itself is.
The tool reads the Subject Alternative Name field, which is the only field current browsers look at. Chrome stopped reading Common Name in 2017 and Safari followed, so a certificate with no SAN fails today whatever name it carries.
Then it checks the other form of your address. If you scan example.com, it also checks www.example.com, and the reverse. That is the "it works for me" failure — whoever set it up tests the address they always use, and never sees the broken one.
The chain — what vouches for your certificate
Your certificate is signed by an intermediate, and that intermediate is signed by a root the browser already trusts. Your server has to send both. Send only your own certificate and the link back to the root is missing.
This is the failure most often reported as working, because desktop Chrome and Firefox usually paper over it. They have the intermediate cached from another site. Android, curl, Java and most payment gateways cache nothing and simply fail.
The tool also compares expiry dates along the chain. A chain is only good until the earliest date in it, so an intermediate expiring before your certificate ends it early — and renewing your own will not move that date.
Signature and key — whether the crypto still counts
A certificate is only as good as the algorithm that signed it. MD5 and SHA-1 have been rejected by browsers since 2017, because forging one stopped being expensive.
No public authority will issue either today. So when this shows up, the certificate was generated by hand or came from an internal authority — which tells you something useful about where to look.
Key size gets the same treatment. Browsers still accept some undersized keys, but security scanners and payment processors do not. That is usually where it surfaces: as a failed compliance scan rather than a broken site.
CAA — whether your own rules allow your own certificate
CAA records name which certificate authorities may issue for your domain. Every compliant CA reads them first and refuses if it is not listed.
So this tool compares the authority that issued your live certificate against the authorities your CAA records permit. A mismatch breaks nothing today. The current certificate stays valid to its last day.
Renewal is where it bites. The CA is required to refuse, automated renewal fails with an authorisation error that never mentions CAA, and the first visible sign is a warning on your own site. The records themselves are checked by the DNS Health Check.
Protocol versions — what your server still agrees to speak
TLS 1.0 and 1.1 were withdrawn by every major browser in 2020, and neither is permitted under PCI DSS. The tool asks your server directly whether it will still negotiate them.
Leaving them on helps nobody. The browsers that needed them cannot reach modern sites for other reasons anyway, so all it does is leave a weaker path available.
One honest limitation: if this server's own TLS library refuses to offer the old versions, the test cannot run and the result proves nothing. The report says inconclusive in that case rather than claiming a pass it did not earn.
HTTPS enforcement and HSTS — do visitors actually reach it
A valid certificate is no use if nobody arrives over it. So the tool asks port 80 one question: does a plain HTTP request end up on HTTPS.
If it does not, anyone typing your address without https:// stays on the unencrypted version, sees "Not secure" in the address bar, and sends everything in the clear. Search engines index both versions and split the ranking between them.
Then it reads the HSTS header. A redirect still leaves the very first request unencrypted, and that first request is the one worth intercepting on public wifi. HSTS closes the gap a correct redirect leaves open. Hops, loops and www inconsistency belong to the redirect checker, not here.
What usually goes wrong, and how it gets fixed
Most certificate failures come down to the same handful of causes. Here they are, with the fix.
Renewal ran, and the old certificate is still being served
This is the most common certificate outage there is, and the renewal is rarely the part that broke. Certbot got a new certificate, wrote it to disk, and nothing told the web server to pick it up. Apache keeps serving the old one until it is reloaded.
So attach the reload to the renewal itself rather than trusting a separate cron job:
certbot renew --deploy-hook "systemctl reload httpd"Use apache2 on Debian and Ubuntu, httpd on RHEL, AlmaLinux and CentOS, and nginx if that is what you run. The deploy hook only fires when a certificate was actually renewed, so it is safe to leave in place permanently. Then run certbot renew --dry-run and confirm it completes without touching anything live.
The intermediate certificate is missing
Your site works in your browser and fails for a payment gateway, an Android app, or anything using curl. That combination almost always means the chain is incomplete.
This is a configuration change, not a new certificate. Point the server at the full chain file rather than the certificate on its own:
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemThe mistake is using cert.pem instead of fullchain.pem — they sit in the same directory and differ by exactly the intermediate. On nginx, ssl_certificate wants fullchain.pem for the same reason. Reload afterwards, then re-run this check.
www gets a warning and the bare domain does not
Both names need covering, even if you only advertise one. People type them interchangeably, old links use www, and search results can carry either.
Reissue with both names on the same certificate:
certbot certonly --webroot -w /var/www/example.com \
-d example.com -d www.example.comThen set up a redirect so one form is canonical. Do it in that order — the certificate has to cover the name before the redirect can run over HTTPS, or visitors get the warning on the way through.
Plain HTTP is served instead of redirecting
You have a working certificate that visitors never reach. Send them there with a permanent redirect on port 80:
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com/
</VirtualHost>Use a 301, not a 302 — a temporary redirect tells search engines to keep the HTTP version in the index. Once that works, add Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" on the HTTPS host. Start with a shorter max-age if you are not yet certain every subdomain can serve HTTPS, because browsers honour the header for its full duration and you cannot call it back.
TLS 1.0 and 1.1 are still enabled
Usually nobody switched them on deliberately. They came with a default from years ago and nothing has revisited it since.
One line disables them:
SSLProtocol -all +TLSv1.2 +TLSv1.3On nginx the equivalent is ssl_protocols TLSv1.2 TLSv1.3;. Check your access logs first if you serve a specialist audience with old embedded clients — but for an ordinary website this is safe, and it is required if you take card payments.
Found something broken?
Send me the result. I'll tell you what it takes to fix it, and whether it's worth paying anyone to do — including me.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.