Certificate & Private Key Matcher

Paste the certificate a server is using and the private key you are about to deploy with it, and this page answers the question a deployed site fails on: did the two come from the same key pair? The answer is not a guess from modulus lengths or fingerprints alone — the page signs a fixed challenge with the private key and verifies that signature with the public key inside the certificate. If the verification passes, the two belong together; if it fails, no amount of editing the configuration will make them work. Both readings are shown side by side with the algorithm, key size, subject key identifier and public key fingerprint, and nothing you paste leaves the browser.
1. Certificate or chain
Paste as many blocks as you like. Every certificate is checked against every key, so a chain plus one key tells you exactly which certificate in the chain that key belongs to — a common surprise on a server that is serving the wrong certificate from a bundle. PEM, a bare base64 or hexadecimal body and a PKCS#7 .p7b file are all read; the certificate checker audits the certificate itself once the key is settled.
2. Private key, or the public key
PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY) and a bare SPKI public key (BEGIN PUBLIC KEY) are all understood, as is a key file pasted as base64 or hexadecimal. An encrypted PKCS#8 key (BEGIN ENCRYPTED PRIVATE KEY) cannot be read by a browser and is reported as such, with the command that removes the passphrase.
nothing checked yet
The sample is a self-signed certificate and the private key that belongs to it, both made for this page and protecting nothing. Replace the key with any other key to see the other verdict, or drop the public key block in place of the private one to see the public key match.
A private key pasted into any web page deserves a second thought first. This page is one file of plain JavaScript, it loads nothing from anywhere and it makes no request, so the key is read, used and forgotten inside this tab. That is still a promise made by code you can read rather than a guarantee from a network you can see: if you are handling a production key, work offline, and consider that the safest check is the same openssl command on your own server. A key pasted here is never stored, never put in a file, and never sent anywhere — including by the export buttons, which write findings about the key and never the key itself.
Why signing is the answer. Two files can look alike and still be a mismatch: RSA keys are compared by modulus in most guides, but that only works for RSA, and a key can carry the right modulus with a damaged exponent or wrong padding. This page proves the pair the way a handshake does — sign a fixed challenge with the private key, verify it with the public key in the certificate — so the verdict holds for RSA, ECDSA and Ed25519 alike. When only the public half is pasted, the public key bytes themselves are compared with the ones in the certificate, which is equally conclusive for identity, just without proof that anyone holds the private half.

What a match does not tell you. That the key is the one actually loaded by the server, that the certificate is trusted, that the key file is intact on disk, or that the key has not been copied by someone else. It also cannot say whether the certificate is the one a client will receive, since a load balancer or a CDN in front of the site may serve a different one. To check what a live server really presents, run openssl s_client -connect example.com:443 -servername example.com -showcerts and paste that output into the certificate box.

Where the files come from. The certificate is whatever your server is configured with, or the one exported from a browser or taken out of a .p7b bundle. The private key is the file your web server reads at start up, typically something like privkey.pem or server.key. If your key is encrypted, decrypt a copy first with openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-plain.pem and paste that, then delete the copy.
Match report
Nothing checked yet. Paste a certificate and a key above and press Check whether they match. The verdict appears here with the evidence behind it, and the report can be copied or saved.
The same check with openssl, on your own machine
# public key inside the certificate openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 # public key inside the private key openssl pkey -in key.pem -pubout | openssl pkey -pubin -outform DER | openssl sha256 # the two digests are equal only when the pair belongs together # the older RSA only way: compare moduli openssl x509 -in cert.pem -noout -modulus | openssl md5 openssl rsa -in key.pem -noout -modulus | openssl md5
The digest comparison works for every key type and matches what this page reports as the public key fingerprint, while the modulus comparison only exists for RSA. Neither of them proves that anyone holds the private half — the signing check above does, which is why this page uses it.
What the report holds. The verdict, the pair of readings it came from (algorithm, key size, curve, subject key identifier and public key fingerprint for the certificate and for the key), and the exact test that was run. The report never contains the private key itself: the key is used to produce a signature and is not written into the text, the JSON or the clipboard. What you copy or save is safe to attach to a ticket; the key you pasted is not, and you should treat the clipboard as the only other place it ever existed.

Privacy: the certificate and the key are read inside the tab, nothing is uploaded, and the page makes no request at all — there is no probe and no lookup on this page. To create a matching pair use the self-signed certificate generator; to ask for a certificate for a key you already have, use the CSR generator; to read what a certificate contains, use the certificate decoder.