How to Generate a CSR for SSL Certificate Requests

Before you can obtain an SSL Certificate from a Certificate Authority (CA) like RapidSSL, GeoTrust, or DigiCert, you need to generate a Certificate Signing Request (CSR). This guide walks you through the entire process on both Linux and Windows, explaining each field you need to fill in.

What is a CSR?

A CSR (Certificate Signing Request) is a text file containing information about your organization and domain, along with a Public Key linked to a Private Key generated at the same time. When you submit a CSR to a CA, they use the information in it to create a signed SSL Certificate for your domain.

The CSR workflow works as follows:

1. You generate a Private Key and CSR on your server
2. You submit the CSR (not the Private Key) to the CA
3. The CA verifies the information and issues your Certificate
4. You install the Certificate and Private Key on your server

What's Inside a CSR (CN, O, OU, SAN)

When you decode a CSR, you'll find it contains two main parts: the Subject (identity information about the domain or organization) and the Public Key that the CA will sign. The Subject is made up of several standard fields, each playing a different role and affecting the type of certificate you receive. Understanding what each field means helps you fill in the data correctly the first time, so you don't have to regenerate the CSR multiple times.

The most important fields in every CSR are:

• CN (Common Name) — The primary domain the certificate will protect. This is the most important field and must match your real domain exactly, e.g., shop.example.com
• O (Organization) — Your registered company name. Required for OV/EV SSL because the CA verifies it against legal business documents. For DV SSL this field is usually not displayed in the certificate
• OU (Organizational Unit) — A department within the organization, e.g., IT or Web Operations. This is optional, and most CAs are now phasing out this field
• L / ST / C — Locality (city), State/Province, and the two-letter Country code, e.g., Bangkok / Bangkok / TH
• SAN (Subject Alternative Name) — A list of additional domains the same certificate will cover, e.g., both example.com and www.example.com. Modern browsers rely on SAN as the source of truth, not just the CN

Information Required Before Generating a CSR

Prepare the following information before generating your CSR:

• Common Name (CN) — The domain name you want SSL for, e.g., yourdomain.com or www.yourdomain.com
• Organization (O) — Your company name as registered (required for OV/EV SSL)
• Organizational Unit (OU) — Department, e.g., IT Department
• City/Locality (L) — Your city, e.g., Bangkok
• State/Province (ST) — Your province/state, e.g., Bangkok
• Country (C) — Two-letter country code, e.g., TH
• Email Address — Administrator email

Generate a CSR on Linux Using OpenSSL

OpenSSL is pre-installed on most Linux systems. Run the following commands in your terminal:

Step 1: Generate Private Key and CSR Together

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key \
  -out yourdomain.csr

This command prompts you for each field and creates two files:

• yourdomain.key — Your Private Key (keep this on the server, never share it)
• yourdomain.csr — The CSR to submit to your CA

Step 2: Non-Interactive (One-Line Command)

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key \
  -out yourdomain.csr \
  -subj "/C=TH/ST=Bangkok/L=Bangkok/O=Your Company/OU=IT/CN=yourdomain.com"

Step 3: Verify the CSR Content

openssl req -text -noout -verify -in yourdomain.csr

This command displays all the information in your CSR so you can verify it before submitting to the CA.

Generate a CSR on Windows

On Windows, you can generate a CSR through IIS Manager or by installing OpenSSL for Windows.

Method 1: Using IIS Manager

1. Open IIS Manager and click on your server
2. Double-click Server Certificates, then click Create Certificate Request
3. Fill in the Distinguished Name Properties
4. Select Microsoft RSA SChannel as the Cryptographic Service Provider and set Bit Length to 2048
5. Save the resulting .txt file — this is your CSR

Method 2: OpenSSL on Windows

Download OpenSSL for Windows from slproweb.com, then run the same commands as Linux in Command Prompt or PowerShell.

Generate a CSR via DirectAdmin (No Commands Needed)

If you use hosting or a VPS with DirectAdmin (such as AsiaGB packages), you can generate a CSR and Private Key directly from the web interface without opening a terminal. DirectAdmin stores the Private Key on the server automatically, reducing the risk of the key leaking while copying files around. Follow these steps:

1. Log in to DirectAdmin and go to the SSL Certificates menu under the target domain
2. Choose the Create A Certificate Request option
3. Fill in all CSR fields: Common Name (domain), Email, Organization, City, State, Country, and Key Size (choose 2048 or higher)
4. If supported, add SAN entries in the More Certificate Names box to cover both example.com and www.example.com
5. Click Save — DirectAdmin generates and stores the Private Key, then displays the CSR (the -----BEGIN CERTIFICATE REQUEST----- block) for you to copy

Copy the entire CSR block and paste it into your SSL order form. Once the CA issues your certificate, you can paste it straight into DirectAdmin's Paste a pre-generated certificate and key menu, since the matching Private Key is already stored. For full installation steps, see Install SSL Certificate on DirectAdmin.

Filling In the CSR Correctly (CN Match, Wildcard *.domain.com)

The most common reason a CA rejects a CSR or issues a certificate for the wrong domain is a Common Name that doesn't match the domain you actually intend to use. Choosing the right CN format for your certificate type is therefore critical. The table below summarizes how to fill in the CN for each scenario:

A common misunderstanding about Wildcards is that *.example.com only covers first-level subdomains such as blog.example.com or shop.example.com. It does not cover the bare domain example.com, and it does not cover nested subdomains like a.b.example.com. If you also want the bare domain to work, you must add example.com to the SAN of the CSR.

Generating a Wildcard + SAN CSR with OpenSSL

OpenSSL doesn't accept SAN entries directly through -subj; you need a config file first, such as san.cnf:

[ req ]
default_bits       = 2048
distinguished_name = dn
req_extensions     = req_ext
prompt             = no

[ dn ]
C  = TH
ST = Bangkok
L  = Bangkok
O  = Your Company
CN = *.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = example.com
DNS.2 = *.example.com

Then generate the CSR referencing this config file:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.key \
  -out example.csr \
  -config san.cnf

Verifying the CSR and Keeping the Private Key Safe

Before submitting a CSR to a CA, always inspect its contents to confirm that the CN, Organization, and SAN values are all correct. A small mistake — like a single mistyped character in the CN — can force you to reissue the entire certificate. Use this command to view the CSR contents in a readable format:

openssl req -noout -text -in example.csr

Look at the Subject: line to check CN/O/C, and look for X509v3 Subject Alternative Name: to confirm the SAN entries you intended are all present. To verify that a CSR and Private Key are a matching pair, compare the modulus of both files:

openssl req -noout -modulus -in example.csr | openssl md5
openssl rsa -noout -modulus -in example.key | openssl md5

The two md5 outputs must be identical. If they differ, the CSR and Private Key are not a matching pair, and the server will refuse to start HTTPS once installed.

Keeping the Private Key Safe

• Restrict file permissions as tightly as possible with chmod 600 example.key so only the owner can read it
• Keep the Private Key on the server only — never send it by email or chat, and never commit it to a Git repository
• Back up the Private Key in a secure location (a password manager or secret vault), because losing it means you can't install the certificate you receive
• If you suspect the Private Key has leaked, revoke the certificate and generate a fresh CSR and key immediately

Reading and Submitting Your CSR

Your CSR file is Base64-encoded and looks like this:

-----BEGIN CERTIFICATE REQUEST-----
MIICpDCCAYwCAQAwXzELMAkGA1UEBhMCVEgxEDAOBgNVBAgMB0Jhbmdrb2sxEDAO
...
-----END CERTIFICATE REQUEST-----

Copy the entire text including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines, then paste it into the SSL order form when purchasing from AsiaGB.

Common CSR Errors to Avoid

• Common Name mismatch — Ensure the CN exactly matches the domain you want to secure (with or without www)
• Special characters in fields — Avoid &, @, !, # in organization fields; use alphanumeric characters only
• Mismatched Private Key and CSR — If you generate them separately, use the matching pair
• Insufficient key length — Use RSA 2048-bit or higher, or ECDSA 256-bit

Frequently Asked Questions About CSRs

Do I need to generate a new Private Key every time I create a CSR?

It's generally recommended to generate a new Private Key together with each new CSR because it's more secure. Technically, however, you can create a new CSR from an existing Private Key using openssl req -new -key example.key -out new.csr. This is useful when renewing a certificate while keeping the same key. That said, generating a fresh key each time reduces the risk if the old key was ever exposed.

Does a CSR expire?

The CSR file itself does not expire — you can store it and submit it to a CA at any time. In practice, though, you should generate a new CSR each time you request a certificate, because your organization details or the CA's policies (such as minimum key size) may have changed. It's the certificate issued from the CSR that has an expiry date, based on the certificate's validity period.

Can I reuse an old CSR to renew SSL?

Yes, but it's not recommended. Renewing with an old CSR means continuing to use the same Private Key. If that key has been in use for a long time or is at risk of leaking, it's safer to generate a fresh CSR and Private Key. Most CA systems support both approaches — simply paste the CSR during the renewal step as usual.

What's the difference between RSA 2048 and ECDSA, and which should I choose?

RSA 2048-bit is the most widely supported standard and is compatible with every older server. ECDSA (such as P-256) offers equivalent security with a smaller key size, making handshakes slightly faster. Unless you have special requirements, RSA 2048 is sufficient and secure for typical websites.