CSR Decoder & Inspector
Read requested names, public-key details, extensions, and signature state before submission
CERTIFICATE REQUEST and NEW CERTIFICATE REQUEST. A PKCS#10 certificate signing request carries a subject name, a public key, a signature made by the matching private key, and optional requested extensions such as subject alternative names. A CA decides which requested fields, if any, appear in the certificate it issues.
- Paste one PEM CSR or the strict Base64 body of a DER CSR.
- Click Inspect CSR and confirm the subject, common name, SAN requests, and public-key details.
- Check the self-signature result before submitting the request to a CA.
- Compare the issued certificate separately; a CA can omit or replace requested fields.
A valid self-signature shows that the matching private key signed this request. The certificate authority separately checks identity or domain control before issuance. Once issued, inspect the certificate's names and dates, and check revocation and trust in the client that will use it.
Use OpenSSL when you need a second local parser or command-line output for a support ticket:
openssl req -in request.csr -noout -text -verifyIf the command reports a verification failure, regenerate the CSR from the intended private key instead of editing the encoded request.
Does a valid self-signature mean the CA will issue the certificate?
No. It shows that the matching private key signed the request when it was created. Current key control, domain checks and CA approval are separate steps.
Should I check the common name or the SAN list?
Review both in the request, but use the SAN list on the issued certificate for modern hostname coverage. A CA can change what it issues.
Can I paste DER Base64 without PEM header lines?
Yes. Use padded Base64 for one DER-encoded PKCS#10 request; hex and URL-safe Base64 are not accepted.