A certificate can be checked in three ways: in the browser, with the openssl command, and with an external checking service — each method answers its own question, and none fully replaces the others.
What actually needs to be checked
Behind the phrase "check the certificate" there are actually several different questions, and the answer to each matters in its own way.
| Criterion | What a mismatch risks |
|---|---|
| Expiration date | Browsers and apps show an error, the site is treated as unsafe |
| Name in the certificate | A domain mismatch warning even if the certificate is valid |
| Chain to the root | Some devices and libraries cannot find the intermediate and refuse the connection |
| Signature algorithm | An outdated algorithm gets blocked by modern browsers and clients |
| Revocation | A revoked certificate should be treated as invalid, but not every client checks for it |
In the browser
The browser shows the certificate through the padlock icon next to the address bar — from there you can see the expiration date, the site name, and the authority that issued it.
The browser does not show the full chain that the server actually sends when the connection is set up, and it does not always flag an outdated signature algorithm — it trusts the chain the operating system already built instead of checking it again from scratch.
With the openssl command
To check a certificate on a live server, you connect directly to the port and look at what the server sends back.
openssl s_client -connect example.com:443 -servername example.com # check a certificate on a server over the networkTo check a certificate file already saved locally, you read its contents without connecting to any server.
openssl x509 -in certificate.crt -noout -dates # check the validity dates in a local fileAn incomplete chain is the most common failure
A browser on a computer remembers intermediate certificates from past visits and completes the chain itself, so the error stays invisible. A phone, curl, and strict clients remember nothing and require the server to send the whole chain itself — hence the difference in behavior for the very same site.
The same openssl command reveals the problem: if the server's response is missing an intermediate certificate, it is immediately visible in the chain output.
Expiration and auto-renewal
Automatic renewal removes most of the worry but is not a guarantee: it silently fails to work if the port the certificate authority uses to verify domain ownership is closed, the web server or renewal handler changed, or the domain moved to different name servers.
Details on connecting and issuing a certificate are in the article how to enable SSL.
Symptom, likely cause, and how to check
The table below helps quickly match what the user sees with what to look for on the server.
| Symptom | Likely cause | How to check |
|---|---|---|
| Browser is fine, but curl or an app shows an error | Incomplete certificate chain | The openssl s_client command or an external chain-checking service |
| Certificate belongs to a different name | Certificate was not updated after a domain or subdomain change | The name fields inside the certificate itself |
| Auto-renewal failed | Verification port is closed or the web server changed | The certificate authority log and the date of the next attempt |
| Self-signed certificate warning | Certificate was not issued by a trusted authority | The issuer field in the certificate |
| Expiration error on some devices but not others | Different trusted root lists on older systems | The expiration date and the list of root authorities |
Frequently asked questions
How do you know when a certificate expires?
The expiration date is visible in the browser next to the site address, or with the openssl command, which shows the start and end dates of the certificate. External checking services can also send a reminder in advance, which helps when nobody is watching the certificate by hand.
Why does a site open fine in a browser but fail in an app?
The usual cause is an incomplete certificate chain: the browser fills in the missing link itself, relying on what the operating system already remembers, while a strict client such as curl or a mobile app expects the full chain from the server itself and refuses the connection if it is not sent in full.
What does checking a certificate actually mean?
It means comparing several independent facts: whether the expiration date has passed, whether the site name matches the name in the certificate, whether the chain builds up to a trusted root, and whether the certificate has been revoked. The browser, the openssl command, and an external service each check different parts of this set.
Is there anything to do during renewal?
Usually nothing with automatic renewal, but it is worth checking from time to time that it is actually happening rather than silently failing because of a closed port or a changed web server. A manual reissue requires installing the new certificate on the server yourself after it is issued.
Conclusion
A browser is enough for a one-off check, the openssl command helps diagnose user complaints, and an external service with notifications is best for ongoing monitoring. What the different certificate types mean at the point of issuance is covered in the article types of SSL certificates.