Certificate Diff

Why compare two certificates

A renewed certificate looks the same as the one it replaces — until a client fails. Renewals now happen every few months and soon every few weeks: the CA/Browser Forum has cut the maximum lifetime of public TLS certificates to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Each renewal is a chance for something to change quietly: a name dropped from the order, a new key, a different intermediate CA, a usage the CA no longer includes. Comparing the certificate in production with its successor before the switch catches those changes while they are still harmless.

How the comparison works

Both certificates are decoded in your browser — nothing is uploaded — and compared field by field as defined in RFC 5280: version, serial number, subject and issuer names, validity dates and the resulting lifetime, the public key (as the SHA-256 of its SubjectPublicKeyInfo) and its type, and the signature algorithm. Extensions are compared both by meaning and as raw bytes:

• Lists are compared as sets. The subject alternative names, key usages, extended key usages, certificate policies, CRL distribution points and the OCSP and CA-issuer URLs of the Authority Information Access extension are sorted before they are compared, so a reordered list is not a change. When a list did change, the diff shows exactly which entries exist only in the first and only in the second certificate.
• Every extension is matched by its OID, so one that was added, removed, re-encoded or switched between critical and non-critical shows up even when the tool has no dedicated field for it.
• Signed certificate timestamps (RFC 6962) differ in every certificate by nature; only their presence and count are compared.

From the names, the key and the dates the diff also tells you how the two certificates relate: identical, a renewal (same names, a later validity period), a re-issue (same names and start date — typically a replacement after a key compromise or a CA error), a cross-sign (the same subject and key signed by a different issuer, the way ISRG Root X1 was once cross-signed by DST Root CA X3), or certificates for different names altogether.

Changes that break clients

The notes under the headline point out the differences that tend to cause outages:

• Names no longer covered. A host name in the old certificate but not in the new one fails with errors such as certificate is valid for X, not Y the moment the new certificate is deployed. This is the most common renewal mistake: the order was placed from an outdated list of names.
• A new key pair. Normal and often desirable, but any public-key pin in a mobile app or an API client must already include the new key, or those clients stop connecting. The SPKI pin generator computes the pins of both certificates.
• A different issuer. The server must now send the new intermediate certificate; a server that still sends the old one triggers unable to get local issuer certificate in OpenSSL-based clients.
• Dropped extended key usages. Root programs now require dedicated TLS server hierarchies, so many CAs have stopped including the clientAuth usage in server certificates. A certificate that was also used for mutual TLS as a client will no longer work in that role.
• OCSP and Must-Staple. Let's Encrypt removed OCSP URLs from its certificates and shut its responders down in 2025, and other CAs are following; revocation is now published through CRLs (OCSP and CRL in 2026). A certificate that gains or loses the OCSP Must-Staple extension changes what the server has to do on every handshake.
• Key type, signature algorithm or CA status. A move from RSA to ECDSA, or a certificate that suddenly is or is not a CA, deserves a second look before it reaches old clients.

Using it

Paste the older certificate on the left and the newer one on the right, as PEM or as DER in base64 or hex, or open the files. When a box holds a whole chain, its first certificate — the server's own — is compared. If you swapped them, the diff says so, and the Swap button turns the comparison around. By default only differences are listed; tick "Show unchanged fields too" for a full side-by-side view. Both certificates are public data, so a share link carries them in full — in the URL fragment, which browsers never send to a server.

To read one certificate in detail, use the certificate decoder; to confirm that a renewed certificate fits the private key on your server, the key, certificate and CSR matcher.