Does this private key belong to this certificate?

It happens at the worst time: you renew a certificate, upload it to the load balancer, and TLS dies with 'key values mismatch'. Somewhere between the CSR you generated three renewals ago, the key on the deploy box and the fullchain.pem your CA emailed you, the pair got scrambled. Keys and certificates look identical in a directory listing — same .pem extension, same wall of base64 — and nothing about the filenames tells you which ones were born together.

Cryptographically, the answer is simple. A private key and a certificate match when the public key embedded in the certificate is exactly the public half of that key pair — for RSA, the same modulus and exponent; for ECDSA, the same point on the same curve. The classic recipe hashes the modulus three ways and compares: openssl rsa -modulus -in server.key -noout | openssl md5, the same with openssl x509 for the certificate, and openssl req for the CSR. Identical hashes mean one key pair. This tool performs that same comparison in your browser for RSA, ECDSA and Ed25519, across a whole mixed paste at once — including fullchain.pem bundles, where the CA certificates are expected not to match and are grouped neutrally instead of alarming you.

Open the free SSL Certificate Key Matcher — no signup, runs entirely in your browser.

How to use it

1. Paste everything you have in one go — the private key, one or more certificates, a CSR, even an entire fullchain.pem — or drop the file onto the input.
2. Check the blocks-found list: every block is classified by position (key #1, cert #2, CSR #3) with its identity, and CA certificates are labeled so a fullchain paste reads correctly.
3. Read the verdict cards: each key gets one card listing every certificate and CSR with a clear MATCH or a does-NOT-belong-to line — the mismatch wording leads, because that is the panic query.
4. If a key is reported as encrypted, decrypt it first with openssl rsa -in key.pem -out key-decrypted.pem (or openssl pkcs8 for PKCS#8); OpenSSH keys convert with ssh-keygen -p -m PKCS8 -f <key>.
5. Hit Clear when done — nothing is stored, so closing the tab works too, but the button wipes input and results immediately.

Why this one

• Mixed bundles just work: legacy PKCS#1 RSA and SEC1 EC keys are re-wrapped to PKCS#8 locally, EC PARAMETERS blocks from ecparam -genkey are skipped quietly, and one garbage block never fails the paste.
• Fullchain-aware: leaf, intermediates and root are classified via basicConstraints, and CA certificates group under a neutral 'not expected to match' section rather than showing up as red failures.
• Honest about limits: a match proves same-public-key only — expiry, hostname coverage and chain trust are separate checks, and the tool links you to the Certificate Decoder for those instead of implying validity.
• Key material never leaks: everything runs on WebCrypto in your browser, blocks are labeled by position only, errors never echo key bytes, and the input collapses after parsing so screenshots stay clean.

Frequently asked questions

Does a match mean my certificate is valid?

No. A match only proves the key and certificate share the same public key — it says nothing about whether the certificate has expired, whether it covers your hostname, or whether its chain builds to a trusted root. Those are independent checks; run the certificate through the Certificate Decoder for validity windows, SANs and chain signatures.

Is it safe to paste my private key here?

Yes, and this is one of the few places where that sentence is defensible: the matching runs entirely in your browser with WebCrypto. The key never touches the network — there is no API call at all — it never appears in error messages or analytics, and nothing is written to local storage. Verify it yourself in the network tab: paste a key and watch zero requests fire.

Why does my fullchain.pem show 'does not match' for two of the three certificates?

Because that is correct — a fullchain contains your leaf certificate plus the intermediates and root that signed it, and those CA certificates hold their own keys, not yours. The tool detects CA certificates via basicConstraints and files them under a neutral 'not expected to match your key' section. Only the leaf should match your key; if the leaf does not match, you grabbed the wrong key or the wrong chain file.

My key says 'encrypted — decrypt with openssl first'. What do I do?

Encrypted keys (ENCRYPTED PRIVATE KEY headers, or Proc-Type: 4,ENCRYPTED inside a traditional RSA key) are never attempted — attempting would mean asking for your passphrase, and that is a habit nobody should build. Decrypt locally with openssl rsa -in key.pem -out key-decrypted.pem for RSA keys or openssl pkcs8 -in key.pem -out key-decrypted.pem for PKCS#8, then paste the decrypted output. OpenSSH-format keys convert with ssh-keygen -p -m PKCS8 -f <key>.