A certificate signing request (CSR) is a block of encoded text that you provide to a Certificate Authority (CA) to apply for a TLS/SSL certificate. The CSR is an important step in the process of a user obtaining a digital certificate and is most often generated on the server where you will install the certificate. While submitting a (CSR) during the certificate enrollment process, you’ll need to provide information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. The CSR also contains the public key that will be included in your certificate and is signed with the corresponding private key.
Behind-the-scenes details for certificate signing requests (CSRs)
For those who use the Public Key Cryptography Standards 10 (PKCS10) Certification Request Standard, one of the most common standards for certificate signing requests, users must provide an unsigned copy of their digital certificate to the CA. They can initiate this process by generating a CSR using cPanel, Exchange, IIS, Java Keytool, or OpenSSL. These methods generally create CSRs in the Base-64 based PEM format, which means there is a X.509 certificate encoded in text using the Base-64 encoding scheme.
At the time of creation, most server software suites ask the user to provide several pieces of information for validation purposes. Those details include the requester's fully qualified domain name (FDQN), legal name of the company, contact email address, physical address, and name of the division that would be handling the certificate. Additionally, users will need to send over their public key as well as its type and length. As explained by GlobalSign, the CA needs these bits of data to create an SSL certificate, which uses asymmetric cryptography based on a corresponding private and public key pair.
What Information Is Included in a certificate signing request?
Your CA will use the data from the CSR to build your TLS certificate. Here is the type of information that you should expect to include in your CSR.
- Common name: The fully qualified domain name (FQDN) of your server (i.e., .example.com).
NOTE: You will receive a mismatch error if the common name does not match exactly the name that you type in your web browser. - Organization:The legal name of your organization. But be sure to include suffixes, such as Inc., Corp., or LLC. (if applicable).
NOTE: You should not abbreviate any part of the legal name. - Organization Unit:The unit or division of the company/organization managing the certificate (i.e., IT Department).
- Locality:The city where your organization is located.
NOTE: This should not be abbreviated. - State/Province/Region:The state/province/region where your organization is located.
NOTE: This should not be abbreviated. - Country:The two-letter code for the country where your organization is located.
- Email address:An email address used to contact your organization.
- Public key:The public key that will be included in the certificate.
NOTE: The public key is created automatically and is used to encrypt, while the corresponding private key is used to decrypt. - Key length and type:The bit-length of the key pair which determines the strength of the key and how easily it can be cracked using brute force methods.
NOTE: The most common key size is RSA 2048, but some CAs support larger key sizes such as RSA 4096. - Signature algorithm:The hashing algorithm used by your issuing CA to actually sign certificates to generate unique hash values from files.
How to simplify a seemingly complex certificate signing request process
Clearly, organizations must complete multiple steps and track many different pieces of information to properly submit a CSR. To make this process easier, companies should consider generating key pairs and CSRs as well as managing and enforcing trust stores from a central location. Such an approach would simplify administration and ensure that all policies governing certificate content during the certificate request process are enforced automatically.
Venafi's solution makes CSR generation easier, as it enables organizations to create their requests from a central enrollment portal. The solution also has the ability to define default values, which decreases the time needed to complete a CSR. Lastly, companies can use the enrollment portal to integrate with any CA. This further simplifies the generation and storage of CSRs and key pairs.
(This post has been updated. It was originally published on August 21, 2018.)
Related posts
