How to Compare Two SSL Certificates
When you renew a certificate, migrate a domain, or audit an infrastructure, you often need to compare two SSL certificates to see what actually changed. The difference may be a single field, or it may be a completely different chain. This guide shows how to compare two SSL certificates side by side: decode them, check the fields that matter, and use OpenSSL to do the diff automatically.
Why compare SSL certificates
Certificates look similar at a glance, but the details matter. Comparing them answers practical questions:
- Is the renewal actually the same certificate, or a new key and a new issuer?
- Did the subject alternative names (SANs) change when the domain list was updated?
- Is the replacement certificate still valid, and for how long?
- Did the key strength or the signature algorithm improve?
You can answer all of these with two files and a few OpenSSL commands.
Decode both certificates
First, get both certificates into PEM files. If you have the files already, skip this step. To pull a live certificate from a server:
openssl s_client -connect example.com:443 -servername example.com \
-showcerts < /dev/null 2> /dev/null | openssl x509 -outform PEM > cert-old.pemRun the same command against the other server or the same host to get cert-new.pem. If a certificate arrives with extra chain certificates, keep only the leaf certificate for the comparison.
Compare the subject and issuer
The subject identifies who the certificate belongs to; the issuer identifies who signed it. Print both fields for each file:
openssl x509 -in cert-old.pem -noout -subject -issuer
openssl x509 -in cert-new.pem -noout -subject -issuerWatch for these changes:
- Subject — the common name (CN) or organization may change after a company rename or a move to a different domain structure.
- Issuer — a switch between issuers means a different trust path, and possibly a different root that clients must trust.
Check the validity period
Validity determines whether a certificate is usable right now and how much time remains:
openssl x509 -in cert-old.pem -noout -dates
openssl x509 -in cert-new.pem -noout -datesCommon problems: the new certificate has not started yet (notBefore is in the future), or it expires sooner than the old one. Compare the notAfter dates to confirm the renewal actually extends coverage.
Compare key strength and signature algorithm
Key strength and the signature algorithm directly affect security. Older certificates commonly use RSA-2048 with SHA-256; newer ones may use ECDSA or RSA-3072/4096.
openssl x509 -in cert-old.pem -noout -text | grep -A1 "Public-Key"
openssl x509 -in cert-old.pem -noout -text | grep "Signature Algorithm"
openssl x509 -in cert-new.pem -noout -text | grep -A1 "Public-Key"
openssl x509 -in cert-new.pem -noout -text | grep "Signature Algorithm"A downgrade in key length or an outdated signature algorithm (such as SHA-1) is a red flag even when every other field matches.
Compare subject alternative names
The SAN list decides which hostnames the certificate actually covers. This is the most common reason a certificate breaks a site after renewal:
openssl x509 -in cert-old.pem -noout -ext subjectAltName
openssl x509 -in cert-new.pem -noout -ext subjectAltNameMissing domains, extra domains, and wildcard changes all show up here. Compare the full list, not just the common name.
Compare fingerprints
A fingerprint is a short hash of the whole certificate. Two certificates with the same fingerprint are byte-for-byte identical:
openssl x509 -in cert-old.pem -noout -fingerprint -sha256
openssl x509 -in cert-new.pem -noout -fingerprint -sha256If the fingerprints differ but the visible fields look the same, the difference is in a field you did not print — commonly the public key, serial number, or extensions. In that case the certificates are not identical even if the subject matches.
Automate the comparison
For a quick scripted diff, extract the fields into a file and compare them:
for f in cert-old cert-new; do
openssl x509 -in $f.pem -noout \
-subject -issuer -dates -fingerprint -sha256 \
-ext subjectAltName > $f.summary.txt
done
diff cert-old.summary.txt cert-new.summary.txt || trueThe output shows exactly which lines changed. Add the public key check when you need to confirm whether the private key changed:
openssl x509 -in cert-old.pem -noout -pubkey | openssl sha256
openssl x509 -in cert-new.pem -noout -pubkey | openssl sha256Common questions
Why do two certificates with the same subject have different fingerprints? The fingerprint covers the entire certificate, including the public key, the serial number, and the validity dates. Any of those changes produces a different fingerprint.
Is a different issuer always a problem? Not necessarily. Many hosts move between intermediate certificates from the same root, or between roots that are equally trusted. Check whether clients trust the new chain before switching.
Can I compare certificates without OpenSSL? Yes, but OpenSSL is the most reliable tool on Linux and macOS. Online decoders and browser views are convenient for reading one certificate; a scripted diff is still the fastest way to compare two.
Next steps
Start by decoding both certificates and comparing subject, dates, and SANs. Add the fingerprint and public-key checks when you need proof that nothing else changed. For regular renewals, keep the summary output from the last certificate so the next comparison takes one command.
