– – – – -BEGIN NEW CERTIFICATE REQUEST- – – – –
The Certificate Signing Request (CSR) is the first step in an SSL certificate’s life cycle – it is the egg from which a certificate hatches. It is also a file that many users are unfamiliar with, which can immediately make you feel confused or lost on your journey to getting an SSL certificate.
Here is a quick explanation of what a CSR is and the role it serves for those getting an introduction (or refresher) to SSL.
What is a CSR?
A Certificate Signing Request is a file that contains information a Certificate Authority (or CA, the companies who issue SSL certificates) need to create your SSL certificate. The purpose of the CSR is to have a standardized method for providing this information to CAs.
A CSR is quite literally a request to have a certificate created and digitally signed by a CA.
There are three important parts to a CSR:
- Your public key.
- The fully-qualified domain name(s) you want your certificate to be used with.
- Other information about you and your organization/website (including the legally registered name and the city/state/country where its registered).
Let’s break those parts down. The public key is an encryption key – one-half of the “key pair” that is used with SSL certificates. This is used to encrypt the data sent to your server. When you create a CSR you also create this key pair at the same time. The public key is included in the CSR and the SSL certificate you receive, allowing users connecting to your site to transfer data securely.
The other half of the key pair is the private key. Note that while this is also created at the same time as the CSR, it is not a part of the CSR. The private key is a separate file (usually in the .key format). The private key is used to decrypt the data that the public key encrypted. As the name suggests, you keep this key to yourself and do not send it to your CA or anyone else. You will need the private key later in the process when you install your SSL certificate.
The fully-qualified domain name(s), or FQDNs, are the hostname(s) where you will use your certificate. The FQDN should consist of the subdomain and parent domain, such as “www.example.com” or “mail.example.co.uk.” Do not include the scheme (“http://”).
Some SSL certificates allow you to secure multiple FQDNs with one certificate – usually marketed as “SAN certificates” or “multi-domain certificates.” For many providers, you will still include just one FQDN in your CSR and will specify the rest later in their order form.
The final piece of the CSR is “subscriber information” – an email address, legally registered business name, and location. This information may be included in your certificate if you purchased an “OV” or “EV” certificate, which validates your website is operated by a registered company/organization. However, not all certificates include this information and if it does not apply to you, you can leave it blank. Many providers also allow you to update this information later if it is incorrect.
Those three pieces are wrapped up and encoded, usually in the “PEM” format. Here is an example of what a CSR looks like:
—–BEGIN CERTIFICATE REQUEST—–
—–END CERTIFICATE REQUEST—–
Where does a CSR come from?
Well, when two SSL Certificates love each other very much, they… just kidding. Typically, the CSR is created by you on your web server. Every web server OS handles this process differently. On Windows/IIS, cPanel, and Plesk, there is a guided wizard. On NGINX/Apache, you use the command line.
In some cases, you will not be able to create a CSR yourself. This is most common when you use “shared” web hosting from providers like GoDaddy or HostGator. In this situation, you usually fill out of form to ask for a CSR.
Once you have created your CSR, you will paste/upload it into the order form on your SSL provider’s website. They will use the information in your CSR to create a certificate for you and send it back (after you have completed the validation process which, depending on the type of certificate you purchased, can take a few minutes or a few days).
While you won’t need to use your CSR again in the process of receiving your SSL certificate, it will be the most convenient to save it. If you ever need to re-issue your certificate you will need a CSR to restart the process. However you can always create a new CSR, so don’t fret if you lose it.