Blog Post Oct 12, 2023

Certificate Signing Request (CSR) Guide

A Certificate Signing Request (CSR) is a critical part of obtaining SSL/TLS certificates, ensuring secure online communications. It contains essential details about the requester, such as the Fully Qualified Domain Name (FQDN), organization name, and public key. Generating a CSR may vary by platform, but the process ensures trust and authenticity in public key infrastructure (PKI). Tools like OpenSSL and IIS Manager streamline CSR creation, and validation tools ensure accuracy before submission. Sectigo simplifies this with lifecycle management solutions, guiding users to secure their websites and choose appropriate SSL certificates.

1. What is a CSR?

2. What are the requirements?

3. Importance of Certificate Signing Requests (CSRs)

4. How to generate a CSR on different platforms

5. Common challenges and tips

6. Secure your website with Sectigo

Digital certificates are a must for keeping online communications and data secure. SSL/TLS certificates in particular facilitate user trust as they secure websites, ensuring that a user's data - such as personal or financial information - is protected.

There's no denying the value of SSL certificates in today's threat-filled digital landscape, but the process of obtaining one — and especially the right one for your business needs — can feel confusing or downright frustrating at times. This stems, in part, from the sheer volume of data that is often required in the issuance process, especially when navigating the most complicated and most essential aspect of obtaining a digital certificate: submitting the certificate signing request (CSR).

Once you understand how CSRs work and why they are important, it will be far easier to navigate the request process. To help, we will explain everything you need to know about CSRs: what they are, why they matter, and how to submit them so you can obtain an SSL/TLS certificate.

What is a CSR?

A certificate signing request (CSR) is an encrypted message that includes critical information about the person or organization seeking to obtain a digital certificate. It presents a standardized solution for sending public keys to certificate authorities (CAs) via an encoded file.

A CSR is a critical component of public key infrastructure (PKI) and essentially functions as the first step in requesting SSL/TLS certificates.

What are the requirements?

Every CSR should include a few key elements, meant to identify the requester:

The Common Name (CN) of the organization. Specifically, this is the Fully Qualified Domain Name (FQDN) or the absolute domain name. This reveals the exact location within the Domain Name System (DNS). This must match exactly what you type in your web browser or you may receive a security error.
The Organization Name (O). Not to be confused with the common name or FQDN, the organization name simply refers to the legal name or official title of the company in question. If relevant, this should include corporate identifiers. With a CSR, the organization name should never be abbreviated.
Organization Unit (OU). The unit or division of the company/organization managing the certificate.
Locality (L). The CSR should include locality detail which is the city you are located in.
State or Province Name (ST). The state or province in which you are located.
Country (C). The country in which you are located.
Email Address. An email address associated with the company.

In addition to organization names and location details, every CSR involves a public key, which functions as half of the eventual key pair required for SSL certificates. The very process of creating a CSR results in the creation of this public key. This will be included with the CSR.

During this process, a private key will also be created. This, unlike the public key, should not be included with the CSR or made available to the CA. Instead, this should be safeguarded until later in the process, when it will be needed to actually install the SSL certificate.

Details about key type and length also play into the CSR. The top types of keys include RSA and DSA, both of which present distinct advantages and potential downsides. While RSA (Rivest–Shamir–Adleman) is typically preferred for swift verification and encryption, DSA (Digital Signature Algorithm) replaces the RSA’s prime factorization with the discrete logarithm problem. DSA is the more efficient option for verifying and decrypting. When opting for RSA, a bit length of 2048 is preferred. The CA/Browser Forum defines current baseline requirements for supported key sizes.

CSR example

CSR files are typically opened with text editors. They include headers and footers, meant to designate when the request begins and ends. The current gold standard involves a Base-64-based PEM (Privacy Enhanced Mail) format. Classified as a binary-to-text encoding scheme, this is widely regarded as the de facto format for sending cryptographic keys.

Below, we've provided a detailed example of what you might encounter, visually speaking, when you submit a CSR:

Navigating this dense text-based data can be difficult so we provide access to a helpful CSR decoder tool. You can easily use this to verify whether details contained within the CSR (such as the aforementioned location or organization name) are accurate.

Importance of Certificate Signing Requests (CSRs)

The CSR represents one of the earliest and most important steps in the process of obtaining an SSL/TLS certificate. The information contained within the CSR allows the CA to create requested certificates.

In many ways, the role of the CSR comes down to trust: by promoting and revealing website authenticity, this resource establishes a much-needed baseline of trust between two parties, the CA and the organization seeking the SSL certificate. CAs are granted the power and responsibility of verification, and they do not take this authority lightly. It is through CSRs that CAs are able to facilitate collective trust in the PKI.

From a practical standpoint, CSRs matter because, without them, it will be all but impossible to secure much-needed SSL/TLS certificates from trusted CAs. These certificates are crucial to developing trust among customers, who want to know that their information is transmitted securely. The Certificate Signing Request builds the foundation of this trusting relationship.

How to generate a CSR on different platforms

Now that you understand the value of a CSR, it's time to take the next step: actually producing and submitting the official request. This can be complicated, in part, because generating the CSR code may look a bit different from one platform to the next. Each platform brings distinct advantages and challenges to the table, but we've highlighted a few of the most common solutions below:

OpenSSL

OpenSSL — an open-source command line tool — provides a common framework for seeking CSRs. It is appealing not only for its open-source status, but also because of its relative ease of use. It is often used to produce CSRs via Nginx and Apache web hosting environments. This strategy is also uniquely valuable for producing ECC CSRs (Elliptic Curve Cryptography Certificate Signing Requests).

Under the oft-preferred OpenSSL approach, the necessary command will appear as follows:

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

Once prompted, you can enter the aforementioned CSR details such as the location and FQDN. A passcode is not required but may be a valuable option for boosting security.

IIS Manager

Another common approach involves Microsoft’s Internet Information Services (IIS) Manager. Visit the Connections page within the IIS Manager, moving next to the Server Certificates menu and then the Actions page.

From there, the Distinguished Name Properties page will provide a Request Certificate tool, where the FQDN and other essentials can be submitted. Don’t forget to reference the bit length and the cryptographic provider.

Other options

Some organizations cite a preference for working with specific platforms to generate CSRs. No matter which platform is desired, we are happy to provide assistance and guidance every step of the way. Alternate options we provide generation details on include:

Common challenges and tips

Often, the biggest challenge of creating a CSR involves reading and understanding the actual request when it's in the recommended PEM format. Other common concerns include:

Inaccurate name information. Attention to detail is crucial when creating and submitting a CSR. This is especially important for naming details, including both the FQDN and the legal name of the company in question. Hence, the need for a decoder to reveal that names are accurately presented.
Seeking multi-domain SSL certificates. CSR generation need not cause ongoing headaches when you are looking to secure multiple domains. When in doubt, OpenSSL config files can be adjusted to include Alt or SAN names. As always, requirements will vary based on the type of certificate and level of validation desired.
Testing and decoding the CSR. To ensure that the CSR is ready to be sent to the desired CA, use a decoder tool to verify that it’s formatted correctly. Sectigo offers access to a CSR decoder free of charge, so you can feel confident as you submit your CSR and take one of the most crucial steps toward obtaining SSL/TLS certificates

Secure your website with Sectigo

Now that you are familiar with the CSR process, it's time to determine which certificates you'll use to protect your website. At Sectigo, we offer a straightforward CSR process, plus a variety of options for obtaining and managing digital certificates. Our certificate lifecycle management solutions streamline the process, so you can confidently secure identities at scale.
We also recommend reading our resource on the various types of SSL certificates so you can determine the right certificate for your needs. Don't hesitate to get in touch if you'd like to learn more about CSRs and the role they play in obtaining SSL certificates.