SSL Certificate Validator: Catch Expiry and Weak Crypto Before They Cause an Outage
A certificate that expires unnoticed takes down HTTPS for an entire site — usually discovered by users, not monitoring. This tool decodes a certificate's own properties and checks them against practical, current standards: is it expired or expiring soon, does it use a deprecated signature algorithm, is the key size strong enough, and does it have the Subject Alternative Names modern browsers actually require.
All checks run against the certificate's own decoded fields — no trust store or revocation check.
Why Certificate Expiry Is a Recurring Outage Cause
Unlike most infrastructure failures, an expired certificate doesn't degrade gracefully — HTTPS simply stops working, often with a browser warning most users won't click through. Because certificates are typically valid for 90 days to a year, renewal easily falls off a team's radar until it's already too late; checking expiry proactively catches this before it becomes an incident.
Why MD5 and SHA-1 Signatures Are Flagged as Errors, Not Warnings
Both hash algorithms have practical, demonstrated collision attacks — meaning an attacker with enough resources could theoretically construct a different certificate that produces the same signature, undermining the entire point of the signature. Major CAs stopped issuing SHA-1 certificates years ago; seeing one in the wild today is a genuine red flag, not just a best-practice nitpick.
The SAN Requirement Isn't Optional Anymore
For years, some certificates relied solely on the subject CN for hostname matching. Since 2017-2018, Chrome and other major browsers require the visited hostname to be explicitly listed in the Subject Alternative Name extension — a certificate without SANs will fail hostname verification in current browsers regardless of its CN.
Practical Examples
Catching an Expiring Certificate
Before it becomes an outage.
- 1.Certificate expires in 12 days
- 2.Warning: Expires in 12 day(s) — renew soon
- 3.Trigger renewal before the deadline
Flagging a Legacy SHA-1 Certificate
An old certificate that needs replacing.
- 1.signatureAlgorithm: sha1WithRSAEncryption
- 2.Error: weak signature algorithm
- 3.Replace with a SHA-256+ signed certificate
What Gets Checked
- Expiry: expired or expiring within 30 days
- Not-yet-valid certificates
- Signature algorithm: flags MD5/SHA-1
- RSA key size: flags < 2048-bit
- EC key size: flags < 256-bit
- Self-signed status
- Missing SANs
Good Use Cases
- Auditing a certificate before it goes into production
- Catching an expiring certificate before it causes an outage
- Reviewing a legacy certificate for deprecated crypto
- Confirming SANs cover the hostnames you actually need
Frequently Asked Questions
Why are MD5 and SHA-1 signature algorithms flagged as errors?
Both hash functions have known practical collision attacks, meaning an attacker could in principle forge a different certificate with the same signature. Major browsers and CAs have deprecated and stopped issuing certificates signed with either algorithm — seeing one today usually means a very old or improperly configured certificate.
Why is 2048-bit the RSA key size threshold?
It's the current widely-accepted minimum for RSA in TLS certificates — smaller keys (1024-bit and below) are considered crackable with enough computing resources and are rejected outright by modern browsers and CAs.
Is a self-signed certificate always a problem?
Not inherently — self-signed certificates are completely normal for internal tools, development environments, and root CA certificates themselves. The warning here just flags it as informational: a self-signed cert won't be trusted by a browser unless it's been explicitly added to that browser's trust store.
Why does missing SANs matter so much?
Since around 2017, major browsers stopped falling back to the subject CN for hostname verification and require the visited hostname to appear in the Subject Alternative Name extension. A certificate without any SANs will fail hostname validation in virtually every modern browser, regardless of what its CN says.
Does this check the certificate against a trust store or revocation list?
No — that requires access to a system trust store and, for revocation, a live network check (OCSP or CRL). This tool validates the certificate's own self-contained properties: dates, algorithm strength, key size, and structural completeness.
Is my certificate sent anywhere?
No, all parsing and validation happen entirely in your browser via a local ASN.1 parser — no upload.