Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Generate a Linux certificate signing request (CSR) with OpenSSL’s req command. The usual one-line workflow is openssl req -new -newkey rsa:2048 -keyout example.com.key -out example.com.csr; add every DNS name or IP address the certificate must cover as a Subject Alternative Name (SAN), then verify the request locally before sending only the .csr file to your certificate authority (CA).
A CSR is a PKCS#10 request, not an issued certificate. It contains your subject details, public key, requested extensions and a proof-of-possession signature. It does not contain the private key. This guide covers interactive, noninteractive and configuration-file methods, key protection choices, SAN handling, verification and recovery from common errors.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11
What a CSR is—and what it is not
OpenSSL’s official req manual describes the command as the “PKCS#10 certificate request and certificate generating command.” In a normal web-server workflow, it creates a PKCS#10 certificate request that a CA uses as input when issuing a certificate.
The request carries four important types of information:
#1 Best Overall
- Subject: distinguished-name fields such as country, state, locality, organization and common name (CN).
- Public key: the public half of the key pair that will be associated with the eventual certificate.
- Requested extensions: especially Subject Alternative Name entries for DNS names and IP addresses.
- Proof-of-possession signature: a signature made with the corresponding private key, allowing the CA to confirm that the requester controls it.
The private key is generated alongside the CSR or supplied from an existing file, but it is never embedded in the CSR. Keep the key confidential; the CSR is the file normally delivered to the CA.
Prepare Linux and protect the files
Install and identify OpenSSL
Install the OpenSSL package supplied by your Linux distribution, then check exactly what is available:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
openssl version -aOpenSSL releases differ in defaults and option names. Newer documentation may call the unencrypted-key option -noenc, while many existing commands use -nodes. Read the local manual with man req if an option behaves differently from the examples here.
Use a private working directory
Create or enter a directory that only the administrator or the account running OpenSSL can read. Starting a shell with a restrictive umask prevents newly created keys and requests from being world-readable:
umask 077The private key in these examples is example.com.key; the request is example.com.csr. A configuration file containing organization details and SANs should also be protected. Use mode 0600 for that file:
chmod 600 csr.confDo not paste private-key text into a ticket, chat message or CA form. Back up the key through your organization’s approved secret-management or encrypted-backup process. Losing the key after issuance means the certificate cannot be used by the service that needs it.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Choose the CSR workflow that fits the job
| Workflow | Best for | Input style | Main considerations |
|---|---|---|---|
| Interactive request | A one-off request where an operator can answer prompts | OpenSSL asks for distinguished-name fields | Simple, but easy to mistype names and difficult to reproduce exactly |
Noninteractive -subj and -addext |
Automation or a single, known SAN set | All values appear in the command | Convenient for scripts; protect shell history and process visibility when appropriate |
| Configuration file | Several SANs, repeat issuance or a documented process | Values are kept in an INI-style file | Repeatable and auditable; the correct extension section must be selected |
You also need to decide whether to create a new key or reuse an existing one. Generate a new key when an old key may have been exposed or your policy requires rotation. Reuse is sometimes permitted for renewal or reissue, but it preserves the risk and lifetime of that existing key.
Option A: generate a new RSA key and CSR interactively
Run the command
With the restrictive umask set, run:
umask 077
openssl req -new -newkey rsa:2048 -keyout example.com.key -out example.com.csr-new asks OpenSSL to create a new request. -newkey rsa:2048 creates a new 2048-bit RSA key and, in this combined form, creates the request in the same operation. -keyout names the private-key file and -out names the CSR file.
Answer the prompts carefully
OpenSSL prompts for distinguished-name fields. Supply the values required by your CA and organization. The common name can identify one primary name, but modern certificate validation uses SAN entries for hostname and IP matching; do not rely on CN alone when multiple names are needed.
Depending on the OpenSSL release and options, the command may ask for a passphrase before writing the key. An encrypted key is safer at rest, but a service must receive the passphrase at startup. Plan how an administrator or a secret-management system will unlock it before choosing that protection.
Two-step equivalent
Ubuntu’s Server Guide documents the equivalent pattern of generating a key first and then creating a request:
openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csrThis separates key creation from CSR creation, which can be useful when the same key is intentionally used for a controlled reissue. The resulting key remains confidential regardless of which pattern you choose.
Option B: create a CSR from an existing private key
For a renewal or reissue where policy permits key reuse, point req at the existing key:
openssl req -new -key example.com.key -out example.com.csrOpenSSL reads the key and prompts for the subject fields. If the old key might have been copied, exposed or stored on an untrusted host, stop and generate a replacement instead. A new CSR does not make a compromised key safe.
Free tools Windows power users keep installed
One-click scans. No signup required.
Add SANs: the names the certificate must actually cover
List every DNS name and IP address that clients will use in Subject Alternative Name entries. Examples include example.com, www.example.com and an address such as 203.0.113.10. A CA may ignore requested extensions or apply its own policy, so inspect the finished CSR and confirm the CA’s current issuance requirements.
One-line, noninteractive command
For one known name set, provide the subject and SAN directly:
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj '/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com' -addext 'subjectAltName = DNS:example.com,DNS:www.example.com'-subj suppresses the interactive distinguished-name prompts. -addext adds the requested SAN extension. The example includes two DNS names; add comma-separated entries for each additional name and use the IP: prefix for an IP address, such as IP:203.0.113.10.
-nodes (called -noenc in newer OpenSSL documentation) leaves the generated private key unencrypted. Use this only when an unattended service must read the key during boot. Compensate with restrictive file permissions, host hardening and an approved secret-protection mechanism. An unencrypted key should never be treated as harmless just because it is on a server.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Rank #4
Why SAN is mandatory in practice
Certificate clients compare the requested hostname or address against SAN values. If the required name is absent, obtaining a certificate later does not repair this CSR; regenerate the request with the complete SAN list. Wildcards cover only one DNS label: a wildcard for *.example.com can match a single label such as www.example.com, not a deeper name such as api.dev.example.com. Use wildcards only when the CA and your security policy allow them.
Use a configuration file for repeatable or larger requests
Create csr.conf
A configuration file makes the requested names visible, reviewable and easy to reproduce. Save the following as csr.conf, then restrict it with chmod 600 csr.conf:
[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
C = US
ST = California
L = San Francisco
O = Example Inc
CN = example.com
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
IP.1 = 203.0.113.10prompt = no tells OpenSSL to use the values in the file rather than ask questions. The req_extensions setting selects the section that requests SANs; @alt_names points to the numbered DNS and IP entries.
Generate the request from the file
umask 077
openssl req -new -newkey rsa:2048 -keyout example.com.key -out example.com.csr -config csr.confThe req command also supports -reqexts, -extensions and -addext for supplying extensions. Exact section names and whether a CA honors requested extensions can vary by OpenSSL release and CA policy. Do not assume that merely writing a section means it was included; inspect the resulting request.
Recommended Free Tools
Understand encrypted and unencrypted private keys
Encrypted key at rest
An encrypted private key requires a passphrase whenever a process opens it. This limits damage if someone obtains the file, but it introduces an operational dependency: the web server, reverse proxy or other service must get the passphrase at startup. Document the unlock procedure and test restarts before production use.
Unencrypted key for unattended startup
An unattended service may require a key that can be read without human input. In that case, use -nodes or the newer -noenc spelling only with strict permissions and host-level controls. Ensure the key directory is not shared, backups are encrypted, and only the service account or administrators can read the file.
Best Value
Key rotation decision
- Create a new key for normal rotation, suspected exposure, host migration to an untrusted system or a policy that requires fresh key material.
- Reuse an existing key only when the organization and CA permit it and the key’s custody is known to be sound.
- Regardless of the choice, verify that the public-key algorithm and size satisfy the CA and platform policy before submitting.
Inspect and verify the CSR before submission
Run the full inspection command first:
openssl req -in example.com.csr -noout -text -verify-text prints the request in readable form, while -verify checks the CSR’s proof-of-possession signature. A successful verification confirms that the request is internally signed by the matching private key; it does not mean the CA will approve the order.
Check the subject separately
openssl req -in example.com.csr -noout -subjectCompare the displayed distinguished name with the organization’s approved values. Look for spelling, punctuation, country code and common-name mistakes before submission.
Inspect the public key
openssl req -in example.com.csr -noout -pubkeyConfirm that the algorithm and key size match the CA or internal policy. The private key itself is not printed by this command.
Review the SAN extension and file encoding
In the -text output, locate the requested extensions and verify every required DNS and IP entry. If the request is PEM encoded, it normally starts with -----BEGIN CERTIFICATE REQUEST----- and ends with -----END CERTIFICATE REQUEST-----. A missing SAN, wrong name or unexpected key type is a reason to regenerate the CSR rather than submit it.
Submit the correct file to the CA
Send example.com.csr to the CA through its approved enrollment channel. The CA may ask for domain control validation, organization details or a specific key algorithm in addition to the request. Upload or paste the CSR text exactly as generated, including its PEM boundary lines when the enrollment form expects PEM.
Never send example.com.key. The CA needs the public-key request, not your private key. Keep the key on the Linux host or in the approved key-management system and use it later when installing the issued certificate.
Troubleshoot common failures
| Symptom | Likely cause | Correction |
|---|---|---|
Unable to load config info or no prompts appear |
OpenSSL cannot find the distribution configuration, or the command is relying on unavailable defaults | Specify the distribution’s configuration with -config, or use explicit -subj and -addext arguments. |
SAN is absent from -text output |
The extension section was not selected, or the option was misspelled | Use req_extensions, -reqexts or -addext correctly and regenerate the CSR. A later certificate cannot add SANs that were omitted from the request if the CA policy does not supply them. |
| Permission denied while writing files | The directory belongs to another account or is not writable | Create the files in a directory owned by the account running OpenSSL and keep restrictive permissions. Do not make the key world-readable to bypass the error. |
| Certificate will not match the intended hostname | A DNS name or IP address is missing or mistyped | Regenerate the CSR with the complete SAN list. Check wildcard scope and spelling in the inspected output. |
| CA rejects the CSR | Key type, size, subject format, SAN set or signature algorithm conflicts with current issuance rules | Compare the request with the CA’s current requirements and your organization’s policy, then generate a corrected request. |
| Service cannot start after key installation | The key is encrypted and the service has no passphrase mechanism, or file permissions block the service account | Provide the approved startup secret or adjust ownership and mode securely. Do not remove encryption or broaden permissions without an explicit operational decision. |
RSA and other key algorithms: follow the receiving policy
The examples use a 2048-bit RSA key because it is broadly recognized, but the correct algorithm is not decided by the CSR command alone. OpenSSL supports multiple key-generation forms; the issuing CA, operating system, application stack and organization policy determine what is accepted. Before generating a large batch of requests, confirm the permitted algorithm, minimum size, signature requirements and SAN rules with the CA and the platform that will terminate TLS.
A concise pre-submission checklist
- Install the distribution’s OpenSSL package and record the result of
openssl version -a. - Work in an administrator-controlled directory and set
umask 077. - Choose a new key or an approved existing key; rotate if exposure is possible.
- Choose interactive prompts, explicit
-subj/-addextoptions or a protected configuration file. - Include every DNS name and IP address in SAN entries, not just in CN.
- Decide deliberately whether the private key is encrypted and document how the service will unlock it.
- Run
openssl req -in example.com.csr -noout -text -verify. - Check the subject, SAN list, public-key algorithm and key size against policy.
- Submit only the CSR file and retain the private key under secure control.
Following this sequence produces a request the CA can evaluate while preserving control of the private key and exposing naming or policy errors before they delay certificate issuance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
