EnterraHost
A TLS certificate check answers a narrower question than most people expect. It tells you whether a certificate was presented, whether it is currently within its validity dates, and whether the name on it matches the name you asked for. It does not tell you that the site is safe, and it does not tell you that a browser will trust it.
You can check any hostname without an account and see the version and the expiry date in the same result as everything else. This is what each part means.
What the check is verifying
Three things have to line up before a certificate is worth anything.
The chain. A certificate is issued by an authority, which is itself vouched for by another, up to a root that your device already trusts. If a link in that chain is missing, the certificate is real and still unusable, because nothing can verify it. A server that forgets to send an intermediate certificate produces exactly this, and it is one of the most common misconfigurations there is.
The name. The certificate has to cover the hostname being requested. One certificate can cover several names, which is why a mismatch is often a near miss rather than a wildcard, and why a certificate for the bare domain does not automatically cover the www version.
The dates. A certificate has a start and an end. Outside those dates it is refused. The failure appears as a security warning rather than an expiry, which is why it confuses people who have not seen it before.
The version matters as much as the certificate
A certificate protects nothing if the connection carrying it is being negotiated with an obsolete version of TLS. The protocol that matters today is defined in RFC 8446, which is TLS 1.3, and the previous generation is still widely supported.
What should not be supported is anything older. RFC 8996 deprecates TLS 1.0 and TLS 1.1, and SSL versions before them were broken long ago. A check that reports one of those is reporting a real finding rather than a curiosity, because a client forced to negotiate down to a deprecated version is not getting the protection the padlock implies.
Why certificates last weeks rather than years
Certificate lifetimes have fallen deliberately, and the reason is worth knowing because it changes how you plan renewals.
A long-lived certificate is a long-lived risk. If a key leaks, every day until expiry is a day the certificate is valid and wrong. Short lifetimes cap that window, and they also make renewal a routine that has to work rather than a yearly ceremony somebody remembers.
Let's Encrypt, which issues most of the certificates on the web, states in its own documentation that its certificates are valid for 90 days by default, with an option for short-lived certificates valid for six days. There is no setting to make them longer. If a check reports an expiry inside the next fortnight, treat that as the finding rather than a note, because renewal is the whole point of the short window and it is the step that silently fails.
What a TLS certificate check cannot tell you
- Nothing about the page contents. A perfectly valid certificate on a page that loads scripts over an insecure connection produces a browser warning anyway. Mixed content is a page problem, not a certificate problem, and no certificate check can see it.
- Nothing about revocation, reliably. A certificate can be withdrawn before its expiry date, and the mechanisms for publishing that are inconsistent enough that clients often carry on accepting a withdrawn certificate. A valid result means valid as far as the check could see.
- Nothing about the wider configuration. Whether the site insists on HTTPS, whether it sets a strict transport policy, and which ciphers it will negotiate are separate questions with separate answers.
- Nothing about trust stores. Trust is decided by the device, and your device is not the same as everyone else's. A certificate can be accepted in one place and rejected in another, which is one more reason a green result is a measurement rather than a guarantee.
What to do with the result
If the certificate is present, within its dates and on a current protocol, the transport part of the problem is not your problem and you can stop looking there.
If it is expiring soon, renew it now rather than on the day. Automatic renewal is the correct answer and the check is a way to find out that the automation stopped, which is the failure that happens.
If the chain is incomplete or the name does not match, the fix is a configuration change and not a new certificate. Both are worth fixing immediately, because they are the two failures that turn a working site into a warning page for every visitor at once.