SSL Matcher (Certificate, CSR, and Key)
Compare a TLS certificate with a CSR or RSA private key in your browser, using exact SHA-256 SPKI identity checks without uploading secrets.{{ summaryHeading }}
{{ summaryLine }}
| Comparison | Result | Evidence | Next action | Copy |
|---|---|---|---|---|
| {{ row.comparison }} | {{ row.result }} | {{ row.evidence }} | {{ row.next_action }} |
| Artifact | Field | Value | Copy |
|---|---|---|---|
| {{ row.artifact }} | {{ row.field }} | {{ displayDetailValue(row) }} |
Introduction
A certificate renewal can fail at deployment even when every file looks valid on its own. The certificate may have been issued from one certificate signing request (CSR) while the server is configured with a different private key, or files from two hosts may have been mixed during a handoff. The decisive question is whether the public key inside each artifact is the same.
An X.509 certificate contains a subject public key along with identity, issuer, serial-number, and validity information. A PKCS #10 CSR also contains a public key, plus a self-signature made with the corresponding private key. The private key holds the secret material from which its public half can be derived. A valid pairing therefore does not require comparing secret values; it requires comparing equivalent public-key identities.
- Certificate
- The issued identity document. Its public key must match the key used by the service.
- CSR
- The request sent to a certificate authority. Its public key records which key pair the request was made for.
- Private key
- The secret signing and decryption material. It should be handled only in an approved environment.
- SPKI fingerprint
- A SHA-256 digest of the standard SubjectPublicKeyInfo encoding, displayed as a compact public-key identity.
Exact public-key equality is stronger than comparing certificate names, serial numbers, or key sizes. Two unrelated RSA keys can have the same size, and a certificate renewal may keep the same key while changing its serial number and dates. Conversely, a certificate and CSR can name the same host yet contain different public keys.
A key match answers only the pairing question. It does not prove that a certificate is within its validity period, trusted by a client, issued for the required hostname, allowed for the intended purpose, unrevoked, or installed with the correct intermediate certificates. Those checks remain part of certificate validation and deployment review.
The private key is the sensitive artifact in this workflow. Comparing derived public-key fingerprints is safe for a change record, but pasting the private key itself is appropriate only when the browser session and device are trusted.
How to Use This Tool:
Start with the leaf certificate, then add whichever peer artifacts need to be proved against it.
- Paste or load the Certificate PEM. Each loaded file must be no larger than 150,000 bytes, and each text editor accepts up to 150,000 characters. If the file contains a chain, place the leaf certificate first because only the first complete certificate block is compared.
- Add the optional CSR PEM, RSA private key PEM, or both. A CSR may be a complete PEM block or bare base64 text; a private key must be a supported RSA PKCS #1 or PKCS #8 PEM key.
- Enter the Key passphrase only when the RSA key is encrypted. An incorrect passphrase or unsupported encryption leaves the result not ready.
- Read the main verdict, then check every relationship in Match evidence. A mismatch in any supplied pair means the files should not be deployed together.
Interpreting Results:
- All supplied material matches means every comparison that could be formed from the supplied certificate, CSR, and private key has the same complete SHA-256 SPKI fingerprint.
- Mismatch found means at least one pair has a different public-key identity. Stop the handoff and locate the certificate, CSR, or key from the same issuance path.
- Peer material needed means the certificate parsed, but no CSR or private key was supplied. Certificate details alone cannot prove a pairing.
- A failed CSR self-signature is a separate warning. Even if its public key matches another artifact, the CSR itself should be regenerated or independently checked.
Technical Details:
SubjectPublicKeyInfo (SPKI) is the standard structure that carries a public-key algorithm identifier and the public-key bits. Encoding each public key in this same structure removes the superficial differences between a certificate, a CSR, and a private-key file.
Rule Core
The comparison reduces every available artifact to one canonical public-key identity. The result is binary: the full fingerprints are identical or they are not.
| Stage | Rule | Failure meaning |
|---|---|---|
| Parse | Read the first X.509 certificate, optional PKCS #10 CSR, and optional RSA private key. | Malformed, incomplete, encrypted-without-passphrase, or unsupported material cannot be compared. |
| Derive | Take the public key directly from the certificate and CSR; derive the RSA public half from the private key. | A private key without supported RSA parameters is outside this checker's scope. |
| Canonicalize | Encode each public key as DER SubjectPublicKeyInfo. | Artifact wrappers and PEM line breaks no longer affect identity. |
| Fingerprint | Hash the DER bytes with SHA-256 and encode the digest in base64 with the sha256/ prefix. | Any changed public-key byte produces a different fingerprint. |
| Decide | Require exact string equality for certificate-to-CSR, certificate-to-key, and CSR-to-key comparisons that exist. | One unequal pair makes the overall verdict a mismatch. |
The relationship profile uses 100% for an exact fingerprint match and 0% for a mismatch. These values are categorical evidence, not a similarity score; cryptographic keys do not become usable together because they are partly similar.
The certificate is required. The CSR and private key are optional, so one peer creates one comparison and both peers create three. A certificate chain may contain several PEM blocks, but only the first block supplies the compared public key; the remaining count is reported as a warning.
CSR self-signature verification proves that the request was signed by the private key corresponding to the public key embedded in that request. It does not prove that a certificate authority approved the request or that the issued certificate is trustworthy.
Fingerprint preview length changes only what is visible on screen. Comparisons and exported evidence retain the complete SPKI fingerprints.
Privacy Notes:
The certificate, CSR, private key, and passphrase are parsed in the current browser session and are not placed in the share URL. Local processing reduces transmission risk, but it does not make an untrusted device, browser extension, screen recording, clipboard, or exported report safe.
- Use a controlled workstation for production private keys and close the page when the comparison is finished.
- Do not include the private key or passphrase in tickets, chat, screenshots, or exported evidence.
- A shared SPKI fingerprint exposes public-key identity, not the private key, but it can still link records that use the same key.
Worked Examples:
Renewal with the existing key
A newly issued leaf certificate and the server's current RSA key produce identical certificate-to-key SPKI fingerprints. The pairing is valid, but the operator still verifies hostname coverage, dates, chain construction, and service configuration before deployment.
CSR from the wrong host
The certificate matches the private key, while the CSR fingerprint differs from both. The certificate and key belong together; the supplied CSR came from another key pair and should not be kept as evidence for this issuance.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF, May 2008.
- RFC 2986: PKCS #10 Certification Request Syntax Specification, IETF, November 2000.
- RFC 7469: Public Key Pinning Extension for HTTP, IETF, April 2015.
- How to check whether a certificate matches a private key using OpenSSL, Simplified Guide.
- How to verify a certificate chain using OpenSSL, Simplified Guide.