{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Accepts PEM, bare base64 PKCS#10, or one binary DER file up to 1 MiB. A certificate or private key fails closed.
{{ sourceStatus }}
Auto recognizes standard and legacy request labels, then falls back to bare base64 DER. The resolved format is recorded in the review brief.
Optional. URLs are reduced to their hostnames; trailing dots and letter case are ignored.
Off by default. SHA-256 remains visible and is the preferred comparison fingerprint.
{{ params.include_legacy_hashes ? 'Enabled' : 'Disabled' }}

Issuance review brief

{{ briefHeading }}

{{ briefSummary }}

{{ row.label }}
{{ row.value }}
{{ row.state }}
{{ row.check }}
{{ row.detail }}
Request material

These handoffs contain public request or public-key material. They never contain the private key.

{{ normalizedPem }}

Public JWK

{{ publicJwkJson }}

Public JWK export is unavailable for this key type.

TypeRequested identityExpected-name checkCopy
{{ row.type }}{{ row.value }}{{ row.expected_status }}
No Subject Alternative Name entries were found.

Requested identity ledger

These are requested identities, not proof that a certificate authority will validate or issue them.

Readiness check profile

How many local checks pass, need review, or are informational before the request reaches CA policy review?

ACME DNS Challenge Readiness Check Check ACME DNS-01 readiness before retrying issuance with exact TXT matching, delegation-path validation, and public-resolver cache hints.
Certificate Inventory Expiry Checker Review a certificate inventory CSV locally to rank renewal urgency and flag ownership, manual-process, invalid-date and public-lifetime risks.
Certificate Signing Request (CSR) Generator Generate a PKCS#10 RSA CSR and matching private key in your browser, with SAN review and optional encrypted PKCS#8 key export.
Alternative DCV Checker Check alternative certificate DCV proofs across DNS and web paths, including CSR-derived values and per-host mismatch or transport evidence.

A certificate signing request (CSR) is the public handoff between a private-key holder and a certificate authority. It contains the requested identity, a public key, optional attributes and extensions, and a signature created with the corresponding private key. The private key should remain with its owner and is not part of a normal PKCS #10 request.

Review matters because a syntactically valid CSR can still ask for the wrong certificate. A copied request may contain an old hostname, omit a Subject Alternative Name (SAN), use a weak key or legacy digest, or carry extensions that do not fit the intended service. Those mistakes are easier to correct before issuance than after a certificate has entered a deployment workflow.

CSR evidence Useful conclusion Important limit
Self-signature The request was signed with the private key matching its embedded public key. It does not prove domain control, identity, or CA approval.
SAN entries The DNS names or IP addresses requested for the certificate are visible. The issuer may reject, validate, remove, or change requested extensions.
Public-key details The key type, size, or curve can be compared with a policy baseline. A strong public key does not establish who controls the private key now.
Fingerprint Two parties can compare exact CSR or public-key bytes. A fingerprint does not make the contents trustworthy.

For normal TLS service identity, SAN entries carry the DNS names and IP addresses that clients use. A familiar common name is not a safe substitute for a missing SAN. Wildcards also have a narrow meaning: *.example.com can cover one label such as www.example.com, not example.com itself or a deeper name such as a.b.example.com.

CSR review is a pre-issuance check, not a certificate validation. Certificate-authority policy, authorization, domain-control validation, final extensions, validity dates, and trust chains are decided later. Keep the private key protected even when the request itself is safe to share with an intended issuer.

How to Use This Tool:

Compare the request with the certificate you intend to obtain, not merely with the text printed in the CSR's subject.

  1. Paste or load one PEM request, or provide bare base64/DER text. Use auto detect unless the expected input form is already known.
  2. Enter the DNS name, IP address, or URL hostname that the certificate must cover. This adds a direct comparison against DNS and IP SAN entries.
  3. Review the self-signature, key strength, digest, SAN presence, common-name alignment, requested usage, and challenge-password checks.
  4. Inspect the requested-name ledger and confirm every identity needed by the service. A Common name only result still needs correction for ordinary modern TLS identity.
  5. Compare the SHA-256 fingerprints with a trusted handoff record before submission. Enable legacy hashes only when an older process explicitly requires them.
If the input is reported as a certificate or private key, stop and select the CSR instead. Never paste a private key into a certificate-request decoder.

Interpreting Results:

Ready for CA policy review means none of the local readiness rules produced a review warning. It does not predict issuance. Review before submission means at least one concrete condition—such as a failed self-signature, missing SAN, weak key, legacy digest, expected-name mismatch, or challenge password—needs attention.

Read informational rows separately from warnings. An unclassified key type or absent server-auth request can be informative without making the CSR invalid. The intended issuer's profile determines whether a particular extension should be present.

A matching expected name is strongest when it appears in a DNS or IP SAN. The comparison accepts exact names and one-label DNS wildcards. Confirm the complete SAN list as well; matching one expected name does not prove that every required service identity is present.

Technical Details:

PKCS #10 wraps certification-request information and a signature in an ASN.1 structure. PEM is a textual boundary and base64 representation of the same DER bytes. Decoding recovers the subject, Subject Public Key Info (SPKI), requested attributes and extensions, and signature algorithm before applying readiness rules.

Transformation Core

Stage Rule Evidence produced
Normalize Accept standard or NEW CERTIFICATE REQUEST PEM boundaries, or bare base64/DER text, and reject certificate or private-key labels. Canonical request PEM and DER bytes
Decode Read subject attributes, public-key information, signature, extension request, SAN, key usage, extended key usage, basic constraints, and challenge password. Human-readable request facts
Verify Check the CSR self-signature against the public key embedded in the request. Internal signature consistency
Compare Normalize the expected hostname or IP address and compare it with DNS or IP SAN entries. SAN match, common-name-only, or no-match status

Rule Core

Check Pass or information rule Review rule
Self-signature Signature verifies with the embedded public key. Verification fails.
RSA key Size is at least 2,048 bits. Size is below 2,048 bits.
EC key Curve is not on the local legacy list. P-192 or P-224 family curve is detected.
Signature digest The decoded digest is not SHA-1 or MD5. SHA-1 or MD5 is detected.
SAN At least one SAN entry is present. No SAN extension is found.
Common name The common name also appears in a DNS or IP SAN. It is absent from SAN, or no SAN exists.
TLS usage serverAuth and digitalSignature are requested together. serverAuth is requested without digitalSignature.
Challenge password No challenge-password attribute is present. The attribute is present and may expose enrollment text.

Ed25519 and Ed448 are recognized as modern key types. Other decoded key types remain informational rather than being forced into a pass or warning. A ready status requires zero review rows; informational rows do not block it.

Fingerprint Mechanism

The CSR SHA-256 fingerprint hashes the complete DER request, so any changed subject, extension, key, or signature changes the digest. The SPKI SHA-256 fingerprint hashes only the public-key structure and remains stable across CSRs that reuse the same public key. The SPKI pin is the base64 form of that SHA-256 digest. Optional SHA-1 and MD5 fingerprints are compatibility aids, not preferred security comparisons.

Privacy and Security Notes:

The CSR is decoded in the browser and is not submitted to a certificate service. A CSR is normally public material, but its subject, SAN entries, organization details, email address, and challenge-password attribute can still be sensitive. Share it only with the people and systems involved in issuance.

The request must never be used as evidence that a private key is safely stored. Self-signature verification proves that the matching private key signed the request at creation time; it cannot show where that key resides, whether it was copied, or whether it remains under the right operator's control.

Worked Examples:

Expected web name missing from SAN

Enter api.example.com as the expected DNS name for a request whose common name is api.example.com but whose SAN contains only www.example.com. The self-signature may verify, yet the expected-name result is Common name only and the common-name alignment check needs review. Regenerate the CSR with the API name in SAN.

Wrong PEM object

Pasting a block labeled CERTIFICATE or PRIVATE KEY stops before decoding. Select the request file instead. This prevents certificate facts from being mistaken for requested facts and, more importantly, avoids exposing a private key in the wrong workflow.

References: