CertGuru

CSR — certificate signing request

A certificate signing request is a block of data you send to a certificate authority containing your public key, the identity you are requesting (the subject and any subject alternative names) and a signature made with the matching private key. That self-signature proves you hold the key you are asking to have certified. The private key never leaves your machine. A CSR is a request, not a promise — the CA validates your claim to those names and decides what actually goes into the issued certificate.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

What a CSR contains #

Read one
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:
      Requested Extensions:
          X509v3 Subject Alternative Name:
              DNS:example.com, DNS:www.example.com
  Signature Algorithm: sha256WithRSAEncryption

Four things, and only four things:

  1. The subject — the distinguished name you are claiming. Country, organisation, common name.
  2. The public key — algorithm, size, and the key itself.
  3. Requested extensions — most importantly the subject alternative names, which is where hostnames actually live.
  4. A self-signature — made with your private key, proving you hold the counterpart to the public key in the request.

What it does not contain #

  • Your private key. It stays on your machine. Any CA or reseller asking you to send a private key is doing something badly wrong.
  • Validity dates. The CA sets those.
  • Any guarantee. Everything in a CSR is a request that the CA may honour, modify or ignore.

Format #

A CSR is PEM or DER just like a certificate. The PEM label is -----BEGIN CERTIFICATE REQUEST-----, and occasionally the older -----BEGIN NEW CERTIFICATE REQUEST----- from Microsoft tooling. Both parse with openssl req.

head -n1 request.csr
Expected output 
-----BEGIN CERTIFICATE REQUEST-----

Verifying before you submit #

Two checks are worth making every time, because both failures are invisible until after issuance.

The self-signature is intact
openssl req -in request.csr -noout -verify
Expected output 
Certificate request self-signature verify OK
The SANs you expect are actually there
openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative Name"

If the second prints nothing, the extension is missing — usually because -addext was used on an OpenSSL version older than 1.1.1, or because a config file referenced x509_extensions where it should have said req_extensions.

The key must still exist #

A CSR is worthless without the private key it was generated against. Confirm the pair before submitting:

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

Frequently asked questions

Does a CSR contain my private key?
No, and it must not. It contains the matching public key and a signature made with the private key. The private key never leaves your machine — that is the property that makes the whole system work.
Can I reuse a CSR for a renewal?
Technically yes, if the details are unchanged. It is a poor habit, because reusing the CSR usually means reusing the key, and rotating the key at renewal limits the damage from an exposure you have not noticed.
Will the CA honour everything in my CSR?
No. The CA drops any hostname you have not proven control of, sets its own validity dates, and generally overrides extensions such as key usage with its own policy. Always inspect the issued certificate rather than assuming it mirrors the request.
I lost the private key after generating the CSR — is the CSR still useful?
No. A certificate issued from it would be unusable, because you would not have the key needed to prove ownership during a TLS handshake. Generate a new key and a new CSR.

References

Related pages