CSR FAQ
- What is a CSR?
- What does a CSR contain?
- What's the process for constructing a CSR?
- What size should the RSA key be?
- Can I check for Debian weak keys?
- 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?
- How do I convert a CSR from PEM to DER format?
- How do I convert a CSR from DER to PEM format?
- Should the DN be encoded as UTF-8?
What is 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, where the entity is the subject of the certificate, for example, a web server. The CSR is typically generated by the software that requires a certificate; most web servers, for example, are able to generate their own CSRs. Before a CSR can be created, however, the software creating the CSR must generate a key pair; the key pair comprises a public and private key. The public key is bundled with the subject's name, and other information to form the CSR. The private key is used to sign the CSR and should be stored securely.
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?
To view the contents of a CSR, use our CSR Decoder or the OpenSSL tool.
Top Level Structure
The top level ASN.1 description of a CSR is shown below:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
The PKCS#10 CSR can be considered as two parts:
- The Certification Request Information part
- The Signature part (i.e., signatureAlgorithm + signature)
CSR Fields
The diagram below shows these two parts. The Certification Request Information part has four fields and is the part of the CSR signed by the entity's private key. The Signature part has two fields.
- Version version of the PKCS#10 standard supported. Should be set to 0 (which, strangely enough, means v1).
- 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
Optional Attributes
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. Some attributes that may be useful are defined in PKCS#9.
Certificate Request Info Structure
The entity's private key is not included in the CSR, but it is used to create the Digital Signature over the Certification Request Information part. Below is the ASN.1 description of the Certification Request Information part of the CSR.
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo,
attributes [0] Attributes
}
The signature over the Certification Request Information part proves to the CA that the requester is in possession of the corresponding private key. This is known as Proof of Possession (PoP).
What's the process for constructing a CSR?
The process by which a CSR is constructed involves the following steps:
- 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.
- The Certification Request Information value is signed with the entity's private key.
- 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?
As of 2017, the CAB forum recommends key strengths are at least 2048-bit for RSA keys
Can I check for Debian weak keys?
Yes, you can check for weak Debian RSA keys in a CSR or certificate by using our CSR Decoder and Certificate Decoder. You can also check if your websites are using Debian weak keys by using our SSL Checker or Bulk SSL Checker. Please note that all tools that check for Debian weak keys do rely on blacklists and may not be 100% complete.
Let's look at some of the background to this issue with Debian based systems. Back in May 2008, the Debian team announced that Luciano Bello had discovered a bug in the random number generator of the Debian OpenSSL package. This meant that all SSL and SSH keys generated on Debian based systems released between September 2006 and May 2008 may be vulnerable. There are many Debian based systems including but not limited to: Ubuntu, Damn Small Linux, Linspire and Xandros. The Debian Security Team disclosed this vulnerability in Debian Security Advisory 1571. The best resource on this vulnerability is the Debian Wiki. It is estimated that a private key generated by the flawed crypto package has between 15 and 17 bits of entropy. In other words, not secure. To check that your CSR or certificate does not contain a weak RSA key from this buggy version of OpenSSL you can use our online CSR Decoder and Certificate Decoder.
Below is an example of a CSR that has a weak key:
-----BEGIN CERTIFICATE REQUEST----- MIIBizCB9QIBADBMMQswCQYDVQQGEwJHQjESMBAGA1UECBMJQmVya3NoaXJlMRAw DgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5NeSBDb21wYW55IEx0ZDCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA5fy56mgUe5YqxNxwzLdRricjfVwgc9pRGbYc sV+uSgRRpGVImD8AD45avTw0wdICGDTAiBAxSQCZfsZfdp42YSuOy/LePj2sTKQk azOpM9SmOf4E7OPWd94O9Jv809d7EzZh4yu+9tEDVgiDNhqZraHYl3nAwBCOw2lt CkxUnwUCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GBANYS454tPh2QD3bS911kS3/F BqOzbWWuNnh5nxH/ObB2x841h2MujLpOmrjeudON7siRb3VCn/K/rRQ0Q0fbrZ5R rjWY2bSwYAziRon/JgI7uKnfIjRGktrFwlQptCkFfbr42GmV3mWjaHRqk+udP39m n8ukO4LSxo1REOW1vdGD -----END CERTIFICATE REQUEST-----
Please also see our article over at Cert Logik that has more examples of Debian weak keys in CSRs and Certificates and also more information on the tools you can use to locate Debian weak keys.
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.
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.
-----BEGIN CERTIFICATE REQUEST----- MIIBozCCAQwCAQAwYzELMAkGA1UEBhMCZ2IxDzANBgNVBAgTBnN0YWZmczEOMAwG A1UEBxMFc3Rva2UxFTATBgNVBAoTDENTUiBEZWNvZGVyczEcMBoGA1UEAxMTd3d3 LmRlY29kZWNzci5jby51azCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzrUU 2GDhmYUY7qJ/UgUanDOF7ou9PG9xyng1du/Cbj1T6Sq48GnChgfAy9p/VwVOW4RA 393vMM6ewfUx18S9Um3V0LZ4m4a2Qyn5ZQAO2lwVmtKFDkFjnn6NndyC1xtB9kQg TU4mne4cvvHuxxDTssdjiu0qFRFwqA5NST32r4ECAwEAAaAAMA0GCSqGSIb3DQEB BQUAA4GBADaragMxUdVEpATqDSGj2twASbCloT5OdeSjE2/dha+6nSTe8mN/7ALD E2gtYXyfY1xebfxbMzddKkl/OTRyBnBS1VemuG5XzUkU9b1dCoV6dcxGVb0K0Z9D 4d5P9aqq//WHGKIwDsfut4gAAjrOshLlw6b4eFLacuRLRVuw+qBE -----END CERTIFICATE REQUEST-----
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.
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 to decode 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 CSRs 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 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
How do I convert a CSR from PEM to DER format?
openssl req -in csr.pem -out csr.der -outform DER
How do I convert a CSR from DER to PEM format?
openssl req -in csr.der -inform DER -out csr.pem -outform PEM
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.
---
Feedback and suggestions about this article are appreciated and can
be emailed to the author Phil Ratcliffe at [email protected]
Last modified: 20th Sept 2017