A CSR is a request file your server sends to get an SSL certificate

A Certificate Signing Request (CSR) is a block of encrypted text that your web server generates and sends to a certificate authority (CA) when you want to secure your website with an SSL certificate. The CSR contains information about your organization — your domain name, company name, location, and contact details — along with a public key that the CA will use to create your certificate.

You do not send money or personal documents to the CA. You generate the CSR on your server, copy the text, paste it into the CA's order form, and they send back a signed certificate. That certificate is what actually encrypts traffic between your site and visitors' browsers. The CSR is just the messenger.

Think of it this way: the CSR proves to the CA that you control the server and domain you claim to own. The CA verifies this, signs the request, and returns a certificate that browsers will trust. Without the CSR, there is no way for the CA to know they are issuing a certificate to the right person.

Key Takeaways

  • A CSR is a text file your server creates that contains your domain name, organization details, and a public key the certificate authority will use to sign your SSL certificate.
  • You generate the CSR on your server using your hosting control panel or command line, then copy and paste it into the CA's order form.
  • The CSR itself does not encrypt anything — it is only used to request the certificate that will do the encrypting.
  • Different certificate types (single domain, wildcard, multi-domain) require different CSRs, so you must generate a new one for each certificate you order.
  • If you lose your private key before the certificate arrives, you will need to generate a new CSR and reorder the certificate.

Where the CSR comes from and what it contains

Your web server generates the CSR using cryptographic software built into your hosting control panel or installed on your server. When you create a CSR, the server also creates a private key — a separate file that stays on your server and never leaves it. The CSR contains the matching public key, which the CA will use to create your certificate.

The CSR includes fields for your domain name (the Common Name), organization name, department, city, state, country, and email address. Some fields are required by the CA; others are optional. The CA will verify at least the domain name — usually by sending a confirmation email to an address associated with that domain or by checking DNS records.

The CSR is just text. When you open it, you will see something like -----BEGIN CERTIFICATE REQUEST----- followed by a long string of characters, then -----END CERTIFICATE REQUEST-----. This is normal. Copy the entire block, including the BEGIN and END lines, when you paste it into the CA's form.

How to generate a CSR on your hosting account

Most hosting providers let you generate a CSR directly from your control panel — usually cPanel, Plesk, or a custom dashboard. Log in to your hosting account, look for an SSL or Security section, and find the option to generate a CSR. You will be asked to enter your domain name and organization details.

If your hosting control panel does not have a CSR generator, you can create one using the OpenSSL command line tool. The command is openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr, replacing yourdomain with your actual domain. This creates two files: the CSR (yourdomain.csr) and the private key (yourdomain.key). Keep the private key file safe — you will need it when the certificate arrives.

After you generate the CSR, the system will show you the text. Copy the entire CSR block and paste it into your certificate order form at the CA. Do not edit or modify the text. If you make a mistake, generate a new CSR and start over.

Why you need a new CSR for each certificate

Each CSR is tied to a specific private key on a specific server. If you order a wildcard certificate (which covers all subdomains of your domain), you need a CSR that requests a wildcard. If you order a multi-domain certificate (which covers multiple unrelated domains), you need a CSR that lists all of them. You cannot use the same CSR for different certificate types.

If you move your website to a new server, you will need to generate a new CSR on the new server, even if you are keeping the same domain name. The private key on the old server will not work with the new one. Some CAs will reissue your existing certificate for a new server without charging you again, but you still have to request it with a new CSR.

If you lose the private key file before your certificate arrives, you cannot use that CSR anymore. You will have to generate a new CSR and place a new order. This is why it is important to back up your private key file once the certificate is installed.

What happens after you submit the CSR

Once you paste the CSR into the CA's order form and pay, the CA will verify that you own the domain. They typically do this by sending a confirmation email to an address listed in your domain's WHOIS record, or by checking a DNS record you create. Some CAs also verify by checking your SSL certificate history or by phone.

After verification, the CA signs the CSR with their private key and sends you back a signed certificate — usually within minutes to a few hours, though some CAs take longer. This signed certificate is what you install on your server. The certificate and your private key work together to encrypt traffic.

You will receive the certificate as a text file, similar in appearance to the CSR. Your hosting control panel will have an option to install or paste the certificate. Once installed, your site will show a padlock in the browser address bar and use HTTPS instead of HTTP.

Common mistakes when working with CSRs

The most common mistake is editing the CSR text after generating it. Even changing a single character makes the CSR invalid. If you need to change your organization name or domain, generate a new CSR instead of editing the old one.

Another mistake is losing track of which private key matches which CSR. If you generate multiple CSRs (for different domains or certificate types), label the private key files clearly so you know which one to use when the certificate arrives. If you cannot find the matching private key, you will have to generate a new CSR and reorder.

Some people also confuse the CSR with the certificate itself. The CSR is the request; the certificate is what the CA sends back. You only use the CSR once, to place the order. After that, you work with the certificate and private key.

CSRs for different certificate types

A single-domain certificate covers one domain name only — for example, www.example.com. The CSR lists that one domain as the Common Name. This is the most common type and the least expensive.

A wildcard certificate covers the domain and all its subdomains — for example, *.example.com covers www.example.com, mail.example.com, and any other subdomain. The CSR must request a wildcard by using an asterisk in the Common Name field.

A multi-domain certificate (also called a SAN certificate) covers multiple unrelated domains — for example, example.com, mysite.org, and another-site.net. The CSR must list all the domains you want to cover. This type costs more than a single-domain certificate but less than buying separate certificates for each domain.

Frequently Asked Questions

Can I reuse a CSR for multiple certificates?

No. Each CSR is tied to a specific private key. If you order a certificate, receive it, and then want to order another certificate for a different domain or server, you must generate a new CSR. Reusing a CSR will cause the certificate to fail installation.

What if I generate a CSR but never use it?

Nothing happens. An unused CSR is just a text file sitting on your server. It does not expire or cause problems. If you generate a new CSR later for the same domain, the old one becomes irrelevant. You can delete it if you want to keep your server clean.

Do I need to keep the CSR after the certificate is installed?

No. Once your certificate is installed and working, you can delete the CSR file. You only need to keep the private key file safe. The certificate and private key are what your server uses to encrypt traffic. The CSR was just the request form.

What if my hosting provider generated the CSR for me?

That is fine. Your hosting provider can generate the CSR on your behalf and handle the installation when the certificate arrives. You do not need to do it yourself. Just make sure they give you a copy of the private key file in case you ever need to move your site to a different host.

Can the certificate authority see my private key?

No. The private key never leaves your server. The CSR contains only the public key, which is meant to be shared. The CA uses the public key to create the certificate, but they never see or have access to your private key.