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 CSR self-signature shows that the request was signed with the private key matching its embedded public key. It does not prove identity, domain control, certificate issuance, CA trust, certificate validity dates, revocation status, or hostname coverage in a future certificate.
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 this request was signed with the corresponding private key when the CSR was created. It does not prove current control of that key, CA approval, or domain control.
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.