Certificate & Key Matcher

Drop in any mix of certificates, private keys and CSRs — PEM or DER — and this workbench proves which key matches which certificate, orders certificates into a chain, converts formats and generates CSRs. Private keys never leave your browser: everything is parsed locally in this tab, keys are held in memory only and are never uploaded, logged or stored, and this page makes no network request. For decoding one certificate in depth, use the SSL certificate parser; for a quick self-signed certificate, the self-signed certificate generator.

Add certificates, keys and CSRs

Matching verdict

Add a certificate and a private key and the verdict appears here: which key matches which certificate, proven by an identical public key — never guessed from file names.

Chain builder

With two or more certificates loaded, the builder orders them leaf first, then intermediate(s), then the root, by matching issuer and subject names — and then, where the browser's cryptography allows, it verifies the actual signature on each link instead of trusting the names.

Generate a CSR

A certificate signing request for a key generated here, in your browser: fill in the subject, choose the key type, and download the CSR to send to your CA — plus the private key, which you must store safely yourself. The key is shown only here; this page does not keep it.

How matching actually works

A certificate and a private key are not two halves of one file; they are two files that share one mathematical object. When a key pair is generated, the public half is placed inside the certificate (and inside any CSR made from the key), while the private half stays in the key file. Two items match exactly when they carry the same public key — for RSA, the same modulus and exponent; for EC, the same point on the same curve. This page encodes that public key in its standard wrapper (the SubjectPublicKeyInfo), hashes the encoding with SHA-256, and groups every loaded item by that hash. The hash shown on each card is therefore the evidence, not a summary: identical hashes cannot happen by accident, and a mismatch is just as certain, which is why the verdict can be stated plainly — this key matches this certificate, or no loaded key does. The classic failure this catches is written up in when your key does not match your certificate: the 2 a.m. reload where the renewed certificate on disk belongs to a different key than the one the server has loaded.

File names prove nothing. A directory full of server.crt, server.key, final-v2.pem and a CSR from last year's renewal attempt is the normal state of inherited infrastructure, and the names are archaeology, not documentation. Neither does a matching file extension or a matching date. What about the traditional openssl check — comparing the modulus hash of the certificate against the modulus hash of the key? It is exactly this page's check, limited to RSA and to one pair at a time, and it misses EC keys entirely because EC keys have no modulus. The public-key fingerprint covers every algorithm uniformly, which is why it is the grouping key here.

Chains, order, and what "verified" means

Servers are expected to present the leaf certificate first, then each intermediate in order, so a client can walk issuer-to-subject links up to a root it already trusts. Presenting the same certificates in the wrong order — or with an intermediate missing — produces the classic "unable to get local issuer certificate" family of errors from clients that cannot fetch the missing link themselves. The builder above reconstructs the order from the names alone, which is always possible, and then goes one step further: for RSA and ECDSA signatures it imports the issuer's public key and checks the signature over the certificate's signed bytes. A link labelled signature verified is cryptographically proven. A link labelled name match only is not — the names chain, but the signature uses an algorithm this platform does not check (RSA-PSS is the usual one), and the page says so rather than dressing a name match up as proof. If a signature check fails, the names were a coincidence or a forgery, and the builder shows the failure in red instead of quietly producing a bundle.

Formats: PEM, DER, and the .pfx question

PEM is DER bytes wrapped in Base64 with a labelled header; DER is the raw encoding. Converting between them loses nothing and proves nothing — it is the same object in a different envelope — which is why every card offers both downloads. Windows and some Java tooling prefer DER or PKCS#12; most Unix tooling wants PEM. PKCS#12 (.pfx/.p12) is a different matter: it is an encrypted container with its own integrity MAC, and producing one that every consumer accepts — with protection worth the name — is not something to hand-roll in a web page. This tool deliberately does not offer it. To package a matched pair yourself, run openssl where the files live: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — after this page has told you which key, certificate and chain actually belong together.

Parsing and chaining are hand-rolled DER code written for this site (BSD-style, no third-party parser); hashing, signature verification and key generation use the browser's WebCrypto. No part of this tool makes a network request.

Frequently asked questions

How does the matcher prove a key and a certificate belong together?

By comparing the public key, not the files. Every certificate, CSR and private key yields the same encoded public key (the SubjectPublicKeyInfo); this page hashes it with SHA-256 and groups items whose hashes agree. Identical public key means the private key is mathematically the one the certificate was issued for — the same check openssl performs with its modulus comparison, done for every file at once and for EC keys as well as RSA.

Is it safe to load a real private key into a web page?

On this page, yes, because of how it is built: everything is parsed locally in your browser, keys are held in this tab's memory only, nothing is uploaded, logged or written to any storage, and the page makes no network request. The habit to keep is checking that claim on any tool before pasting a key — and never pasting a private key into a chat, a ticket or a server-side "checker" that processes it remotely.

What does "name match only" mean in the chain builder?

The chain builder orders certificates by matching each certificate's issuer name to the next certificate's subject name, then tries to verify the actual signature with the issuer's public key. Where the signature algorithm is one the browser's WebCrypto can check (RSA and ECDSA in practice), the link is labelled "signature verified" or, if the check fails, "signature FAILED". Anything else — RSA-PSS is the common case — is honestly labelled "name match only": the names line up, but this page did not cryptographically prove the link.

Why is there no PKCS#12 (.pfx) export?

A PKCS#12 file wraps a key and certificate in password-based encryption with MAC integrity — a format that needs careful, well-tested encoding. Rather than ship a hand-rolled version that might produce files other software rejects (or, worse, weakly protected keys), this page converts between PEM and DER and leaves .pfx packaging to openssl: the command is shown on the page so you can run it where the key already lives.

Can this page read an encrypted private key?

It can identify one and say so, but it cannot use it: an encrypted (password-protected) key does not reveal its public key until it is decrypted, and pairing is done on the public key. Decrypt a copy locally with openssl (pkcs8 -topk8 -nocrypt, or rsa/ec) and load the decrypted copy — on a machine you trust, and delete the copy afterwards.