Importance of Secure Certificate Signing Request (CSR) Submission Process

Introduction

Imagine you are configuring an HTTPS website for your organization.

You have installed a web server and configured a domain name.

However, when users visit the website, their browsers report that the connection is not trusted because the server does not have an appropriate trusted TLS certificate.

How can you request a certificate for your website?

One common method involves creating a Certificate Signing Request (CSR).

A CSR contains information that a Certificate Authority (CA) can use when processing a certificate request.

It includes the public key associated with your server’s private key and can specify the domain names for which you want a certificate.

In this article, you will learn:

• What a Certificate Signing Request is
• Why organizations use CSRs
• How a CSR works with a Certificate Authority
• Important CSR fields, including CN and SAN
• Differences between a CSR, private key and certificate
• How to generate a CSR using OpenSSL
• How to inspect and verify a CSR
• Common CSR errors and security best practices

Prerequisites: Basic Networking, HTTPS, SSL/TLS, Public and Private Keys

1. What Is a Certificate Signing Request (CSR)?

CSR stands for Certificate Signing Request.

It is a structured, digitally signed request used to obtain a public-key certificate from a Certificate Authority.

A common CSR format is PKCS #10, defined by RFC 2986.

A PKCS #10 CSR normally contains:

• Subject information
• The subject’s public key
• Optional attributes, including requested certificate extensions
• A signature algorithm identifier
• A digital signature created using the associated private key

Why Is a CSR Required?

A CSR provides a standardized way to submit a public key and requested identity information to a CA.

It also includes a signature that the CA can verify to confirm possession of the private key corresponding to the CSR’s public key.

However, a CSR signature does not independently establish ownership of a domain name or the legitimacy of an organization.

What Is a Certificate Authority?

A Certificate Authority (CA) is an entity that issues digital certificates according to its applicable validation requirements and certificate policies.

For publicly trusted TLS certificates, the CA must perform the required validation before issuing the certificate.

2. What Information Does a CSR Contain?

A CSR includes a public key, subject information and a cryptographic signature.

The actual information depends on the certificate type, CSR generator and CA requirements.

Common CSR Fields

These fields are not all mandatory in every CSR or issued certificate.

2.1 Common Name (CN)

The Common Name is a subject attribute.

Historically, website certificates often used it to identify the primary hostname.

Example:

CN=www.example.com

Modern public TLS server certificates use the Subject Alternative Name (SAN) extension for their DNS names or IP addresses.

2.2 Organization (O)

The Organization field can identify a legal organization.

Example:

O=Example Organization

Whether it is included and validated depends on the certificate type and CA requirements.

A domain-validated certificate does not require the same organizational identity information as an organization-validated certificate.

2.3 Organizational Unit (OU)

The Organizational Unit field historically identified a department.

Example:

OU=IT Department

Although older CSRs may contain this field, modern publicly trusted TLS server certificate requirements prohibit the organizationalUnitName subject attribute in issued subscriber certificates.

Do not assume that a CA will accept or copy OU information into a public TLS certificate.

2.4 Locality, State and Country

These fields can identify geographical information associated with the certificate subject.

Examples:

L=New Delhi

ST=Delhi

C=IN

The country field uses a two-letter country code.

2.5 Public Key

The CSR contains a public key that the CA can certify.

The associated private key remains under the control of the key owner.

2.6 Subject Alternative Name (SAN)

SAN identifies additional DNS names or IP addresses requested for a certificate.

For example:

DNS:www.example.com

DNS:example.com

For publicly trusted TLS server certificates, SAN is required and must contain at least one appropriately validated DNS name or IP address.

3. CSR vs Private Key vs SSL/TLS Certificate

These three objects perform different roles.

Private Key

A private key is sensitive cryptographic material.

It may be stored in a protected file, hardware security module (HSM), TPM or another supported key-management system.

It must not be included in a CSR.

Public Key

The public key is mathematically associated with the private key.

It is included in the CSR and, when issued, in the corresponding certificate.

Signed Certificate

A CA-issued certificate contains the certified public key, subject and identity information, validity details, extensions, issuer information and the CA’s digital signature.

4. How a Certificate Signing Request Works

A typical CSR-based certificate issuance process involves several steps.

Step 1 — Generate a Key Pair

The administrator generates a cryptographic key pair.

For a file-based setup, the private key is stored securely.

The corresponding public key can be derived from it.

Step 2 — Create the CSR

The administrator creates a CSR containing the public key, subject information and requested extensions.

The CSR is signed with the associated private key.

Step 3 — Submit the CSR

The CSR is submitted to the appropriate CA using its supported enrollment procedure.

Step 4 — Complete Validation

The CA performs the required checks.

For a publicly trusted website certificate, these include validation of the requested domain names or IP addresses and other applicable checks.

Additional identity verification depends on the certificate type.

Step 5 — Issue the Certificate

If the request is approved, the CA issues a certificate containing the certified public key.

The CA is not required to copy every requested CSR field or extension into the certificate.

Step 6 — Install and Verify

The issued certificate is installed with access to its corresponding private key.

The server must also be configured with the appropriate certificate chain and TLS settings.

The administrator then verifies certificate matching, trust and HTTPS functionality.

5. Practical Lab — Generate a CSR Using OpenSSL

This example demonstrates how to generate an RSA private key and CSR on a trusted Linux system.

It uses reserved example domain names for training.

Lab Information

The example domain names are placeholders.

A public CA will require validation of real domain names or IP addresses for which you are authorized to request certificates.

Step 1 — Verify OpenSSL Installation

openssl version

Illustrative output:

OpenSSL 3.x.x

The exact version depends on your operating system and installed software.

Step 2 — Create a Secure Working Directory

mkdir -p ~/csr-lab
chmod 700 ~/csr-lab
cd ~/csr-lab
umask 077

This creates a working directory accessible only to the current account under the specified permissions.

The umask 077 setting also restricts permissions on newly created files in the current shell session.

Step 3 — Generate a Private Key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key

This generates a 3072-bit RSA private key.

The key can also be used to derive its corresponding public key.

Verify File Permissions

ls -l server.key

Illustrative output:

-rw------- 1 user user ... server.key

The example stores the private key in an unencrypted file, protected by operating-system permissions.

Production deployments should follow the organization’s key-management requirements, including encryption at rest or HSM-based protection where appropriate.

Step 4 — Generate the CSR

Run:

openssl req -new -sha256 -key server.key -out server.csr -subj "/CN=www.example.com" -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

Command Explanation

The command creates server.csr using the existing server.key.

It does not create an issued TLS certificate.

Step 5 — Verify the Generated Files

ls -l server.key server.csr

You should see both files in the working directory.

6. How to View and Verify a CSR

After generating a CSR, inspect it before submitting it to a CA.

View CSR Details

openssl req -in server.csr -noout -text

This displays information including the subject, public key, signature algorithm and requested extensions.

Example Output

Illustrative abbreviated output:

Certificate Request:
    Subject: CN = www.example.com
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        Public-Key: (3072 bit)
    Requested Extensions:
        X509v3 Subject Alternative Name:
            DNS:www.example.com, DNS:example.com

Verify the CSR Signature

openssl req -in server.csr -noout -verify

Certificate request self-signature verify OK

This confirms that the CSR’s signature verifies against its included public key.

It does not confirm ownership of the requested domains or establish that a CA will approve the request.

View the CSR Subject

openssl req -in server.csr -noout -subject

Verify the Public Key Matches the Private Key

A useful check is to compare fingerprints of the public keys derived from each file.

From the CSR:

openssl req -in server.csr -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

From the private key:

openssl pkey -in server.key -pubout -outform DER | openssl dgst -sha256

If both commands produce the same SHA-256 digest, the public key in the CSR matches the public key derived from the private key.

7. CSR File vs Certificate File

A CSR and an issued certificate may both use PEM encoding, but they represent different objects.

Example CSR Structure

A PEM-encoded CSR commonly begins and ends with:

-----BEGIN CERTIFICATE REQUEST-----
Base64-encoded certificate request data
-----END CERTIFICATE REQUEST-----

Example Certificate Structure

An issued PEM-encoded X.509 certificate commonly uses:

-----BEGIN CERTIFICATE-----
Base64-encoded certificate data
-----END CERTIFICATE-----

Main Differences

8. Common CSR Problems and Troubleshooting

Common Mistake — Relying Only on CN

A CSR containing:

CN=www.example.com

does not replace the need for appropriate SAN entries in a modern public TLS server certificate.

Common Mistake — Sharing the Private Key

A CA normally needs the CSR and its required validation information.

It does not need the server’s private key.

Common Mistake — Assuming a CSR Proves Domain Ownership

The CSR signature proves possession of the corresponding private key.

It does not prove authorization to obtain a certificate for a domain.

9. CSR Security Best Practices

Generate Keys in a Trusted Environment

Use a controlled system or approved hardware-backed key-management service.

Protect the Private Key

Restrict permissions and avoid transmitting private keys through insecure channels.

Include the Correct SAN Entries

Specify all intended hostnames or addresses permitted by the certificate type and CA.

Choose Supported Algorithms

Use key algorithms and sizes permitted by the CA and organizational security policy.

Verify the CSR Before Submission

Check its subject, SAN values, signature and public key.

Protect Certificate Enrollment Accounts

Secure CA account credentials and automated issuance permissions.

Maintain a Renewal Process

Monitor certificate expiration and maintain an approved renewal or reissuance workflow.

Follow CA Requirements

Publicly trusted CAs apply validation and certificate profile requirements that can change over time.

o only when its verified original asset is supplied.

[/SG-VISUAL]

10. Key Takeaways

Basic Concepts

• CSR stands for Certificate Signing Request.
• A CSR is commonly formatted using PKCS #10.
• A CSR contains a public key, subject information and a digital signature.
• The associated private key is not included in the CSR.
• A CA must perform applicable validation before issuing a certificate.
• A CSR is not an issued TLS certificate.

Important Security Concepts

• CN is the Common Name field.
• SAN identifies requested DNS names or IP addresses.
• Modern public TLS server certificates require appropriate SAN entries.
• The CSR signature proves possession of the associated private key, not domain ownership.
• Private keys must remain protected.
• OpenSSL can generate, inspect and verify CSRs.

Conclusion

A Certificate Signing Request is an important part of many digital certificate enrollment workflows.

It provides a standardized way to submit a public key and requested certificate information to a Certificate Authority.

However, the CSR itself does not establish trust or provide a working HTTPS connection.

The CA must perform the required validation and issue an appropriate certificate.

Administrators must also protect the associated private key, verify the issued certificate and configure their server correctly.

Understanding CSRs, SAN entries, key pairs and CA validation provides an essential foundation for certificate management, PKI and secure TLS deployment.

Next Article: SSL/TLS Digital Certificates Explained — Certificate Chain, Root CA, Intermediate CA and Trust Validation.

Useful Links and References

SanchitGurukul Static Resources

Official References