CSR FAQ

• What's a CSR?
• What does a CSR contain?
• What's the process for constructing a CSR?
• What size should the RSA key be?
• What does the CA do with the CSR?
• What does a CSR look like?
• How do I generate a CSR?
• How do I decode a CSR?
• How do I verify a CSR?
• Should the DN be encoded as UTF-8?

What's a CSR?

A Certificate Signing Request (CSR) is a message sent to a Certification Authority (CA) to request a public key certificate for an entity (such as a person or a web server). Before a CSR can be created, a key pair, which comprises a public and private key, must be generated. Once the key pair has been generated, the CSR can be created.

The most widely used format for CSRs is defined by RSA in the PKCS#10 specification. Another, far less common CSR format is the Signed Public Key and Challenge (SPKAC), which was defined by Netscape for use inside their browsers. Unless otherwise stated, this FAQ describes the PKCS#10 CSR

What does a CSR contain?

A PKCS#10 CSR consists of the following two parts:

• The Certification Request Information Part
• The Signature Part

The diagram below shows these two parts. The first part is the Certification Request Information part, which has four fields and is the part of the CSR signed by the entity's private key. The second part is the Signature part, which is made up of two fields.

• Version version of the PKCS#10 standard supported. Should be set to 0 (which, strangely enough, means v1.7).
• Distinguished Name (DN) is the distinguished name of the entity the certificate is being requested for.
• Public Key contains the entity's public key.
• Attributes are a collection of attributes that may be included with the request.
• Signature Algorithm identifies the algorithm used to sign the CSR
• Digital Signature is the signature created using the entity's private key

The purpose of the optional Attributes is threefold: to provide the CA with additional information about the entity such as a postal address, to communicate attributes to be included in the certificate (for example an email address), and to provide a challenge passphrase that can be used at a later stage if required to revoke the certificate.

The entity's private key is not included in the CSR, but it is used to create the Digital Signature over the CSR. The signature proves to the CA that the requester is in possession of the corresponding private key. This is known as proof of possession.

What's the process for constructing a CSR?

The process by which a CSR is constructed involves the following steps:

1. A Certification Request Info value containing a version number, a distinguished name (DN), a public key, and optional attributes is constructed by the entity requesting a certificate.
2. The Certification Request Information value is signed with the entity's private key.
3. The Certification Request Information value, a signature algorithm, and the entity's signature are collected together to make the CSR.

What size should the RSA key be?

When deciding what size key to use, consideration should be given to your security requirements. What data is being protected? What threats may it be exposed to? How long does it need to be protected for? The larger the key, the greater the security it provides, but also the slower the cryptographic operations.

Consideration should also be given to compatibility. What applications will be using the certificate? Are there any restrictions on the key sizes the applications can work with?

On the subject of key size, Wikipedia writes the following: "RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010 and that 2048-bit keys are sufficient until 2030." While on the RSA Laboratories website an article recommends key sizes of 1024 bits for corporate use and 2048 bits for extremely valuable keys (note: it is not clear when this RSA article was last updated). A number of CAs are now recommending and in some instances requiring 2048 bit keys for all SSL certificates, which is the minimum key size for EV certificates.

For a number of years now the security community has suggested a move away from 1024-bit key lengths by the end of 2010. In Special Publication 800-57 NIST recommends that 1024-bit RSA keys only be used to protect data until 2010. In 2003, RSA Labs published a document that recommended 1024-bit RSA keys should not be used to protect data with a lifetime beyond 2010. It is generally accepted that 1024-bit RSA keys are roughly equal in strength to 80-bit symmetric keys, and that given the advances in computing power and algorithms these keys sizes may be crackable in the next decade.

In summary, 1024 bit keys may be vulnerable to attack in the not too distant future and for this reason you should consider moving to a longer key length. Any certificate with a validity period past 2010 should use at least a 2048 bit key. Finally, it is important to examine your own security requirements and applicable policies carefully before deciding on a suitable key size.

What does the CA do with the CSR?

The CA examines the CSR, which it considers to be a wish list from the requesting entity. If the request is in line with the CA's policy or it can be modified to bring it in line, the CA will issue a certificate for the requesting entity. Once issued the certificate is sent to the requesting entity and/or a certificate repository such as an LDAP directory.

What does a CSR look like?

The most widely used syntax for a CSR is defined by the PKCS#10 specification. It is possible to encode a PKCS#10 CSR in binary or text formats.

Binary Format

The binary formatted CSR is also known as the ASN.1 or DER encoded CSR. It is an ASN.1 structure (defined by PKCS#10) that has been encoded using the Distinguished Encoding Rules (DER). If you open a binary encoded CSR in a text editor you will see lots of strange looking characters.

Text Format

The text or PEM (Privacy Enhanced Mail) formatted CSR is the binary CSR after it has been Base-64 encoded to create a text version of the CSR. It also includes additional header and footer lines which enclose the Base-64 and provide an indication of the content. A text formatted CSR can be viewed in a text editor or pasted into an email. Below is an example of a PEM encoded CSR. You can use our CSR Decoder to decode the CSR, verify its signature, and display the information contained within it.

How do I generate a CSR?

While some applications that use certificates can generate keys and CSRs themselves, others rely on an external tool such as OpenSSL to do the work. The command line below shows how to generate a CSR using OpenSSL. After providing OpenSSL with information about the certificate you will end up two files: a new private key called server.key and a certificate request called server.csr.

openssl req -new -newkey rsa:1024 -keyout server.key -out server.csr

How do I decode a CSR?

We've written a web based CSR Decoder tool that decodes CSRs online. If your CSR contains information that you do not want to send over the Internet (such as a challenge passphrase), you can decode a CSR locally on your own machine using the following OpenSSL command:

openssl req -in server.csr -noout -text

How do I verify the signature on a CSR?

Our online CSR Decoder will verify the signature on a CSR. Alternatively you can use the following OpenSSL command:

openssl req -in server.csr -noout -text -verify

Should the DN be encoded as UTF-8?

There was a PKIX Working Group requirement that all distinguished names (DNs) should be encoded as UTF-8 after December 31 2003. However, the requirement has since been removed and most CAs ignored it anyway because of the interoperability issues it would cause. The majority of CAs use strings called PrintableString to encode the attributes of a DN.