What is a Certificate Signing Request (CSR)?

A Certificate Signing Request (CSR) is the request file to be sent to a Certification Authority (CA) when requesting an SSL certificate. The CSR in PKI is created along with the public/private key pair and contains the public key. Examples are provided below on how to generate a CSR, and take note that the private key generated along with the CSR should be kept secret. This should be generated on the server where the SSL certificate will be installed. Different web servers require the private key to be stored in different ways, but regardless, always remember to protect the private key. The CA will only need the CSR to generate and issue the SSL certificate and WILL NOT need the private key.

A Certificate Signing Request header looks like the following:

-----BEGIN CERTIFICATE REQUEST-----

and the footer looks like:

-----END CERTIFICATE REQUEST-----

Some CSRs may be generated with a header and footer like the following, but this is less common.

-----BEGIN NEW CERTIFICATE REQUEST-----

and the footer:

-----END NEW CERTIFICATE REQUEST-----

Certificate Signing Request data and contents

Note that the Certificate Signing Request Common Name will be an FQDN for an SSL server certificate, a human name for a personal client certificate, or an application name for an application client certificate.

OpenSSL Generate CSR

To generate a CSR using openssl, run the following command:

openssl req -newkey rsa:4096 -keyout key.pem -out req.pem -nodes

Note that -nodes means your private key will be plain text. Also, note that the key size specified in rsa:4096 must be at least 2048 to be secure. While 2048 is deemed secure, we recommend going ahead with 4096 key size.

If you prefer to use the Java keytool over openssl, see our article on generating a CSR with the Java keytool.

Create CSR from existing private key

If you already have a private key that you want to reuse, you can create a new CSR from the existing private key. If you have the old CSR you can just resubmit it to your Certification Authority (CA). While it is a best practice to rotate your keys and generating a new private key, it is still generally secure to reuse a private key because of its cryptographic strength.

To create a CSR from an existing private key, run the following command:

openssl req -new -key example.key -out example.csr -nodes

Answer the given questions, and your CSR will be generated with the specified file name, decrypted as specified with -nodes.

Adding a Subject Alternative Name (SAN) to the CSR

Depending on the Certification Authority (CA), SANs may or may not be supported in the CSR. Many CAs will expose an API allowing SANs to be included with the CSR or as a separate parameter. In the case of the former, you can add the to the CSR with an additional option to your OpenSSL command or by use of a configuration file. We’ll cover both.

To include SANs in your CSR with a configuration file, do the following:

1. Create a file named config.

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = Richmond
O = Some Org
OU = Some OU
CN = example.com
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com

2. Run the following openssl command:

openssl req -new -out example.csr -newkey rsa:2048 -nodes -sha256 -keyout example.key -config config

3. Inspect your generated CSR for the SANs.

4. Submit your CSR to a Certification Authority listed below.

To include SANs in your CSR with a command line option, run the following openssl command:

openssl req -new -subj "/C=US/CN=example.com" -addext "subjectAltName = DNS:www.example.com" -newkey rsa:4096 -keyout key.pem -out req.pem

This will add the www.example.com subject alternative name to your CSR, and then pick up with step number 3 above to inspect and then submit your CSR.

Also, by specifying -subj you are providing the subject information in the command instead of being prompted. This can make the processing of generating your CSR much quicker and programmatic. Again, specify -subj to provide the subject in the command rather than being prompted for it.

Adding an IP address SAN to a CSR

For internal systems and applications that may not have a dire need for a DNS name, it may be easier to add a SAN to the certificate in the form of the IP address instead of DNS name. This can be achieved using similar config as above. After creating the configuration file, add the following to it to include the DNS.

[alt_names]
IP.1 = <your_ip_address>
IP.2 = <your_ip_address_2>

Then run the same openssl command as above, pointing to the configuration file with -config config to create the CSR with an IP SAN (Subject Alternative Name).

Alternatively, you can skip the CSR generation and go straight to creating a self signed certificate with an IP SAN with the following command:

 openssl req -x509 -nodes -days 1825 -newkey rsa:2048 -keyout key.pem -out cert.pem -config config

If you do not wish to create the config file for the IP SAN configuration, you can add the subjectAltName extension, similar to the example above. To include the IP SAN in the CSR with the command line option, run the following:

openssl req -new -subj "/C=US/CN=example.com" -addext "subjectAltName = IP:10.10.10.10" -newkey rsa:4096 -keyout key.pem -out req.pem

If you receive the following error, make sure that your IP address is formatted properly and is indeed an IP address and not a DNS name:

Error Loading command line extensions
140239286240576:error:220A4076:X509 V3 routines:a2i_GENERAL_NAME:bad ip address:../crypto/x509v3/v3_alt.c:473:value=www.example.com
140239286240576:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=IP:www.example.com

Then decode the CSR, described below, to verify the IP address is set as a Subject Alternative Name (SAN) on the CSR. It will look like the following:

Setting basicConstraints on the CSR

To set basic constraints on the CSR, use the -addext option when using OpenSSL. For example, to set the CA=false basic constraint on your CSR:

openssl req -newkey rsa:4096 -keyout key.pem -out req.pem -addext "basicConstraints=critical,CA:false"

Alternatively if the CSR is requesting an intermediate CA certificate, you would simple change false to true.

Verify a CSR with OpenSSL

To verify the signature on a CSR with openssl, run the following command:

openssl req -in example.csr -verify

If the CSR signature is verified successfully, the output will be: verify OK

If the CSR signature verification fails, the output will be:

unable to load X509 request
140569047790912:error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode:../crypto/pem/pem_lib.c:929:

A few Certification Authorities to send your CSR to (in no particular order):

• The SSL Store
• Comodo
• Sectigo
• RapidSSL
• DigiCert
• Alternatively, make use of the Automated Certificate Management Environment (ACME) and use Let’s Encrypt to automate your certificate request process.

Decoding a Certificate Signing Request

You can decode a CSR with the following openssl command:

openssl req -in req.pem -noout -text

Alternatively, you can decode your CSR with our online CSR decoder tool.

Conclusion

Hopefully this article has served you well and covered what a Certificate Signing Request is and how to generate a new CSR with openssl or keytool. Let us know in the comments if you need additional examples on CSR generation or if you have any questions that have not been covered in this post.