Certificate & CSR Decoder

What “trusted” actually means

A certificate is trusted when a chain of signatures leads from it to a root certificate your software already trusts. The decoder builds that chain from what you paste: it checks each signature, the validity dates, that every issuer is allowed to act as a CA, and that the last link is in the bundled Mozilla root store, the list Firefox and most Linux systems use.

The most common production fault is a missing intermediate certificate. Browsers often hide it, because they cache intermediates or download them from the URL inside the certificate, so the site works in Chrome but fails in curl, Java, Python or on Android. Paste exactly what the server sends (the “Get the chain from a server” command does this) and a gap shows up immediately.

Host names, lifetimes and the lint

Browsers match the host name only against the Subject Alternative Name list; the Common Name has been ignored for years (RFC 9525). Type a host name to see whether a certificate covers it, including how wildcards match one label only.

Publicly trusted TLS certificates follow the CA/Browser Forum Baseline Requirements. Their maximum lifetime is shrinking: 398 days before March 2026, 200 days now, and 47 days by 2029. The lint flags lifetimes over the limit for the issue date, weak keys, missing extensions and other rules a CA should never get wrong — useful for private CAs, which are not audited.

Revocation without the network

This page cannot connect anywhere, so it never asks an OCSP responder. Paste the CA’s CRL instead and the decoder checks the serial number against it and verifies the CRL’s signature. CRLs matter more again since Let’s Encrypt stopped running OCSP in 2025 and browsers rely on CRL-based revocation lists.