| Field | Value | Copy |
|---|---|---|
| {{ row.k }} | {{ row.v }} | |
| No details available. | ||
TLS certificates, certificate signing requests, and private keys are separate files, but they are supposed to point back to the same public key identity. When they do not, renewals fail, services refuse to start, or a newly issued certificate cannot be installed with the key you expected to keep.
This matcher helps answer that narrow but important question. It reads a leaf certificate, optionally reads a CSR and an RSA private key, then tells you whether the supplied material lines up at the public-key level instead of leaving you to compare fingerprints by hand.
That is useful during certificate renewal, migration between servers, or cleanup after a hurried key rotation. A common case is inheriting a certificate chain from one system, a saved CSR from another, and a private key from a third place and needing to know quickly which pieces still belong together.
The result is practical rather than ceremonial. You get a match headline, a detail table, short signal notes, and exportable output so you can keep a troubleshooting record or send a concise summary to the person handling the next step.
A clean match does not say anything about trust, hostname coverage, expiry, or whether a certificate authority will issue or renew a certificate. It only says that the compared artifacts expose the same public key. Private keys are still sensitive, so treat the page context carefully and clear the material when you are done.
Start with the certificate you actually plan to deploy. The tool requires a PEM certificate and can also accept a chain, but it always parses the first certificate block it finds and treats that as the leaf certificate for comparison. If the first block is an intermediate instead of the server certificate, the outcome can look wrong even when the later block is the one you meant to test.
From there, add the companion material you want to check. A CSR is useful when you want to confirm that the request you saved during issuance still belongs to the certificate you received. A private key is useful when you are verifying installation readiness, especially after copying files between hosts or restoring from backups.
The upload flow tries to sort pasted or uploaded PEM text into certificate, CSR, and key inputs automatically, and the page also accepts drag and drop. If your CSR was saved without PEM boundary lines, the matcher can wrap the base64 body as a request before parsing it, which saves a cleanup step when all you have is the encoded body.
Encrypted private keys are supported, but there is an important boundary: matcher mode only accepts RSA private keys. Certificates and CSRs can still expose RSA or EC public-key summaries, yet the private-key comparison path depends on reconstructing the RSA public component from the private key values. If you are working with an EC private key, use the certificate and CSR comparison path instead of expecting the private-key check to run.
The matching rule is simple and strict: each artifact is reduced to its SubjectPublicKeyInfo, or SPKI, representation, then the page computes a SHA-256 digest over the DER-encoded SPKI and stores that digest as a base64 pin string. Equality between those SPKI pins is the comparison rule. In plain language, the page is not asking whether the files look similar. It is asking whether they expose the same public key.
That is a better fit than comparing file text directly because certificates, CSRs, and keys have different outer structures. A certificate carries subject and validity data, a CSR carries subject data plus a self-signature, and a private key carries secret material. The shared point is the public key itself, which is why SPKI-based comparison is the reliable common denominator.
When a CSR is present, the page also verifies the CSR signature before it reports the result. That check does not prove the request is approved or safe for production, but it does confirm whether the CSR validates against its embedded public key the way a well-formed PKCS #10 request should.
| Artifact | What the page extracts | Important limits |
|---|---|---|
| Certificate | First CERTIFICATE block, subject common name, key summary, SPKI pin | The first parsed certificate is treated as the leaf certificate even if a chain is pasted. |
| CSR | Subject common name, signature verification result, SPKI pin | A bare base64 body can be wrapped as PEM before parsing. |
| Private key | RSA key summary, encrypted flag, SPKI pin derived from the RSA public component | Private-key matching is RSA only in this bundle. |
The overall headline is derived from certificate-based comparisons. If a CSR is present, the page compares certificate versus CSR. If a private key is present, it compares certificate versus key. When both are present, it also reports CSR versus key in the detail output. The headline becomes MATCH only when every available certificate comparison succeeds. Otherwise it becomes MISMATCH. With no companion material, it stays PARTIAL.
The detail table exposes the common name, key summaries, SPKI pins, pairwise yes-or-no comparison fields, and any warning text. That table can be copied as CSV, downloaded as CSV, or exported as a DOCX report. The JSON tab exposes the same result object in structured form so you can archive the comparison or hand it off to someone who prefers raw data.
All parsing and comparison logic runs in the browser. The bundle does not call a helper endpoint, store the pasted material in browser storage, or send the certificate, CSR, passphrase, or private key to a site-owned server. The privacy caveat is simpler: you are still handling sensitive key material inside a web page, and the cryptographic parsing script is loaded before the comparison starts.
MATCH means the supplied certificate and companion material reduce to the same public key identity. In practice, that means the certificate belongs with that CSR, that RSA private key, or both.
MISMATCH means at least one available comparison against the certificate failed. The most common explanations are the wrong private key, the wrong saved CSR, or a pasted chain whose first certificate is not the intended leaf. A mismatch does not necessarily mean every artifact is wrong. It means at least one of the supplied pieces does not belong with the certificate you tested.
PARTIAL means the certificate parsed successfully but there was nothing else to compare. That state is useful when you only want to inspect the certificate common name, key summary, and SPKI pin before gathering the CSR or key.
| Output | How to read it |
|---|---|
| CSR Verified = Yes | The CSR self-signature validated against its embedded public key. |
| CSR Verified = No | The CSR parsed, but its signature did not verify. Treat the request as malformed, altered, or otherwise unreliable. |
| Certificate CN observed | A convenience label from the certificate subject, not the actual matching rule. |
| Encrypted key path used | The key was decrypted in the browser before the RSA comparison was made. |
The common name is descriptive, not decisive. Two artifacts can show familiar names and still mismatch because the public keys differ. The SPKI-based comparison is the real test.
Renewal sanity check. You paste the newly issued certificate and the CSR that was generated during renewal. The page reports MATCH, the CSR verifies, and the SPKI pins are identical. That tells you the request and certificate still belong together.
Wrong private key after a migration. You restore a certificate and a private key from different backup folders. The certificate parses, the key parses, but certificate versus key is No. That is the classic sign that the wrong RSA key was copied into place.
Chain pasted in the wrong order. You paste an intermediate certificate first and the leaf certificate second. The page uses the first CERTIFICATE block as the comparison target, so the result looks like a mismatch even though the later block may have been the one you meant to test. Reordering the chain fixes the confusion.
No. It only proves that the compared artifacts expose the same public key. Trust, hostname coverage, validity dates, and chain correctness are separate checks.
Certificates and CSRs can show EC key summaries, and certificate-versus-CSR matching works through the public key. The private-key matcher itself is RSA only in this bundle.
The parser uses the first CERTIFICATE block as the comparison target and reports a partial result unless you also supply a CSR or private key.
Yes. The matcher can wrap a bare request body with standard CSR boundaries before parsing it.
The comparison logic in this bundle runs in the browser and does not post the pasted material to a helper endpoint. You should still handle private keys carefully because they are being processed inside a web page context.