Key Points
- To obtain digital certificates, you must submit a Certificate Signing Request (CSR), which includes your public key and identifying information.
- To ensure secure communication, the CSR procedure generates a key pair, creates a PKCS #10 structure, and has it certified by a Certificate Authority (CA).
- A managed PKI solution, such as JoinNow Connector PKI, can manage the whole certificate lifecycle for internal use cases, from initial CSR generation to certificate issuance and revocation.
Every SSL/TLS certificate starts with a certificate signing request (CSR). Whether you are securing a public web server, issuing client certificates for Wi-Fi authentication, or protecting a VPN gateway, the CSR is the formal message you send to a certificate authority (CA) asking it to issue a digital certificate.
Despite the common shorthand “CSR certificate,” a CSR is not the certificate itself. It is the application that produces one.
This guide covers what a CSR contains, how the CSR generation process works across manual and automated methods, common mistakes that delay issuance, and how modern protocols like SCEP and ACME eliminate manual CSR handling entirely.
What Is a Certificate Signing Request (CSR)?
A certificate signing request is a block of structured, encoded text that an applicant submits to a CA. It contains two categories of information:
- Identity data — the Distinguished Name (DN) fields that identify the organization or device requesting the certificate.
- A public key — the cryptographic key that will be bound to the issued X.509 certificate.
The private key never leaves the applicant’s device — only the public key travels inside the CSR. Once the CA validates the request, it signs and returns a certificate that pairs the public key with the verified identity information.
CSRs follow the PKCS #10 standard (RFC 2986) and are typically encoded in Base64 PEM format — the familiar block of text wrapped in —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– headers.
What Information Is in a CSR?
The CSR bundles several fields into a standardized format
| Field | Description | Example |
| Common Name (CN) | Fully qualified domain name or device identifier | www.example.com |
| Organization (O) | Legal entity name | Acme Corp |
| Organizational Unit (OU) | Department (optional, deprecated by some CAs) | IT Security |
| Locality (L) | City | Seattle |
| State (ST) | State or province, unabbreviated | Washington |
| Country (C) | Two-letter ISO code | US |
| Email Address | Contact email | admin@example.com |
| Public Key | RSA or ECC key embedded in the request | 2048-bit RSA or P-256 ECC |
CSR Structure and Format: Inside PKCS #10
At a technical level, a CSR encoded in PKCS #10 (ASN.1 notation) consists of three parts:
- CertificationRequest Info: version number, subject DN, public key (algorithm identifier plus bit string), and optional attributes.
- SignatureAlgorithm: the algorithm used to sign the request (e.g., SHA-256 with RSA).
- Signature: the digital signature created by signing the CertificationRequestInfo with the applicant’s private key.
The signature proves the applicant holds the private key that corresponds to the public key inside the request. If someone tampers with any field after signing, the CA will reject the CSR because the signature will not verify.
Optional attributes can include certificate extensions (key usage, extended key usage), challenge passwords for revocation, and additional subject information.
How To Generate a CSR: Step-by-Step
Most SSL/TLS, client, code-signing, and device certificates follow the same general CSR workflow. The steps below apply whether you are using a public CA for a web server or a private CA for internal network authentication.
Step 1: Generate a Key Pair
Before creating the CSR, the system needs a cryptographic key pair:
Private key: stored securely on the server or device. Never shared.
Public key: included in the CSR and eventually bound to the certificate.
Most deployments use RSA keys with a minimum of 2048 bits. Elliptic Curve Cryptography (ECC) keys (P-256 or P-384) are increasingly common because they offer equivalent security at smaller key sizes, which reduces TLS handshake overhead.
With OpenSSL, generating a 2048-bit RSA key pair and CSR in a single command looks like this:
“`bash openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr “`
OpenSSL prompts for the DN fields (Common Name, Organization, Locality, etc.) and encodes the output in Base64 PEM.
Step 2: Create the CSR
The CSR is built on the same system that holds the private key. Whether you use OpenSSL, IIS Manager, a Java Keytool command, or a platform-specific wizard, the tool:
- Collects the DN fields and any SANs.
- Packages them with the public key into a PKCS #10 structure.
- Signs the structure with the private key. 4. Outputs the Base64-encoded CSR file.
Before submitting, decode and inspect the CSR to confirm the CN, SANs, key algorithm, and key size are correct. Catching errors here avoids rejected requests and resubmissions.
Step 3: Submit the CSR to a Certificate Authority
For public TLS certificates, submission usually means pasting the Base64 block into the CA’s web portal or uploading through an API. The CA parses the CSR, extracts the public key and subject fields, and begins validation.
Validation depth depends on the certificate type:
- Domain Validation (DV) — the CA confirms you control the domain (DNS record or HTTP challenge).
- Organization Validation (OV) — the CA verifies the legal entity exists.
- Extended Validation (EV) — the CA performs thorough identity and legal checks.
Core fields like the Common Name cannot be edited after submission. If the CSR contains errors, you must generate a new key pair and CSR.
Step 4: Certificate Issuance and Installation
After validation, the CA signs the certificate with its own private key and returns the signed end-entity certificate and any intermediate CA certificates needed to complete the certificate chain.
Once the signed certificate is returned, install it on the server or device that generated the original key pair. The private key stored locally and the public key inside the certificate must match, or the TLS handshake will fail. Platform-specific steps bind the certificate to web servers (Apache, Nginx, IIS), VPN gateways, Wi-Fi controllers, or application proxies.
After installation, verify the full certificate chain resolves back to a trusted root CA in the client’s trust store
Automating CSR Generation With SCEP and ACME
Manual CSR generation works for a handful of web server certificates, but it does not scale when an organization manages thousands of device certificates for Wi-Fi, VPN, and network access. Two protocols address this problem by automating the CSR lifecycle end to end.
SCEP: Simple Certificate Enrollment Protocol
SCEP was designed for network device enrollment. It wraps the CSR in PKCS #7 and PKCS #10 messages and handles the exchange between the device and the CA automatically.
Mobile Device Management (MDM) platforms like Microsoft Intune, Jamf, and Google Workspace use SCEP profiles to push certificate configurations to managed devices. The device generates the key pair, builds the CSR, submits it to the SCEP endpoint, and installs the returned certificate—all without user intervention.
ACME: Automated Certificate Management Environment
ACME, originally developed by the Internet Security Research Group for Let’s Encrypt, automates domain validation and certificate issuance for TLS certificates. The ACME client generates a key pair, creates the CSR, submits it to the ACME server, completes a domain control challenge (HTTP-01 or DNS-01), and retrieves the signed certificate. Renewal happens on a schedule with no manual steps.
ACME Device Attestation (ACME DA) extends the protocol to enterprise device certificates by binding the CSR to hardware-level attestation, proving the private key was generated inside a Trusted Platform Module (TPM) or secure enclave. This prevents key export and strengthens device identity assurance beyond what a standard CSR alone provides.
Why Automation Matters for Enterprise PKI
When CSR generation is manual, IT teams face certificate sprawl, expired certificates causing outages, and inconsistent key management.
Automated enrollment through SCEP and ACME reduces human error, enforces consistent key strength and certificate policies, and handles renewal before expiration. Organizations running certificate-based authentication for 802.1X Wi-Fi or VPN access need this level of automation to keep thousands of certificates current without helpdesk overhead.
Common CSR Mistakes and How to Fix Them
Understanding CSR mistakes makes it easier to troubleshoot and remediate.
Common Name and SAN Mismatches
If the Common Name or SANs in the CSR do not match the hostname clients use to connect, browsers and supplicants return certificate mismatch errors. A CSR for `samplename.com` will not cover `www.samplename.com` unless that hostname is listed as a SAN.
Wildcard certificates (`*.samplename.com`) cover single-level subdomains like `app.samplename.com` but not the bare domain `samplename.com` or multi-level subdomains like `app.eu.samplename.com`.
Fix: List every hostname and subdomain before generating the CSR. Verify the CN and all SANs match your production URLs.
Private Key and Certificate Mismatch
A certificate can only function with the private key that signed its CSR. Mismatches happen when:
- Multiple CSRs are generated on the same machine and the wrong key gets associated.
- Keys are moved, overwritten, or deleted during server migration.
- The certificate is installed on a different server than the one that generated the CSR.
Fix: Compare the modulus of the private key and the certificate. In OpenSSL:
“`bash openssl rsa -in server.key -modulus -noout openssl x509 -in server.crt -modulus -noout “`
If the output differs, generate a new key pair, create a new CSR, and resubmit.
Weak Key Sizes and Deprecated Algorithms
CAs and browsers reject CSRs that use key sizes below 2048-bit RSA or deprecated signature algorithms like SHA-1. Some older server configurations still default to 1024-bit keys.
Fix: Regenerate the key pair with `rsa:2048` or stronger (4096-bit RSA or P-256 ECC). Confirm the signature algorithm is SHA-256 or SHA-384. Retire and securely destroy the old key.
How the Certificate Trust Chain Works
A CSR is the starting point, but the issued certificate only works if clients can validate it through the full certificate trust chain. Here’s what that looks like.
Root CA Certificates
The root CA sits at the top of the chain. Root certificates are self-signed and distributed inside trust stores that ship with operating systems and browsers. Because the root key must be protected, CAs do not use it to sign end-entity certificates directly.
Intermediate CA Certificates
Intermediate CAs are signed by the root CA and handle day-to-day certificate issuance. This separation protects the root key. If an intermediate CA is compromised, the root CA can revoke it without invalidating the entire trust store.
End-Entity Certificates
The certificate issued from your CSR is the end-entity certificate. It sits at the bottom of the chain. During a TLS handshake, the server presents its end-entity certificate along with the intermediate certificates. The client walks the chain from end-entity to intermediate to root, verifying each signature, checking expiration dates, and consulting revocation sources (CRL or OCSP).
How SecureW2 Automates CSR Generation and Certificate Enrollment
Manual CSR workflows create friction for IT teams managing large device fleets. SecureW2 JoinNow Dynamic PKI eliminates that friction by automating the full certificate lifecycle, from CSR generation through issuance, renewal, and revocation.
For managed devices, SecureW2 integrates with MDM platforms (Intune, Jamf, Google Workspace, Kandji) through SCEP and ACME gateways. The MDM pushes a certificate profile to the device, the device generates the key pair and CSR locally, and the SecureW2 CA issues the certificate, all without IT touching a CSR file.
For BYOD and unmanaged devices, JoinNow MultiOS provides a self-service onboarding flow. End users connect to a portal, authenticate against their Identity Provider (Entra ID, Okta, Google Workspace), and receive a certificate configured for 802.1X Wi-Fi or VPN access. The CSR, key pair generation, and certificate installation happen behind the scenes in seconds.
ACME Device Attestation adds hardware-bound assurance by verifying the private key was generated inside the device’s TPM or secure enclave before the CA signs the certificate. This closes the gap that standard CSRs leave open: a traditional CSR cannot prove where the private key lives.
Combined with JoinNow Cloud RADIUS for real-time identity lookup and certificate validation at every authentication event, the result is a certificate-based network access architecture that scales without manual CSR management.
Schedule your free demo to learn how SecureW2 automates certificate enrollment for your network.
Frequently Asked Questions
What is the difference between a CSR and an SSL certificate?
A CSR is the request you submit to a CA. It contains your public key and identity information. The SSL/TLS certificate is what the CA returns after validating the CSR. The certificate binds your public key to your verified identity and is signed by the CA's private key so clients can trust it.
Can I reuse a CSR for multiple certificates?
Technically yes, but it is not recommended. Reusing a CSR means reusing the same key pair, which increases exposure if the private key is compromised. Best practice is to generate a new key pair and CSR for each certificate renewal or replacement.
How long does a CSR take to process?
Processing time depends on the validation level. Domain Validation (DV) certificates can be issued in minutes through automated checks. Organization Validation (OV) and Extended Validation (EV) certificates require manual verification and can take one to five business days.
Do I need a CSR for every device on my network?
If you are issuing individual device certificates for Wi-Fi (802.1X) or VPN authentication, each device needs its own key pair and CSR. Enrollment protocols like SCEP and ACME automate this process so that devices generate and submit CSRs without manual intervention. Managed PKI platforms like SecureW2 handle this at scale across thousands of endpoints.
What happens if my CSR contains incorrect information?
The CA may reject the request, or worse, issue a certificate with wrong details that causes connection failures. Because CAs cannot edit core fields like the Common Name after submission, the only fix is to generate a new key pair, create a corrected CSR, and resubmit.
