An organization’s robust Public Key Infrastructure (PKI) is built on the strength of digital certificates. Each of these machine identities relies on the integrity of its creation process, and a Certificate Signing Request (CSR) is a foundational element of asymmetric encryption ensuring the security of SSL/TLS certificate generation.
To obtain an SSL/TLS certificate for a domain name on your server, you must first submit a CSR to a Certificate Authority (CA). The following will explain what a CSR is, the information needed at time of request, and how to create one.
What are certificate signing requests (CSRs)?
A CSR is a block of encoded text sent by the user to a Certificate Authority to request an SSL/TLS certificate for a website on your server. It contains encoded information about your server, site and organization and a public key. The CA uses that information, along with the public key, to create your SSL/TLS certificate.
At the time your server generates the CSR request, it also generates a private key that is used to sign your certificate using asymmetric encryption. If the private key is ever compromised, a new key pair and certificate should be generated as the strength and security of your SSL/TLS certificate depends on the privacy of that private key. It should not be shared with anyone outside of your organization.
What information is included in a CSR?
The requestor provides the following information to the issuing CA:
- Fully Qualified Domain Name (FQDN) of your server (“example.com”). This must be entered exactly as seen in the search bar.
- Company legal name and address. This cannot be abbreviated and must include suffixes (“Banning Corp.”). For Extended Validation Certificates, CAs will validate this information and include it directly in the SSL/TLS certificate.
- Organizational Unit (OU). The department within your organization in charge of the certificate.
- Company address. The specific format should be as follows:
- City/Locality (“San Francisco”)
- State/Region - unabbreviated (“California”)
- Country - two letter ISO code (“US”)
- Company email address
- Public key used to encrypt. Generated automatically at time of CSR request, the private key is used to decrypt will be kept safe on your server and should not be delivered over to the CA.
How do you create a CSR?
A CSR is generated on the server you wish to install the certificate on, and the file can be opened in a simple text box. Specific instructions depend on the platform you’re using (MMC, Java Key Store, Apache OpenSSL, IIS 10), but the general principles are the same.
The requestor submits the public key and SSL/TLS certificate information as part of the CSR request. For those using Public Key Cryptography Standards 10 (PKCS#10) Certification Request Standard, a common CSR standard, the CSR will generate in the Base-64 encoded PEM format, which will encode an X.509 certificate in the text body of the request. The request will be book-ended by “------Begin Certificate Request------” and “-----End Certificate Request-----”.
Specific instructions for generating a CSR request vary based on what platform you’re using (Exchange, OpenSSL, cPanel, IIS, Java Keytool). Basic instructions will be included in your server documentation, and individual Certificate Authorities provide their own sets of instructions as well.
The web server then generates a private key unique to the CSR which gives the SSL certificate its validity and strength. Bit length of the key pairs should be an industry standard RSA 2048, as required by the Extended Validation guidelines for all SSL/TLS certificate providers issuing EV certificates. Some CAs also accept RSA 4096+ or ECC keys for additional security. All SSL/TLS certificates should be signed using SHA-2, the strongest signature algorithm at present.
How can you manage CSRs?
Spinning up key pairs and CSRs for every certificate can be a tedious and repetitious affair. Having a central enrollment portal that manages trust stores and keeps track of CSR default values (for example, company info will remain the same) is becoming the gold standard for safe and efficient PKI hygiene within an organization.
Venafi’s TLS Protect enables the automation of CSR requests and enforces trust stores and defaults in order to remove human error from the mundane, yet precarious, task of keeping track of thousands of private keys and CSR data points at a time. Once one SSL certificate is compromised, it can open an attack vector to your entire organization. A CSR initiates the first line of defense into securing your organization’s PKI and must be protected accordingly.