Skip to content

How to Generate a CSR for Your SSL Certificate

Key idea:

CSR (Certificate Signing Request) is a file with your public key and organisation data that you send to a CA to obtain an SSL certificate. Generated with openssl, requires: private key, Common Name (CN = domain), SAN for multi-domain. Let's Encrypt does not need a CSR — it uses ACME.

Below: step-by-step, working examples, common pitfalls, FAQ.

Check your site's SSL →

Step-by-Step Setup

  1. Ensure openssl is installed: openssl version
  2. Generate private key: openssl genrsa -out privkey.pem 2048
  3. Generate CSR: openssl req -new -key privkey.pem -out request.csr
  4. Fill fields: Country, State, City, Organization, Common Name (example.com), email
  5. For multi-domain: use a SAN config (see example below)
  6. Submit request.csr to the CA (DigiCert, Sectigo, GeoTrust)
  7. After receiving the cert: install in nginx/Apache with the original privkey.pem + intermediate bundle
  8. Verify with Enterno SSL Checker

Working Examples

ScenarioConfig / Record
Minimal CSR (one line)openssl req -new -newkey rsa:2048 -nodes -keyout privkey.pem -out request.csr -subj "/C=US/ST=CA/O=Acme/CN=example.com"
CSR with Subject Alternative Names (SAN)openssl req -new -key privkey.pem -out request.csr -config san.cnf
san.cnf for multi-domain[req] distinguished_name = req_dn req_extensions = v3_req [req_dn] CN = example.com [v3_req] subjectAltName = DNS:example.com,DNS:www.example.com,DNS:api.example.com
Inspect CSRopenssl req -text -noout -in request.csr
Wildcard certCN = *.example.com + SAN = *.example.com, example.com

Common Pitfalls

  • Typo in Common Name (www.example.com vs example.com) — CA rejects
  • RSA key below 2048 bit — most CAs reject (Let's Encrypt minimum is 2048)
  • Password on the private key (-aes256) — nginx prompts at restart. Use -nodes.
  • Forgot SAN for multi-domain → cert only covers one domain
  • ECDSA instead of RSA — supported but not every CA / every client. RSA is safer for compatibility.

TL;DR

To generate a Certificate Signing Request (CSR) in 2026, use the openssl command-line tool. Execute openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr to create a CSR and its associated private key. Ensure you provide accurate information such as your domain name and organizational details during the process, which is crucial for SSL certificate issuance.

Understanding the CSR Generation Process

A Certificate Signing Request (CSR) is a block of encoded text that contains information about your website and your organization. It is submitted to a Certificate Authority (CA) to obtain an SSL certificate. Generating a CSR is a critical step in securing your website and establishing trust with your visitors.

What You Need Before Generating a CSR

Before you begin generating a CSR, ensure you have the following:

  • Your domain name: The fully qualified domain name (FQDN) for which you are requesting the SSL certificate.
  • Organizational details: Information such as your organization's name, location (city, state, country), and administrative contact.
  • OpenSSL: A widely used tool for handling SSL/TLS certificates. Ensure you have OpenSSL installed on your server or local machine.

Generating a CSR Using OpenSSL

To generate a CSR, follow these steps using the OpenSSL command-line tool:

  1. Open your terminal: Access your command line interface (CLI) on your server or local machine.
  2. Run the OpenSSL command: Execute the following command:
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

This command performs the following actions:

  • -new: Indicates that you want to create a new CSR.
  • -newkey rsa:2048: Generates a new RSA private key of 2048 bits.
  • -nodes: Specifies that the private key should not be encrypted.
  • -keyout: Defines the filename for the private key.
  • -out: Specifies the filename for the CSR.

Providing Information for the CSR

After running the command, you will be prompted to provide several pieces of information:

  • Country Name: Use the two-letter ISO code (e.g., US for the United States, DE for Germany).
  • State or Province Name: Enter the full name of your state or province.
  • Locality Name: This is typically the city where your organization is located.
  • Organization Name: Enter the legal name of your organization.
  • Organizational Unit Name: This field is optional and can be used for a department name.
  • Common Name: The fully qualified domain name (e.g., www.yourdomain.com) that you want the SSL certificate to protect.
  • Email Address: Provide a valid email address for communication.

Example of CSR Generation

For instance, if you are generating a CSR for example.com, you would run:

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

Upon execution, you would fill in the prompts with:

  • Country Name: US
  • State or Province Name: California
  • Locality Name: San Francisco
  • Organization Name: Example Inc.
  • Organizational Unit Name: IT Department
  • Common Name: example.com
  • Email Address: admin@example.com

Verifying Your CSR

Once you have generated your CSR, it’s essential to verify its content to ensure accuracy. You can do this using the following command:

openssl req -in example.com.csr -noout -text

This command will display the details of the CSR, allowing you to check that all information is correct before submission to the CA.

Best Practices for CSR Generation

To ensure your CSR is generated correctly and securely, follow these best practices:

  • Use a strong key size (2048 bits or more) to ensure the security of your private key.
  • Keep your private key secure and never share it publicly.
  • Double-check the accuracy of all details provided in the CSR, especially the Common Name.

By following these guidelines, you can successfully generate a CSR that meets the requirements of most Certificate Authorities and helps secure your website.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Frequently Asked Questions

Do I need a CSR for Let's Encrypt?

No. Let's Encrypt uses the ACME protocol — certbot generates the key and CSR automatically. Just run <code>certbot --nginx -d example.com</code>.

What is SAN?

Subject Alternative Names — an X.509 extension that lets one cert cover multiple domains. Modern browsers ignore CN in favor of SAN. Always include the domain in SAN.

DV vs OV vs EV?

DV (Domain Validation) — only ownership check (Let's Encrypt). OV (Organization Validation) — + legal entity verification. EV (Extended Validation) — + in-depth review, green address bar (deprecated in browsers 2019+).

Can I reuse a CSR?

Yes, you can reuse the same CSR (same key) on renewal. Rotating the key is the safer practice.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.