Certificate Signing Request (CSR) Decoder

CSR source format:

Use Auto for normal PEM text; choose DER/base64 only when you copied raw DER bytes after external conversion.

Certificate Signing Request:

Paste PEM or bare base64 PKCS#10, or drop one .csr, .pem, .txt, or DER .der request.

Drop CSR, PEM, TXT, or DER onto the textarea.

Expected DNS name:

Optional. Enter a DNS name such as www.example.com; wildcard SANs are matched one label deep.

Field	Value	Copy
{{ key }}	{{ value }}
No request anatomy fields are available Decode a valid PKCS#10 CSR to inspect subject, key, signature, and fingerprint fields.

Type	Requested name	Expected DNS check	Copy
{{ row.type }}	{{ row.value }}	{{ row.matchLabel }}
No SAN entries found Modern TLS issuance usually expects DNS or IP names in Subject Alternative Name.

Status	Note	Copy
{{ row.status }}	{{ row.note }}

{{ normalizedCsrPem }}

Public JWK is not available

JWK export is available for RSA and named-curve EC public keys.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A certificate signing request is the handoff between a key owner and a certificate issuer. It asks for a certificate without exposing the private key, but the request still carries enough detail to decide whether the request is shaped correctly before it reaches a certificate authority.

Most CSRs are PKCS#10 requests wrapped in PEM text, although the same request can also appear as DER bytes or bare base64. The request contains a subject name, a public key, optional attributes, requested certificate extensions, and a signature made with the matching private key. That signature matters because it shows the request was created by someone holding the private key at the time of signing. It does not prove that the requester controls a domain, owns an organization name, or should receive a publicly trusted certificate.

CSR review usually sits between key generation and certificate issuance. Administrators use it to catch wrong hostnames, missing Subject Alternative Name entries, weak key choices, copied certificate blocks, and stale private-key workflows before a request is sent to a public CA or an internal PKI team. The review is also useful when a ticket says one hostname but the request asks for another.

The most common mistake is trusting the common name too much. Modern TLS name checking is built around Subject Alternative Name entries, especially DNS names and IP addresses. A CSR can have a familiar common name and still be unsuitable for issuance if the SAN extension is missing, incomplete, or different from the hostname the certificate will protect.

CSR anatomy including subject, public key, requested extensions, and signature

CSR parts, review purpose, and common review mistakes
CSR part	Why it matters	Common review mistake
Subject	Names the requester using fields such as common name, organization, country, and email.	Treating a familiar subject as proof of identity without issuer validation.
Subject Alternative Name	Requests DNS names, IP addresses, email addresses, URIs, or other identities for the certificate.	Submitting a server CSR with only a common name and no SAN entry.
Public key	Defines the key that will appear in the certificate if the request is approved.	Accepting weak RSA sizes, legacy curves, or the wrong key for the deployment.
Request signature	Shows that the CSR was signed with the private key matching the embedded public key.	Reading a verified signature as approval to issue the certificate.
Requested extensions	Describe requested certificate behavior such as key usage, extended key usage, and basic constraints.	Assuming every requested extension will be granted unchanged by the issuer.

CSR review is therefore a pre-issuance check, not a certificate validation result. It helps catch malformed input, missing names, weak key material, deprecated signature choices, and policy mismatches early enough to regenerate the request instead of discovering the problem after a CA rejects it or issues a certificate with the wrong identity.

How to Use This Tool:

Start with the CSR material you actually plan to submit or review. The decoder can inspect pasted text, bare base64 PKCS#10 data, and a dropped or selected CSR file.

Leave CSR source format on Auto detect CSR text for ordinary PEM input, including legacy NEW CERTIFICATE REQUEST labels. Use the DER/base64 option only when the request is already represented as DER data or base64 DER text.
Paste the request into Certificate Signing Request, choose a .csr, .pem, .txt, or .der file, drop a file onto the textarea, or load the demo request.
Add Expected DNS name when you want a hostname check. A URL is reduced to its hostname, trailing dots are ignored, and wildcard SANs match only one DNS label below the wildcard.
Press Decode CSR. If an error says the input looks like a certificate or private key, replace it with the public CSR request instead of certificate output or private-key material.
Review Request Anatomy for subject fields, key algorithm and size, signature verification, fingerprints, key usage, extended key usage, basic constraints, and any challenge password.
Open Requested Names to inspect SAN entries and the expected-name match result, then use Readiness Notes for warnings such as missing SANs, weak keys, deprecated digests, failed signatures, CN/SAN mismatch, and challenge-password presence.
Use Request Material, Public JWK, and JSON when you need normalized CSR text, DER or SPKI output, a public JWK for supported RSA or named-curve EC keys, or a structured review record.

For file input, keep the file below 1 MB. If a copied base64 request fails, check for missing lines, extra ticket text, URL-safe base64 characters copied from another system, or a PEM label that is not a certificate request label.

Interpreting Results:

The strongest first-pass result is a verified request signature, a modern key, and at least one SAN entry covering the intended hostname. That combination means the request is internally consistent and likely shaped for normal TLS issuance, but it still needs CA validation and policy review.

CSR output cues, trusted signals, and limits
Output cue	What to trust	What not to overread
Signature verified	The request signature matches the embedded public key.	It does not prove domain control, organizational authorization, or CA approval.
Subject and common name	The distinguished-name fields are visible for review and ticket matching.	A correct-looking common name is not a substitute for SAN coverage in modern TLS.
Requested Names	DNS, IP, email, URI, OID, directory, and other SAN values are separated by type.	A wildcard only covers one label below its suffix, not every deeper subdomain.
Key details	RSA size, EC curve, and key fingerprints help compare the request with another artifact.	A fingerprint identifies bytes; it does not say the request is authorized or policy-compliant.
Readiness Notes	Warnings point to issues worth fixing before submission or approval.	No warning means no common blocker was detected, not that every CA profile will accept the request.

When a hostname is important, compare the expected-name result against the SAN table rather than the subject line alone. If the expected name appears only in the common name, regenerate the CSR with a SAN extension before using it for a public TLS certificate.

Technical Details:

PKCS#10 defines a certification request as request information plus an algorithm identifier and a signature. The request information carries the version, subject, subject public key information, and attributes. One important attribute is the requested extensions set, where a requester can ask for SAN, key usage, extended key usage, basic constraints, and similar certificate behavior.

The signature is calculated over the certification request information, not over a final certificate. That distinction explains why a CSR can verify successfully while still being rejected later. The signature proves possession of the private key for the public key in the request, while issuance depends on identity validation, CA policy, certificate profile constraints, and the issuer's decision about which requested extensions to honor.

Decoding Map:

CSR decoding stages and review outputs
Input or structure	Decoding rule	Review output
PEM request	Recognize `CERTIFICATE REQUEST` or legacy `NEW CERTIFICATE REQUEST` boundaries, remove whitespace, and parse the base64 body as PKCS#10 data.	Normalized PEM, parsed subject, key, signature, attributes, and requested extensions.
Bare base64 request	Wrap valid CSR base64 with standard certificate-request PEM boundaries before parsing.	The same request evidence as PEM input, plus a normalized PEM copy.
DER file	Read binary bytes in the browser, base64-encode them, and wrap them as a certificate request.	PEM and DER review material for the same underlying CSR.
Subject	Decode recognized distinguished-name attributes such as CN, O, OU, L, ST, C, and email address.	Subject common name, full subject string, and individual subject fields.
Requested extensions	Inspect the extension request attribute for SAN, key usage, extended key usage, and basic constraints.	Requested names, requested usage values, CA/basic-constraints flag, and warning notes.
Public key	Classify RSA keys by modulus size and exponent, EC keys by curve, and supported EdDSA keys by type.	Algorithm, size or curve, SPKI material, public-key fingerprint, and JWK when supported.
Signature	Verify the CSR signature against the embedded public key and identify the signature digest when available.	Signature algorithm, digest label, and verification status.

Fingerprint Core:

CSR fingerprint

CSR SHA-256 = SHA-256(DER-encoded CSR)

Public-key fingerprint

SPKI SHA-256 = SHA-256(DER SubjectPublicKeyInfo)

Pin value

pin-sha256 = base64(SPKI SHA-256 bytes)

Readiness Rules:

CSR readiness rules and warning conditions
Rule	Warning condition	Why it matters
Signature	The CSR signature does not verify.	The request may be malformed, altered, or not signed by the matching private key.
RSA key size	RSA modulus is below 2048 bits.	Modern public TLS baselines and cryptographic guidance treat smaller RSA keys as too weak for new use.
EC curve	Curve is a legacy 192-bit or 224-bit curve such as secp192r1 or secp224r1.	These curves do not meet the common modern security-strength baseline for certificate signing.
Signature digest	The request uses SHA-1 or MD5 in the CSR signature.	Deprecated digests are a sign to regenerate the request with a current signing algorithm.
SAN presence	No Subject Alternative Name extension is present.	Modern TLS identity matching relies on SAN rather than common name alone.
CN/SAN agreement	The common name is present but not listed in SAN.	The subject name and requested server identities may not describe the same certificate target.
TLS server usage	`serverAuth` is requested without `digitalSignature` key usage.	Many TLS server profiles expect a compatible key-usage request for the intended key type.
Challenge password	A challenge-password attribute is present.	It may expose sensitive text and is often unnecessary in modern certificate enrollment workflows.

Expected Name Matching:

The optional hostname review normalizes a URL or DNS name to a lowercase hostname, removes a trailing dot, and compares it with requested SAN values and the common name. A DNS wildcard such as *.example.com covers www.example.com, but not api.dev.example.com. A SAN match is reported as a pass, a common-name-only match is a warning, and a missing name is a warning.

Privacy and Security Notes:

CSR content is processed in the browser for decoding. A CSR normally contains a public key rather than a private key, but it can still reveal hostnames, organization names, email addresses, URI names, internal naming patterns, and challenge passwords. Avoid pasting private keys, and handle exported review files as sensitive when the requested names or subject details should not be shared.

Worked Examples:

New Web Server Certificate

A CSR for www.example.com verifies with an RSA 2048-bit key and includes DNS SANs for example.com and www.example.com. With Expected DNS name set to www.example.com, the readiness note reports SAN coverage, so the next review step is CA validation and profile approval.

Common Name Only Request

A request has CN=portal.internal.example but no SAN entries. Even if the signature verifies, Readiness Notes flags the missing SAN because modern TLS clients should not rely on the common name for server identity.

Copied Wrong File

A pasted block begins with BEGIN CERTIFICATE or BEGIN PRIVATE KEY. The decoder stops instead of treating it as a CSR, which helps prevent reviewing an issued certificate or accidentally exposing private-key material.

FAQ:

Is a CSR the same as a certificate?

No. A CSR is a request that contains a public key and requested certificate details. A certificate is the signed result an issuer creates after validation and policy checks.

Does a verified CSR signature mean the certificate should be issued?

No. A verified CSR signature shows possession of the matching private key. Issuance still depends on domain control, requester authorization, certificate profile rules, and the CA's policy.

Why does the expected hostname check prefer SAN over common name?

Modern TLS service identity checking uses DNS names in the Subject Alternative Name extension. A common name can still be useful for human review, but it should not be the only requested server name.

Can a CSR safely contain a challenge password?

The attribute is part of older certificate-request workflows, but it can expose sensitive text in tickets, logs, and exported reports. Treat its presence as a reason to confirm whether the CA still requires it.

Glossary:

CSR: Certificate signing request, the public request sent to an issuer before a certificate is created.
PKCS#10: The certification request syntax commonly used for CSRs.
SAN: Subject Alternative Name, the certificate extension used for DNS names, IP addresses, email addresses, URIs, and other identities.
SPKI: Subject Public Key Info, the standardized public-key structure used for public-key fingerprints and pin values.
JWK: JSON Web Key, a JSON representation of a cryptographic key. The decoder exports public JWK data for supported RSA and named-curve EC keys.

References:

RFC 2986: PKCS #10 Certification Request Syntax Specification, IETF, November 2000.
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF, May 2008.
RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, IETF, April 2015.
RFC 9525: Service Identity in TLS, IETF, November 2023.
CA/Browser Forum TLS Baseline Requirements, CA/Browser Forum, May 2026.
NIST SP 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths, NIST, March 2019.
How to configure SSL/TLS on a MySQL or MariaDB server, Simplified Guide.