What is a Certificate Signing Request (CSR)? CSR Certificates

X.509 digital certificates use the X.509 Public Key Infrastructure (PKI) to certify a public key to a user, device, or service identity embedded in the certificate. A PKI encapsulates the framework to use a certificate signing request (CSR) and enables users and servers to generate digital certificates like a SSL/TLS certificate.

In a PKI, a certificate signing request (CSR) is a message sent to the certificate authority to get a digital certificate. A certificate signing request (CSR) contains information like the public key, domain name, and the corresponding signatures needed to generate a certificate.

Read on to learn about CSR generation, the process of generating a certificate in the JoinNow Connector PKI, and see how our vendor-neutral PKI makes shifting to certificate-based authentication easy.

What Is a Certificate Signing Request (CSR)?

A certificate signing request (CSR) is a message sent to a certificate authority (CA) to get a digital certificate. It contains information like the public key, domain name, and a digital signature created with the private key to prove ownership of the public key.

X.509 digital certificates use the X.509 Public Key Infrastructure (PKI) to certify a public key to a user, device, or service identity embedded in the certificate. Signing certificates starts with the client generating a key pair known as the private and public keys. The client then digitally signs the CSR with the private key and it is sent to the CA to generate a digital certificate. Upon verification, the CA sends the certificate to the applicant.

What Information Is in a CSR?

A CSR is a bundle of identity details that proves you control a public key without exposing your private key. It consists of three main parts:

• Certification request information that contains pertinent information like the public key
• Signature algorithm identifier
• Digital signature identifier

The CSR must also provide the email address of the user or the organization if it is for a business entity.

After the certificate is issued, it can contain the following:

• Fully qualified domain name
• Legal name of an organization
• Organization unit
• City/State
• Country
• Email ID
• The public key for which the certificate is to be issued
• Unique identifying name
• Proof of authenticity. e.g., digital signature

Image Courtesy: Medium

Certificate Request Process Overview: How to Generate a CSR

SSL certificates and other types of certificates (Most SSL/TLS, client, code-signing, and device) follow a similar CSR process: You generate a key pair, create the CSR itself, then submit it to the certificate authority.

1. Generate a Key Pair

Before you can create a CSR, the system must first have a cryptographic key pair that will be using the certificate. This pair consists of:

• A private key that must be securely stored on the server or device.
• A public key that will be shared with the CA within the CSR.

Most modern deployments use RSA keys with at least 2048-bit length, although some newer environments use Elliptic Curve Cryptography (ECC).

Administrators can generate the key pair using built-in server tools (e.g., IIS wizards) or CLI utilities such as OpenSSL, HSM tools, or other PKI clients. Using tools with a high level of cryptographic protection is required to make sure that the certificate received is trusted and secure.

2. Create the CSR on the Target System

Once the key pair is generated, the next step is to create the CSR from the same system holding the private key. The CSR bundles the public key with important identity attributes including:

• Common name (domain)
• Organization
• Locality (including state and country)
• Contact information

This information is shared via the PKCS #10 request format.

During the creation process, the tool will typically prompt for these fields and then encode the request in Base64. This generates the familiar “BEGIN CERTIFICATE REQUEST/END CERTIFICATE REQUEST” block.

• It is vital that the CSR accurately reflects both the hostname and, when or where required, legal organization information.
• Decoded CSRs allow verification of identity fields and public key size, ensuring the private key remains secure on the host.

3. Submit the CSR to a Certificate Authority

With the verified and validated CSR complete, you can then submit the CSR to the CA for processing and issuance.

For public TLS/SSL certificates, the process typically involves pasting the Base64-encoded CSR into an online tool or uploading via API. Then, the CA parses the CSR and extracts the public key and subject information. Once that data is extracted, the CA verifies the information according to the processes in place depending on the level of validation required.

For some checks, this is as simple as validating domain control. For more advanced checks, the CA will also verify organization and identity checks. Some CAs allow some limited correction of information at this point, while core data elements (especially Common Name) can’t be edited and errors will require a new CSR.

When all information has been validated, the CA moves to issuance.

4. Certificate Issuance

After the CSR is validated and processed, the CA issues a signed digital certificate containing both your public key plus the verified identity information taken from the CSR. The certificate, plus any intermediate chain certificates, is then available for download.

5. Certificate Installation

Once the certificate is downloaded or received, it must be installed on the server or device that originally generated the key pair.

• You will have platform-specific steps to bind the certificate to services including web servers, VPNs, or application proxies.
• Installation usually requires importing the certificate, linking it to the private key store, and updating config to enable SSL/TLS for the intended hostname.
• After restart, the certificate should be installed correctly and chained to a trusted root.

Clients can now validate the certificate and establish encrypted, authenticated connections to your service.

What Happens After Submitting Your CSR: Understanding the Certificate Trust Chain

After your Certificate Authority (CA) approves your Certificate Signing Request (CSR), they issue your new certificate. However, that certificate doesn’t stand alone. It relies on a certificate trust chain (also called a chain of trust) so browsers and devices can verify its legitimacy.

The trust chain is a hierarchical series of certificates where each one is digitally signed by the one above it. This creates a verifiable path from your end entity/device certificate all the way up to a widely trusted Root Certificate Authority.

Trusted Root CA Certificate

The first certificate in a trust chain is the root certificate. Known as a trusted root, the root certificate is self-signed and pre-installed in the trust stores of operating systems and web browsers. 

A root certificate must be secured well. Otherwise, an attacker can forge certificates and compromise security.

Intermediate CA Certificate

An intermediate CA connects the root CA and the user to obtain an end-user certificate. CAs typically do not issue certificates from their root store. Thus, a CA uses root certificates to sign and issue intermediate certificates. These are used to issue end-user certificates in the final step of the trust chain. Using intermediates adds a layer of security: if an intermediate certificate is compromised, it can be revoked without affecting the root.

End-Entity (Server or User) Certificates

This is the actual certificate issued to you based on your CSR. It contains device-specific details (such as hostname, MAC address, or user identity) and is signed by an intermediate CA. This device certificate is what your endpoint presents during network authentication.

How Browsers Validate SSL/TLS Certificates and Trust Chain

A website sends its SSL/TLS certificate to a browser to authenticate its web pages. The browser checks the following:

• The integrity of the certificate as per its digital signature to prove that it originated from a legitimate server.
• Validity to ensure the certificate is still active.
• Revocation status from the Certificate Revocation List (CRL).

Upon verification, the browser and server initiate a TLS handshake to encrypt the connection. This process mitigates the risk of unauthorized access and helps establish a secure connection.

Common CSR Mistakes and How to Fix Them

There are several areas of risk inside the CSR process that can potentially impact service connections. Watch out for these common errors.

Common Name and Wildcard Errors

Many CSR errors happen due to a bad Common Name (CN) or wildcard. 

• If the CN doesn’t match the hostname users hit (e.g. samplename.com vs. www.samplename.com), browsers may return mismatch errors.
• Wildcards add more risk. For example, *.samplename.com would cover app.samplename.com and web.samplename.com, but not samplename.com or app.eu.samplename.com.

To prevent these problems, make sure all hostnames are listed exactly before CSR generation. Verify CNs and SANs line up with this list and use wildcards only when you understand the pattern they cover.

Mismatched Private Key and CSR

Another common problem is a certificate that can’t be installed due to a mismatch with the private key on the server. This can happen if:

• Multiple CSRs are generated on the same machine.
• Keys get moved or deleted.
• An issued certificate gets installed on the wrong server.

A certificate can only be used for authentication by the entity holding the matching private key. If you suspect a mismatch, compare the modulus or fingerprint of the private key and certificate. If they differ, generate a new key pair and re-submit.

Weak Keys and Old Algorithms

Old or weak key sizes can cause problems. 2048-bit RSA or stronger is the minimum for public-facing certificates, but errors can also happen if:

• The key size is too small.

• Outdated algorithms are used.
• Wrong org or domain details are held by the certificate.

The smartest fix is regenerating the key pair and CSR with correct, complete, up-to-date information and settings. To avoid confusion, retire the old key and make sure the new key gets stored securely.

Vendor-Neutral PKI for CSR Generation

SecureW2 Managed Cloud PKI provides a turnkey certificate solution for managed network devices. It’s straightforward and can be set up quickly without additional infrastructure — one biotech customer rolled out digital certificates to all their employees in fewer than three weeks using the SecureW2 PKI, enhancing network security and integrating with their existing infrastructure.

Schedule a demo to see how SecureW2 can help secure your network with digital certificates.

---

Frequently Asked Questions

How to Obtain a User Certificate From the SecureW2 JoinNow PKI?

1. Log in to our JoinNow Management portal with your credentials. 2. Hover over “PKI” and select “Create Certificate.”

3. Enter the device information, i.e., the OS (Windows, Mac, etc.), a user description, and the device’s MAC address.

4. Scroll down to the “Certificate” section and enter the CA, common name, validity, override validity, and select Generate keypair and CSR. Then, enter the details as shown here:

5. As you scroll down, enter your email address, URL, and other names (email ID) under the “SAN.” Then, select “Client Authentication” under the “Extended Key Usage” header.

6. Finally, select the certificate template name, policies, and your preference to receive the PKCS and click “Create.”

7. The CA will generate a user certificate, which you can use immediately.

What Is the Technical Structure of a CSR (PKCS #10 and ASN.1)?

The Public Key Cryptography Standard #10 (PKCS #10) stands for certificate signing request (CSR) syntax. It is a security standard produced and distributed by RSA Data Security and consists of a name, public key, and a set of attributes. The Abstract Syntax Notation.1 (ASN.1) is a notation describing the data transmitted by a telecommunication protocol. ASN.1 transmits information in any form to anywhere and covers the structural information. Here is the syntax of how a PKCS #10 CSR is generated in an ASN.1 format: ASN.1 type CertificationRequestInfo, consists of a version number, the subject name, public key (algorithm identifier + a bit string), and additional attributes about the purpose of the certificate. The attributes include extensions, a challenge password to curtail revocations, and other information like the subject and the types of certs (local or future).