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 PKI contains the framework for a certificate signing request (CSR), which helps users and servers obtain SSL and TLS certificates. A CSR is sent to the certificate authority to obtain a digital certificate. Signing certificates starts with the client generating a key pair known as the private and public keys. The key is then signed with the private key and sent to the certificate authority to generate a digital certificate. Upon verification, the CA sends the certificate to the applicant. A certificate 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. The Certificate Signing Requests (CSR) follow the Public Key Cryptography Standard #10 (PKCS #10), the format used to send a message to certify a public key.

Image Courtesy: Medium

CSR Structure: Fields and Format (PKCS #10)

A Certificate Signing Request 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 ID of the user or the organization if it is for a business entity.

A PKCS#10 in ASN.1 format for CSR:

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 Inc. and consists of a name, public key, and set of attributes.

The Abstract Syntax Notation.1 (ASN.1) is a notation describing the data transmitted by a telecommunication protocol. The 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).

Certificate Request Process Overview: How To Generate a CSR

SSL certificates and other types of certificates follow a similar CSR process.

Most SSL/TLS, client, code-signing, and device certificates start the same way: You generate a pair key, create the CSR itself, then submit it to the certificate authority.

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).

Generating the key pair:

The key pair can be generated with 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 critical to ensure the certificate received is trusted and secure.

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.
• A common CSR best practice is to decode and inspect the CSR to confirm both field details and key size before sending it to a CA.

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 TSL/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 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.

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.

Certificate Installation (H3)

Once the certificate is downloaded or received, it must install the files 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.

How To Fix Common CSR Mistakes

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 cert gets installed on the wrong server.

A certificate can only be validated with the private key that signed the CSR. 

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.

• Outdate 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.

Explaining the Certificate Trust Chain To Establish Certificate Authority

A Trust Chain is the specific order in which certificates are issued in a PKI.

A secure certificate chain begins with a root certificate issued by the CA and is followed by one or more intermediate certs. Lastly, the system issues the end certificate, completing the process.

Here’s a diagram illustrating the certificate chain and its aspects:

What Is a Root CA Certificate?

The first certificate issued by a CA in a trust chain is the Root certificate. Known as a trusted root, the Root certificate is endorsed by a trusted CA and is a step before issuing intermediate CAs. Root certificates are obtained from the root stores. Devices contain root stores that are native to their operating system. 

A root certificate must be secured well. Otherwise, the transmission would need to be improved. To utilize the Root certificate effectively, they are preloaded in internet browsers and on devices existing on a network.

What Is an Intermediate CA Certificate?

An intermediate CA connects the root CA and the user to obtain an end-user certificate. CAs cannot 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.  

A CA’s verification protocols function to protect the Root certificate. Thus, intermediate certs are issued to secure the protocol, helping to prevent the Root certificate from getting revoked.

What Are End-Entity (Server or User) Certificates?

A Root CA does not produce end-user certificates. Intermediate CAs get certificates from the Root CA and are used to sign end-user and server certificates. Numerous intermediate CAs can be configured between the Root and end-user certificates, thus giving rise to the Trust Chain.

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 ensures no malicious threat actors can get access, and the user can safely access the webpage. 

How To Obtain a User Certificate From Our 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.

Vendor-Neutral PKI for CSRs and CA Generation

A trusted certificate authority is crucial to issuing digital certificates in a network. A trusted root CA signs impending intermediate CAs that go on to issue end-user and server certificates. This establishes a trust chain that protects the root certificate from any breaches. 

Click here to see how our customers adapted to digital certificates with our Managed PKI. 

A trusted CA can be obtained from a PKI, and Managed Cloud PKI solutions from SecureW2 are a solution to all your needs. Our vendor-neutral PKI provides a turnkey solution for all your managed devices in the network. The solution is straightforward and can be set up in no time.

Contact SecureW2 today to see our solutions in action and secure your network right away.