To verify that an SSL certificate is valid, you need to confirm four things at once: it has not expired, it matches the hostname you are connecting to, it chains up to a trusted root certificate authority, and it has not been revoked. If all four hold, browsers show the padlock and connections succeed. If any one fails, visitors get a security warning no matter how correct the other three are. This guide explains each check, the most common reasons a certificate shows as invalid, and how to confirm validity in seconds.
What makes an SSL certificate valid
A certificate is a signed statement that a given public key belongs to a given hostname, vouched for by a certificate authority. Validity is not a single property. A browser accepts a certificate only when every one of these conditions is true at the moment of the connection: the current date falls inside the certificate's validity window, the hostname is covered by the subject or a subject alternative name, the issuing chain leads to a root the device already trusts, and the certificate has not been revoked by its issuer.
This is a different question from reading what is inside a certificate. If you want to inspect the issuer, chain, expiry, and SAN fields in depth, see the guide on how to check an SSL certificate. Here the focus is the yes-or-no decision: is this certificate valid, and if not, why.
The four validity checks
| Check | What it confirms | Typical failure |
|---|---|---|
| Expiry | Today is within the not-before and not-after dates | Certificate expired or renewal not deployed |
| Hostname match | The name you typed is in the subject or a SAN | Cert issued for the apex but used on www, or wrong SAN |
| Trusted chain | Intermediates link the leaf to a trusted root | Missing intermediate certificate on the server |
| Revocation | The issuer has not revoked the certificate | Key compromise or mis-issuance revoked via CRL or OCSP |
Browsers run all four automatically and fail closed on the first problem. Because they stop at the first failure, the warning you see may not name every issue. A certificate can be both expired and missing an intermediate, and you will only hear about the expiry until you fix it.
How to verify a certificate step by step
- Check the dates. Read the not-before and not-after fields. If today is outside that range, the certificate is invalid regardless of anything else.
- Confirm the hostname. The exact name in the address bar must appear in the subject common name or, more reliably, in the subject alternative name list. A wildcard covers one label level only.
- Walk the chain. The server should send the leaf certificate plus every intermediate up to (but not including) a trusted root. A broken or incomplete chain fails on devices that lack the missing intermediate.
- Check revocation. Confirm the certificate is not listed in a certificate revocation list and that its OCSP status is good.
- Test from outside your network. Local trust stores and corporate proxies can mask problems, so verify from a neutral vantage point.
You can run all of these at once with the Valla SSL checker, which reports expiry, hostname coverage, chain completeness, and revocation status in a single result.
Common reasons a certificate shows as invalid
The most frequent cause is a missing intermediate certificate. The certificate itself is fine, but the server was configured with only the leaf, so devices that do not already cache the intermediate cannot build a path to a trusted root. The fix is to install the full chain, not just the end-entity certificate.
Hostname mismatches are next. A certificate issued for example.com does not automatically cover www.example.com unless www is listed as a SAN. Expiry is third and the most preventable: a renewed certificate does no good until it is actually deployed to every server and load balancer. Less common but important are clock problems on the client, where a device with the wrong date rejects a perfectly valid certificate, and name constraints enforced by a CAA policy, which the CAA records guide explains.
Self-signed and internal certificates
A self-signed certificate is cryptographically fine but not valid for public use, because no trusted CA vouches for it. Browsers warn unless the certificate is manually added to the trust store. The same applies to internal CAs: valid inside an organization that distributes the root, invalid to anyone outside it. When a public site shows a self-signed certificate warning, it almost always means a misconfiguration or an interception proxy rather than the intended certificate.
Frequently asked questions
How can I tell if an SSL certificate is valid right now?
Run the hostname through the Valla SSL checker. It confirms in one result whether the certificate is unexpired, matches the hostname, chains to a trusted root, and is not revoked, which are the four conditions a browser requires.
Why does my certificate work in one browser but not another?
This almost always means a missing intermediate certificate. Browsers and devices that already cached the intermediate can build the chain, while those that have not cannot. Installing the complete chain on the server fixes it everywhere.
Is a certificate invalid the moment it expires?
Yes. Validity is time-bound. Once the current date passes the not-after field, every browser treats the certificate as invalid and shows a warning, even if nothing else about it changed. Renew and deploy before that date.
Does a valid certificate mean the site is safe?
No. A valid certificate confirms the connection is encrypted and the hostname is authenticated. It says nothing about whether the site itself is trustworthy. Phishing sites can and do use valid certificates, so validity is necessary but not sufficient for trust.
What is the difference between an expired and a revoked certificate?
An expired certificate simply passed its end date. A revoked certificate was invalidated by its issuer before expiry, usually because the private key was compromised or the certificate was mis-issued. Both produce browser warnings, but revocation signals a deliberate action by the CA.
Want a definitive answer for your own site? Check it now with the Valla SSL checker and see all four validity signals at a glance.