| Field | Value | Copy |
|---|---|---|
| {{ key }} | {{ value }} |
| # | SubjectAltName | Copy |
|---|---|---|
| {{ idx + 1 }} | {{ name }} | |
| No SAN entries found. | ||
openssl req -in request.csr -noout -text openssl req -in request.csr -verify -noout openssl req -in request.csr -pubkey -noout | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 -binary | openssl enc -base64
{{ csr.trim() }}
Certificate signing requests are structured messages that present an identified public key and a proof that the sender controls its private half. They are commonly used when preparing for a new server certificate or a renewal with a trusted issuer.
Clear decoding helps you confirm subject names, alternative names, and key details before submission, which avoids delays and rejections. A certificate signing request decoder and verifier clarifies what is inside and whether the self signature checks out.
You provide a request in the familiar text envelope and receive human readable fields with the key algorithm, size or curve, the signature method, a verification result, and simple fingerprints for tracking. You can also review a compact key representation for use in services that expect a standard public key format.
As an example, a request for a site with both the bare domain and the www host should show both names under alternative names and its common name should appear there as well. If it does not, update your template so the issued certificate includes all the endpoints you intend to serve.
Treat requests as sensitive material and handle them with the same care as you would a certificate order. Small mismatches can create confusion, so compare results with your intended order details before you proceed.
Certificate Signing Requests (CSR) describe an entity’s subject information and public key, then include a self signature that proves possession of the corresponding private key. The tool parses the request, verifies the signature, and displays structured fields for inspection.
From the parsed data it computes reference fingerprints on the binary form of the request and on the Subject Public Key Info (SPKI). It also converts the public key into a JSON Web Key (JWK) so that the same key can be reused wherever a compact JSON form is expected.
Results include the Distinguished Name (DN) with Common Name (CN), Organization (O), Organizational Unit (OU), Locality (L), State or Province (ST), Country (C), and email address, plus any Subject Alternative Name (SAN) entries. Key Usage (KU), Extended Key Usage (EKU), and Basic Constraints are shown when present.
Interpretation focuses on practical readiness: signature verification should pass; RSA keys should be at least 2048 bits; weak digests such as SHA 1 and MD5 indicate legacy settings; a server certificate request typically needs SAN entries that match the names you plan to serve.
pin-sha256="…". A missing SAN for the common name would be flagged.
| Condition | Implication |
|---|---|
| Signature verification failed | Request cannot prove key possession; regenerate with a valid key pair. |
| RSA size below 2048 | Likely rejected by most issuers; increase key size. |
| Weak EC curve (P 192 or P 224) | Deprecated strength; choose a modern curve such as P 256 or P 384. |
| Digest is SHA 1 or MD5 | Legacy signature; prefer SHA 256 or stronger. |
| No SAN entries | Modern server certificates rely on SAN; add required names. |
| CN not listed in SAN | Target host may be uncovered; mirror CN in SAN when needed. |
| serverAuth without digitalSignature KU | Typical server profiles expect digital signatures; adjust KU set. |
| Challenge password present | Often unnecessary; remove unless your process requires it. |
| Input | Accepted Families | Output | Encoding/Precision | Rounding |
|---|---|---|---|---|
| CSR text | PEM with headers; bare base64 wrapped automatically | Subject, SAN, key, signature, warnings | Strings; integers for sizes; booleans for verification | None |
| CSR file | .pem, .csr, .txt; generic application types | Same as text input | As above | Not applicable |
| Fingerprints | CSR MD5, SHA 1, SHA 256; SPKI SHA 256 | Lowercase hex; SPKI pin in base64url | Hex and base64url | Exact digests |
| Public key | RSA, EC (named curves), Ed25519/Ed448 | JWK for RSA/EC; SPKI DER | base64url for JWK components | Not applicable |
| Field | Type | Min | Max | Step/Pattern | Error Text | Placeholder |
|---|---|---|---|---|---|---|
| CSR text | Multiline text | — | — | PEM headers added if missing | Paste a PEM-encoded CSR. | Paste PEM-encoded CSR or drop a file… |
| CSR file | File | — | — | Accepts .pem, .csr, .txt, application/* | — | — |
Processing runs entirely in your browser; decoding, verification, and fingerprinting operate on local memory. No data is transmitted or stored server side.
No data is transmitted or stored server side. Outputs assist with operational checks and do not constitute security guarantees.
Certificate signing requests can be decoded and verified for quick pre‑issuance checks.
Example. A request for api.example.com should include that host in SAN and pass signature verification. If the digest reads SHA 1, regenerate with SHA 256.
Once everything aligns with your order, proceed to submission with confidence.
No. All parsing and checks happen in your browser and nothing is persisted or sent to a server.
The self signature is verified against the included public key. Passing means the private key was used, not that an issuer will accept the request.
PEM text with request headers or a file with .pem, .csr, or .txt. Bare base64 text is wrapped automatically.
Yes, once the page is loaded. All processing is browser based and requires no network calls.
Warnings highlight likely issues such as weak digests or missing SAN entries. Use them as prompts to adjust templates before ordering a certificate.
Decode the request, confirm the signature passes, review subject and SAN, and ensure key parameters meet your policy. Regenerate if anything falls short.
Yes. You can copy a JWK for RSA or EC keys and download SPKI in DER for other uses.
No. It prepares your request and surfaces likely issues. Issuance depends on external validation and policy.