An X.509 certificate is a signed statement binding a public key to a name. Under the base64 of a PEM block sits DER-encoded ASN.1: a TBSCertificate — the portion that is actually signed — holding the version, serial number, issuer and subject Distinguished Names, a validity window, the subject public key, and a set of extensions, followed by the signature algorithm and the signature itself. This decoder walks that structure in your browser and lays out every field, instead of making you remember which openssl incantation prints which part.
The validity window causes the most outages, and it carries the most encoding history. RFC 5280 requires certificate times in UTC with seconds, and pins a rule that catches people out: in the older UTCTime encoding the year has only two digits, so 50–99 means 19xx and 00–49 means 20xx. That is exactly why a certificate valid past 2049 must switch to GeneralizedTime with a full four-digit year. Both encodings are in the wild and both are handled here, with expired, not-yet-valid, and expiring-soon all reported against your clock.
Signature findings are graded by how thoroughly the hash is broken, not by how old it is. A SHA-1 signature is flagged because SHA-1 collisions are practical — the SHAttered work produced a real one, so a SHA-1 signature no longer firmly binds a certificate to its contents. MD5 is treated as critical, because researchers chained chosen-prefix MD5 collisions into a working rogue CA certificate. Those are two different claims backed by two different results, so they carry different severities and different citations.
The remaining checks concern how the certificate is scoped. A missing subjectAltName matters because browsers stopped honouring commonName as a hostname years ago, so a CN-only certificate simply will not validate. A wildcard SAN is informational — legitimate, but it widens the blast radius if the key leaks. Basic constraints reveal whether this is a CA certificate. A critical extension the parser does not recognise is surfaced rather than skipped, because RFC 5280 says a conforming implementation must reject precisely that. The embedded RSA key also runs through the same weakness checks as the standalone key inspector, so an undersized or ROCA-fingerprinted key inside a certificate does not slip past.
One limit, stated plainly: this tool inspects a single certificate. It does not fetch or build a chain, does not check revocation via CRL or OCSP, and does not verify the signature against an issuer's public key — with one certificate pasted in, there is nothing to verify against. So it will never tell you a certificate is trusted. It tells you what the certificate asserts, and which of those assertions are self-evidently a problem.
Edge cases worth knowing
- A self-signed certificate
- When the subject and issuer DNs are identical, tryb reports self-signed as informational rather than a warning. Self-signed is correct and expected for a root CA or a local development certificate, and is only a problem if you expected a publicly-trusted one. tryb compares the names only — it does not verify the certificate's signature against its own key.
- A certificate valid beyond 2049
- Such a certificate cannot use UTCTime, whose two-digit year would be ambiguous, so it must use GeneralizedTime. Both encodings are supported, and the test fixtures deliberately include a certificate dated 2090 to exercise the GeneralizedTime path rather than assuming it works.
- A long-lived internal certificate
- A ten-year certificate is a warning about public-CA acceptance, not a cryptographic flaw. Publicly-trusted TLS certificates are capped at 398 days by the CA/Browser Forum and enforced by the browser root programs, but a long-lived certificate from a private internal CA works fine.
- A certificate whose embedded key is itself weak
- The public key runs through the full RSA inspection: modulus size, ROCA fingerprint, small factors, close primes, and exponent sanity. A 2048-bit key is not automatically sound — if its primes were generated badly, the certificate is only as strong as that key.
Common mistakes
- Assuming a tool that parses a certificate has also validated it — chain building, revocation checks, and signature verification all need more than the single certificate you pasted.
- Treating a self-signed certificate as inherently broken, when every root CA in your trust store is self-signed.
- Relying on commonName for the hostname; browsers require subjectAltName, so a CN-only certificate fails validation no matter how correct the CN looks.
- Reading a SHA-1 signature as merely dated rather than broken — collisions are practical, so the signature no longer firmly binds the certificate to its contents.
- Assuming the key is strong because it is 2048-bit: key size and key generation quality are separate questions.