What Is a CSR? Certificate Signing Request Explained

What is a CSR, exactly?

A CSR is a message you generate and send to a certificate authority to request a certificate. Formally it follows the PKCS#10 standard (RFC 2986): a structured block containing your public key, the identity details you want certified, and a signature made with your private key. That signature is the clever part — it proves you hold the private key that matches the public key, without ever revealing the key itself.

Think of it as a sealed application form. The form states who you are and hands over one half of a lock (the public key); the seal is made with the other half (the private key) that stays in your pocket. Anyone can read the form, but only the holder of the private key could have sealed it. The CA checks the seal, verifies the identity claims independently, and then issues a certificate — its own signed statement that this public key really does belong to this domain.

Crucially, the CSR is a request, not the certificate. It carries no authority on its own. Its whole purpose is to travel to a CA and come back transformed into something browsers will trust. If you understand how PKI establishes trust, the CSR is simply the on-ramp: the moment a key pair you generated enters the chain of trust.

What's inside a CSR?

A CSR holds three things: a subject, a public key, and a signature. The subject is your identity — at minimum the Common Name, which is the domain the certificate will protect, plus optional organization, locality, state, and country fields. The public key is the half of your key pair that will end up in the finished certificate. The signature binds the two together and proves you own the private key.

The org fields only matter for higher validation levels. A domain-validated certificate ignores them — the CA only confirms you control the domain — while OV and EV certificates verify the organization details against public records, so accuracy there matters. One field that no longer lives in the CSR the way people expect is the list of extra hostnames: modern CAs usually take Subject Alternative Names from the order, not the CSR, which is why the Common Name has quietly become the least important part of the request.

The CSR and the private key: one pair, two halves

Generating a CSR always produces two files at once: the CSR itself and a private key. They come from a single key pair, and they have opposite rules. The CSR is public — you can email it or paste it into an order form without a second thought. The private key is the secret that must never leave the machine it was made on. Mixing up their handling is the single most damaging CSR mistake there is.

The reason both exist is that the certificate you eventually install only works when it can be paired with the private key. The certificate proves ownership of a public key; the private key is what actually performs the decryption and signing during a TLS handshake. So the CSR starts the process, but the private key finishes it. This is why "I got my certificate but lost the key" is an unrecoverable situation — the two are useless apart.

How a CSR becomes a certificate

When a CA receives your CSR, it does three things: it checks the signature to confirm you hold the private key, it independently validates the identity claims (domain control for every certificate, plus organization checks for OV and EV), and then it constructs a new X.509 certificate. That certificate wraps your public key inside the CA's own signed statement, with a serial number, validity period, and signature that the CA — not you — chooses.

A common misconception is that the CA "signs your CSR" and hands it back. It doesn't. The signature on your CSR is only a proof-of-possession check; once the CA has used it to confirm ownership, it's discarded. The certificate the CA issues is a fresh document, signed with the CA's private key so that browsers — which already trust that CA — will trust your certificate by extension. Your public key is the one thing carried across from the CSR into the finished certificate.

How do you generate a CSR?

There are three common paths, and they produce the same PKCS#10 result. You can run OpenSSL on the server that will host the certificate, use your hosting control panel's built-in generator (cPanel, Plesk, IIS all have one), or use a browser-based tool. Whichever you choose, the golden rule is the same: generate the CSR where — or in a way that keeps — the private key safely under your control.

Whatever you generate, verify it before you submit. Pasting the CSR into a decoder confirms the domain and organization fields are spelled correctly and the key size is what you intended — a two-minute check that saves a rejected order later.

RSA or ECDSA? Key choices in your CSR

The key type is decided when you generate the CSR, because the key pair is created first and the CSR is built around it. Under the CA/Browser Forum Baseline Requirements, a public certificate must use either an RSA key of at least 2048 bits or an ECDSA key on the NIST P-256, P-384, or P-521 curves. Those are your only two families, and both are fully trusted — the choice is about compatibility and performance, not security level.

RSA 2048 is the safe default: every client that has ever spoken TLS understands it. ECDSA P-256 gives equivalent security with a much smaller key and faster handshakes, and it's the better modern choice for any stack that supports it — which today is essentially all current browsers and servers. If you want the full trade-off, our comparison of ECC vs RSA certificates lays out where each still makes sense. As of July 2026, the 2048-bit RSA floor and the approved ECDSA curves are unchanged in the Baseline Requirements.

Common CSR mistakes and how to avoid them

Most CSR problems trace back to a handful of avoidable errors: losing the private key that pairs with the CSR, mistyping a subject field, generating the CSR on the wrong machine, or submitting a CSR whose key falls below the current minimum. Each one shows up either as a rejected order or as a certificate you can't install. Here's how to sidestep the common ones.