# 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.

Source: https://certguru.io/openssl/view-csr/
Last updated: 2026-08-19
Commands verified against OpenSSL 3.5.7.

---

## The full decoding

```bash
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*

```bash
openssl req -in request.csr -noout -verify
```

Expected output:

```
Certificate request self-signature verify OK
```

*2. The subject is what you meant*

```bash
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*

```bash
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
```

> **Empty output from check 3 means a broken certificate**
>
> A CSR with no SAN extension produces a certificate that fails in every modern browser, and you
>   will not find out until after issuance. This is the check that saves the most time.

## 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

```bash
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:

```bash
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:

```bash
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
```

## Related

- [Generate a CSR](/openssl/generate-csr/)
- [Generate a CSR with SANs](/openssl/generate-csr-with-san/)
- [Decode a CSR in your browser](/tools/decode-csr/)


## 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

- [openssl-req(1)](https://docs.openssl.org/3.5/man1/openssl-req/) — -in, -noout and -verify
- [RFC 2986: PKCS #10 certification request syntax](https://www.rfc-editor.org/rfc/rfc2986) — the CSR structure itself

## Related pages

- https://certguru.io/openssl/generate-csr/
- https://certguru.io/openssl/generate-csr-with-san/
- https://certguru.io/formats/csr/
- https://certguru.io/concepts/san/
- https://certguru.io/openssl/check-key-matches-certificate/

--
CertGuru — https://certguru.io