How to Generate a CSR in Windows

This guide shows you how to generate a CSR (Certificate Signing Request) on Windows using the tools that ship with the operating system.

The CSR is a PKCS #10 text block that carries your public key and subject details to the Certificate Authority, which signs it and returns your SSL/TLS certificate. The matching private key stays on the machine that generates the request.

Windows gives you three native ways to build a CSR, and each one is covered below. Pick the one that fits your workflow:

• The Certificates MMC snap-in (graphical), which walks you through a wizard and lets you add a Subject Alternative Name. This is the path the original tutorial covered, and the one most users want.
• The certreq.exe command-line tool with an INF file, which is scriptable, supports SAN, and is the standard method on Windows Server.
• The OpenSSL for Windows binary (a separate download), which produces the CSR exactly the way Linux administrators do it.

If you run a web server with its own CSR workflow, use that instead of the generic Windows steps: see the dedicated guides for IIS and Microsoft Exchange. The steps below cover Windows 10, Windows 11, and Windows Server 2016 through 2025; sign in with an account that has local administrator rights before you start.

Generate a CSR with the Certificates MMC snap-in

The Microsoft Management Console (MMC) ships with every supported version of Windows and exposes a Create Custom Request wizard that can build a CSR with a SAN entry. The wizard stores the new private key in the Local Computer certificate store, so any Windows service on the machine (IIS, ADFS, RD Gateway, RDP) can use the issued certificate once it is installed.

Step 1: Open the MMC Certificates snap-in for the Local Computer

Press Win + R, type the command below, and press Enter:

mmc

In the empty MMC console, open File > Add/Remove Snap-in. Select Certificates in the left list, click Add, choose Computer account, click Next, leave Local computer selected, and click Finish, then OK. The Certificates snap-in is now anchored to the Local Computer store, which is what Windows services read from.

Step 2: Start a custom certificate request

In the left pane, expand Certificates (Local Computer) and right-click Personal. Choose All Tasks > Advanced Operations > Create Custom Request. The Certificate Enrollment wizard opens. Click Next.

On the Select Certificate Enrollment Policy screen, select Proceed without enrollment policy under Custom Request and click Next. This tells Windows to build a standalone CSR for an external CA rather than enrolling against an internal Active Directory Certificate Services template.

Step 3: Pick the template and request format

On the Custom request screen, set Template to (No template) CNG key, leave Request format on PKCS #10, and click Next. CNG (Cryptography Next Generation) is the modern Windows key provider and is the right choice for new requests; the legacy CSP option is only needed for compatibility with older applications.

On the Certificate Information screen, expand the Details arrow next to the request entry and click Properties. The Certificate Properties dialog is where the rest of the CSR is configured.

Step 4: Fill in the subject and Subject Alternative Names

On the General tab, type a friendly name and an optional description so you can identify the pending request later in the certificate store.

Switch to the Subject tab. In Subject name, leave Type on Full DN only if you know what you are doing; for most orders, add each component one at a time using the Type dropdown. For every attribute below, pick the type, type the value, and click Add:

• Common Name: the fully qualified domain name you want to secure, for example www.yourdomain.com. For a wildcard certificate, put an asterisk in front of the apex domain, for example *.yourdomain.com.
• Country: the two-letter ISO country code, for example US, GB, or DE.
• State: the full state or province name (for example California, not CA).
• Locality: the full city name where your organization is registered (for example San Jose, not SJ).
• Organization: the legal name of your company, exactly as registered. Required for OV and EV certificates. For Domain Validation (DV) certificates, this field is ignored, so any placeholder works.

Skip the Email attribute. RFC 5280 says new certificates with an email address must place it in the Subject Alternative Name extension (as an rfc822Name), not in the subject Distinguished Name, and public CAs may strip an email value from the subject of a TLS certificate. Leaving it out keeps the CSR clean.

In the Alternative name section of the same tab, set Type to DNS and add every hostname the certificate must cover, one click of Add per entry. Always list the Common Name here as well: browsers, .NET, Java, Go, and other modern TLS clients validate the hostname strictly against the SAN list and ignore the Common Name. A typical web certificate uses two DNS entries:

• yourdomain.com
• www.yourdomain.com

For a wildcard order, add the wildcard and the apex: *.yourdomain.com and yourdomain.com.

Step 5: Configure the key and signature

Switch to the Private Key tab and expand each section in turn.

• Cryptographic Service Provider: leave the default RSA, Microsoft Software Key Storage Provider selected. This is the modern CNG provider for RSA keys.
• Key options: set Key size to 2048 (the current public-CA minimum). Pick 3072 or 4096 only if your policy demands a larger key; the trade-off is slightly slower TLS handshakes. Tick Make private key exportable if you want the option to back the key up or move the issued certificate to another server.
• Select Hash Algorithm: in the Select hash algorithm section, choose sha256. SHA-1 is no longer accepted by public CAs and SHA-256 is the modern default. Leave the Use alternate signature format checkbox off.

Click OK to close the properties dialog, then click Next on the wizard.

Step 6: Save the CSR file

On the Where do you want to save the offline request? screen, set File format to Base 64 (CAs expect base64-encoded PEM, not binary). Click Browse, pick a folder you can find again (a dedicated C:\certs\ folder or the Desktop is easier than the default Windows path), give the file a name with a .req or .txt extension, and click Save. Click Finish to write the CSR.

The wizard writes the CSR to the file and stores the matching private key in Certificates (Local Computer) > Certificate Enrollment Requests. Do not delete that pending request: when the CA returns the issued certificate, Windows pairs it with the waiting key automatically.

Step 7: Copy the CSR and submit it to the CA

Open the saved file in Notepad. You should see a block that looks like this:

-----BEGIN CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----

Select the entire block, including the five-hyphen BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, copy it, and paste it into the CSR field on your SSL order form.

Generate a CSR with certreq.exe and an INF file

The certreq.exe command-line utility ships with every version of Windows Server and is also present on Windows 10 and 11 client. It is the right method when you want to script CSR creation, set unusual key parameters, or build the request remotely over a session that cannot run MMC. The flow has three parts: write a request INF file, run certreq -new to generate the CSR, then submit the CSR to your CA.

Step 1: Create the request INF file

Open Notepad as Administrator and save the file below as request.inf. Edit the Subject line and the DNS entries under [Extensions] to match your domain:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=www.yourdomain.com, O=Your Company, L=San Jose, S=California, C=US"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=www.yourdomain.com&"
_continue_ = "dns=yourdomain.com"

Notes on the values:

• Subject: a single line with the components separated by commas. Use the two-letter ISO country code in C=, and write the state and city names in full.
• KeyLength: 2048 minimum. Set 3072 or 4096 if your policy requires a larger key.
• Exportable = TRUE: lets you export the private key together with the issued certificate (for backup or to install on a second server). Set it to FALSE if you want the key locked to this machine.
• MachineKeySet = TRUE: stores the key in the Local Computer store, which is what services such as IIS read from. Leave this on for server workloads.
• HashAlgorithm = SHA256: signs the request with SHA-256, the modern default. Older examples sometimes default to SHA-1, which public CAs no longer accept.
• 2.5.29.17: the OID for Subject Alternative Name. Add one _continue_ line per hostname; every line except the last must end with the & separator. List your Common Name here too, because TLS clients validate against the SAN list.

Step 2: Generate the CSR

Open an elevated Command Prompt or PowerShell, change to the folder that contains request.inf, and run:

certreq -new request.inf request.csr

The tool creates the private key in the Local Computer store and writes the PKCS #10 request to request.csr. Open the file, copy the full BEGIN CERTIFICATE REQUEST to END CERTIFICATE REQUEST block, and paste it into your order form.

When the CA returns the issued certificate, complete the pairing with:

certreq -accept certnew.cer

This binds the issued certificate to the private key that has been waiting in the store, after which the certificate is available to any Windows service that needs it.

Generate a CSR on Windows with OpenSSL

Windows does not ship OpenSSL, but a maintained Windows build is available from Shining Light Productions. The OpenSSL flow is identical to the Linux one and produces a key and a CSR as two separate files, which is useful if you plan to deploy the certificate to a platform that does not use the Windows certificate store (for example a third-party reverse proxy, Tomcat, or a custom application).

Install the Win64 OpenSSL Light package (the regular installer is enough for CSR work) and, when the setup asks, copy the OpenSSL DLLs to the OpenSSL bin directory rather than to the Windows system folder. Open Command Prompt or PowerShell and confirm OpenSSL is on the path:

openssl version

If the command is not found, either add the installation folder (typically C:\Program Files\OpenSSL-Win64\bin) to your PATH or call openssl with the full path. Then generate the CSR and the key with a single command:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr -subj "/C=US/ST=California/L=San Jose/O=Your Company/CN=www.yourdomain.com" -addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

What each flag does:

• -newkey rsa:2048 creates a fresh 2048-bit RSA key. Use rsa:4096 for a larger key if your policy requires one.
• -nodes writes the private key without a passphrase so the consuming service can read it at startup without prompting. OpenSSL 3.x renamed this flag to -noenc; -nodes still works but is considered deprecated.
• -keyout and -out name the key file and the CSR file.
• -subj supplies the subject inline so OpenSSL does not stop to ask interactive questions.
• -addext “subjectAltName=…” adds the SAN list. Include the Common Name here too.

OpenSSL 3.x signs the CSR with SHA-256 by default, so no extra digest flag is needed. Treat the resulting yourdomain.key as a secret: anyone who has it can impersonate the certificate.

Verify the CSR before you submit it

Confirm the Common Name, SAN entries, key size, and signature algorithm before sending the request to your CA. From the Windows command line, certutil reads any CSR file:

certutil -dump request.csr

If you installed OpenSSL, the equivalent command prints the same details:

openssl req -noout -text -in request.csr

Prefer a browser? Paste the contents of the request into SSL Dragon’s CSR decoder to read back the subject, SAN list, key size, and signature algorithm. Confirm that the Common Name matches the hostname clients will use, that every required name appears under the SAN list, and that the signature algorithm is sha256WithRSAEncryption (or stronger).

If you would rather generate the CSR off the server, our CSR Generator builds a request (with SAN) from a single form. The trade-off is that the private key is generated in your browser, not in the Windows store, so when the CA issues the certificate you combine the certificate and the key into a .pfx file and import it through the certificate management console of your application.

Frequently Asked Questions