CertGuru

View and decode a CSR

To decode a certificate signing request, run `openssl req -in request.csr -noout -text`. This prints the subject, the public key algorithm and size, the requested extensions including subject alternative names, and the signature algorithm. Add `-verify` to check the CSR's self-signature, which confirms the request was made with the private key it claims. Add `-inform der` if the file is binary rather than PEM.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

The full decoding # 

openssl req -in request.csr -noout -text
Expected output 
Certificate Request:
  Data:
      Version: 1 (0x0)
      Subject: C = US, ST = California, O = Example Inc, CN = example.com
      Subject Public Key Info:
          Public Key Algorithm: rsaEncryption
              Public-Key: (2048 bit)
      Attributes:
          (none)
      Requested Extensions:
          X509v3 Subject Alternative Name:
              DNS:example.com, DNS:www.example.com
  Signature Algorithm: sha256WithRSAEncryption

The three checks worth running #

1. The self-signature is intact
openssl req -in request.csr -noout -verify
Expected output 
Certificate request self-signature verify OK
2. The subject is what you meant
openssl req -in request.csr -noout -subject
Expected output 
subject=C = US, ST = California, O = Example Inc, CN = example.com
3. The SANs are actually there
openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative Name"
Expected output 
X509v3 Subject Alternative Name:
  DNS:example.com, DNS:www.example.com

Individual fields #

Flag Prints
-subject The subject distinguished name
-pubkey The public key, PEM-encoded
-verify Whether the self-signature is valid
-text Everything, decoded
-noout Suppress the re-encoded CSR
-inform der The input is binary

Confirming the CSR matches your key # 

openssl req  -in request.csr -noout -pubkey | openssl sha256
openssl pkey -in private.key  -pubout        | openssl sha256

Identical hashes mean this CSR was generated from that key. If they differ, a certificate issued from this request would be unusable — you would not hold the key needed to complete a handshake.

A DER-encoded CSR #

Windows tooling sometimes produces these:

openssl req -inform der -in request.der -noout -text

Extracting the SANs as a plain list #

Handy in a script that checks a CSR covers everything it should:

openssl req -in request.csr -noout -text \
| grep -A1 "Subject Alternative Name" \
| tail -n1 \
| tr ',' '\n' \
| sed 's/ *DNS://' \
| tr -d ' '
Expected output 
example.com
www.example.com

Frequently asked questions

What does -verify check?
That the signature on the request was made by the private key matching the public key inside it. It proves the requester holds the key. It says nothing about whether they are entitled to the hostnames they are asking for — that is the CA's job.
My CSR shows no Requested Extensions — why?
The SANs were never added. Either -addext was used on OpenSSL older than 1.1.1, or a config file referenced x509_extensions where it should have said req_extensions. Regenerate the CSR; you cannot add extensions to an existing one.
Can I see which private key a CSR belongs to?
Not directly, but you can test a candidate. Compare openssl req -in request.csr -noout -pubkey | openssl sha256 with openssl pkey -in private.key -pubout | openssl sha256.
Does the CA see everything in the CSR?
Yes, and it may ignore most of it. Validity dates come from the CA, hostnames you cannot prove control of are dropped, and extensions such as key usage are normally replaced by CA policy.

References

Related pages