# Certificate signing requests

A certificate signing request is a signed statement saying "here is my public key, here is the identity I am claiming, and here is proof I hold the matching private key". The proof is a signature over the request made with that private key. You send the CSR to a certificate authority; the private key never leaves your machine. The CA then validates your claim to those names and issues a certificate — which may not match your request, because the CA decides what goes in it.

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

---

## The three parties

```text
You                          CA                        Client
 |                            |                          |
 |-- generate key pair        |                          |
 |-- build CSR (public key    |                          |
 |   + claimed identity,      |                          |
 |   signed with private key) |                          |
 |--------------------------->|                          |
 |                            |-- validate domain        |
 |                            |-- issue certificate      |
 ||
```

The private key appears exactly once in that diagram, on your side, and never moves.

## What the self-signature proves

A CSR is signed with the private key corresponding to the public key inside it. That signature does
not prove you own `example.com`; it proves the person submitting the request holds the key they are
asking to have certified.

Without it, an attacker could take your public key, submit it with their own identity, and obtain a
certificate for a key they cannot use — pointless — or, more usefully, substitute their key into
your request in transit. The self-signature closes that.

*Check it*

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

Expected output:

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

## What the CA does with it

| In your CSR | What the CA does |
| --- | --- |
| Public key | Copies it into the certificate. This is the point of the exercise |
| Common Name | Usually copies it, but it has no effect on hostname matching |
| Subject alternative names | Keeps names you prove control of; drops the rest |
| Organisation, country | Verified for OV and EV; often stripped for DV |
| Key usage, extended key usage | Normally replaced by CA policy |
| Validity dates | Not in a CSR at all — the CA sets them |

The consequence: never assume the issued certificate mirrors the request.

*Compare what you asked for with what you got*

```bash
openssl req  -in request.csr     -noout -text | grep -A1 "Subject Alternative Name"
openssl x509 -in certificate.crt -noout -ext subjectAltName
```

## Domain validation happens outside the CSR

Anyone can generate a CSR for any hostname. Try it — nothing stops you:

```bash
openssl req -new -newkey rsa:2048 -nodes -keyout fake.key -out fake.csr \
  -subj "/CN=www.google.com" -addext "subjectAltName=DNS:www.google.com"
```

That file is a perfectly valid CSR. It is also worthless, because no CA will issue against it —
validation is a separate step where you prove control of the domain by serving a token over HTTP,
publishing a DNS record, or answering a documented email address.

> **Why this design is right**
>
> Separating the request from the validation means the CSR format does not have to encode any notion
>   of ownership, and CAs can change how they validate without changing the format. It also means a
>   CSR is not a secret — there is nothing sensitive in one.

## The key pair is the thing that matters

If you lose the private key, the CSR and any certificate issued from it become useless: you cannot
complete a TLS handshake without the key. There is no recovery.

*Confirm a CSR and key belong together*

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

## Related

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


## Frequently asked questions

### Does the CA get my private key?

No, and no legitimate CA will ever ask for it. The CSR contains only the public key plus a signature made with the private one. Any provider requesting a private key should be refused.

### What stops someone submitting a CSR for a domain they do not own?

The CA's validation, not the CSR itself. Anyone can generate a CSR claiming any hostname. The CA proves domain control separately — an HTTP challenge, a DNS record, or an email to a documented address — before issuing.

### Can I reuse a CSR?

Technically yes, if nothing has changed. It is a poor habit, because reusing the CSR normally means reusing the key, and rotating the key at renewal limits the damage from an exposure you have not noticed.

### Why does my issued certificate not match my CSR?

Because the CSR is a request. The CA sets its own validity dates, drops hostnames you have not proven control of, and usually replaces extensions such as key usage with its own policy. Always inspect the certificate you receive.


## References

- [RFC 2986: PKCS #10 certification request syntax](https://www.rfc-editor.org/rfc/rfc2986) — the CSR structure itself
- [RFC 6125: service identity in TLS](https://www.rfc-editor.org/rfc/rfc6125) — why the common name stopped being authoritative for hostnames

## Related pages

- https://certguru.io/formats/csr/
- https://certguru.io/openssl/generate-csr/
- https://certguru.io/openssl/generate-csr-with-san/
- https://certguru.io/concepts/san/
- https://certguru.io/openssl/view-csr/

--
CertGuru — https://certguru.io