What is an SSL certificate check?
An SSL certificate check connects to a server the way a browser does and inspects the certificate it presents: who issued it, which hostnames it covers, when it expires, and whether the chain of trust back to a root certificate authority is complete. It shows problems before visitors see a browser warning.
What this tool checks
| Check | Pass | Fail |
|---|---|---|
| Expiry | The certificate is inside its validity period | Expired, or expiring within days |
| Chain | The server sends every intermediate up to a trusted root | An intermediate is missing, or the certificate is self-signed |
| Hostname | The name you entered appears in the certificate's SAN list | The certificate was issued for a different name |
| Revocation | The serial number is not on the issuer's revocation list (CRL) | The CA has revoked the certificate |
| Key and signature | RSA 2048+ or an elliptic-curve key, SHA-256 or better | RSA under 2048 bits, or a SHA-1 signature |
It also shows the issuer, serial number, SHA-256 fingerprint, every name on the certificate and each certificate in the chain with its own validity dates. These are the same checks NetworkAI runs daily on monitored domains.
How to fix common certificate problems
Incomplete chain. The server is sending only its own certificate. Desktop browsers often hide this by fetching the missing intermediate themselves, but curl, mobile apps, Java and Python clients do not, so API calls fail while the site looks fine. Configure the server with the full chain file:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemHostname mismatch. The certificate does not list the name you connected to. The usual causes are a certificate for example.com that omits www.example.com, or a wildcard used one level too deep: *.example.com covers api.example.com but not v2.api.example.com. Reissue with every name included.
Expired certificate. Renew and install it, then find out why automation did not: a renewal timer that stopped, a DNS or HTTP validation that now fails, a CAA record that excludes the CA, or a reload step that never ran so the server kept serving the old file.
Renewed, but the old certificate is still served. The new files are on disk and the server has not been reloaded, or a load balancer or CDN in front holds its own copy.
Why expiry is harder to manage than it used to be
Certificate lifetimes are being cut on a fixed schedule set by the CA/Browser Forum (ballot SC-081v3). The maximum fell from 398 to 200 days in March 2026 and drops to 100 days in March 2027 and 47 days in March 2029.
At 47 days, renewal is something that happens eight times a year per certificate, and it has to be automated. That shifts the risk. The question is no longer "did someone remember?" but "did the automation quietly stop working?" A certificate with plenty of days left can already be in trouble if its replacement should have arrived and has not.
- See how your certificate compares with each deadline: certificate lifetime readiness.
- Plan renewal frequency for a given date: 47-day certificate lifetime calculator.
- Check many hosts at once: bulk SSL expiry checker.
How revocation is checked
A certificate authority can revoke a certificate before it expires, for example when its private key is exposed. This tool downloads the certificate revocation list (CRL) named in the certificate and looks for its serial number.
CRLs are used rather than OCSP because the industry is moving that way: Let's Encrypt, the largest CA, shut down its OCSP service in 2025. If a certificate names no CRL, or the list cannot be fetched, revocation is shown as unknown rather than assumed good.