Generate a certificate signing request (CSR) and its matching private key with OpenSSL, then send only the CSR to your certificate authority (CA). A current, non-interactive command is:
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
openssl req -new -newkey rsa:2048 -noenc
-keyout server.key -out server.csr
-subj "/C=US/ST=State/L=City/O=Example Org/CN=example.com"
-addext "subjectAltName=DNS:example.com"This creates server.key, which must remain secret on the server, and server.csr, which contains the requested identity and public key for CA processing. The OpenSSL Project describes req as the command that “primarily creates and processes certificate requests (CSRs) in PKCS#10 format.”
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
What a CSR is and what OpenSSL creates
A certificate signing request is a PKCS#10 document that asks a certificate authority to issue a certificate for one or more identities. It contains the subject information you request, the server’s public key, and a signature made with the corresponding private key. The CA validates your control of the requested name and applies its own issuance policy before returning a signed certificate.
The command creates two separate files:
| File | Contents | What to do with it |
|---|---|---|
server.key |
The private key used by the server and to sign the CSR | Keep it on the server, restrict its permissions, and never send it to the CA |
server.csr |
The PKCS#10 request containing the subject, requested extensions, and public key | Inspect it locally, then submit this file to the CA |
The CSR is not a certificate. It becomes useful only after the CA signs and returns a certificate, usually together with one or more intermediate certificates.
Prepare the Linux server before generating files
Confirm the names the certificate must cover
Write down every fully qualified domain name that users or systems will actually use. For a site reached as both example.com and www.example.com, request both names. Include service-specific names such as an API or mail endpoint only when that service needs them and you control them. Do not request a hostname merely because it exists in internal notes; the CA may require proof that you control each requested name.
Modern TLS validation uses the Subject Alternative Name (SAN) extension. Put the names in SAN even when one of them is also copied into the Common Name (CN). Treat the CN as a descriptive subject field, not as a substitute for SAN.
Check that OpenSSL is available
Run:
openssl versionIf the shell reports that the command is missing, install the OpenSSL package supplied by your Linux distribution, then run the version check again. The exact package name and installation command depend on the distribution and its configured repositories. Use the version shipped and supported by that operating system rather than downloading an unrelated binary.
Choose a protected working directory
Generate the key where the service can later read it but ordinary users cannot. A temporary working directory is acceptable only if you move the key into the service’s protected key directory immediately afterward. Check free space and make sure backups, shell history, terminal logging, and automated support tools will not expose the private key.
Generate an RSA CSR and private key non-interactively
Replace the example subject values and DNS names with the values approved for your certificate. Then run:
openssl req -new -newkey rsa:2048 -noenc
-keyout server.key -out server.csr
-subj "/C=US/ST=State/L=City/O=Example Org/CN=example.com"
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"On success, OpenSSL writes the private key to server.key and the CSR to server.csr. If files with those names already exist, stop and decide whether this is a new request or a planned key rotation before allowing them to be replaced.
Understand each option
| Option | Purpose |
|---|---|
req |
Creates and processes certificate requests in PKCS#10 format. |
-new |
Creates a new certificate request. |
-newkey rsa:2048 |
Generates a new 2048-bit RSA key for the request. |
-noenc |
Writes the newly generated private key without a passphrase, allowing a service to start unattended. Protect the file and directory carefully because possession of the file is sufficient to use the key. |
-keyout server.key |
Sets the output path for the private key. |
-out server.csr |
Sets the output path for the CSR. |
-subj |
Supplies the distinguished-name fields without interactive prompts. |
-addext |
Adds a request extension, here the SAN list. |
The values in -subj are separated by slashes: country (C), state or province (ST), locality (L), organization (O), and common name (CN). A CA may ignore, normalize, or reject some subject fields according to its enrollment policy, so use the CA’s current requirements when it specifies a different format.
Use the interactive mode when you need prompts
If you omit -subj, OpenSSL asks for distinguished-name values such as country, organization, and common name. This can be useful for a one-off request when you want to review each prompt. It is less suitable for repeatable provisioning because a typo or an accidental blank value can produce a request that does not match the approved names. Interactive input also does not automatically guarantee that SAN values are present; add SAN explicitly or use a configuration file.
Put every required DNS name in SAN
Inline SAN with -addext
For a short, stable list, place each DNS name in one comma-separated extension:
-addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:api.example.com"Use the exact spelling that clients will send in the TLS connection. A name omitted from SAN may produce a hostname-mismatch warning even when it appears in the CN. Do not include names that are not needed or that you cannot validate with the CA.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use a configuration file for larger or repeatable requests
A configuration file is easier to review when a request has many names or is generated repeatedly. Create a file such as csr.conf with the required subject and a request-extension section:
[req]
prompt = no
distinguished_name = dn
req_extensions = req_ext
[dn]
C = US
ST = State
L = City
O = Example Org
CN = example.com
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.comGenerate the request by referencing that file:
openssl req -new -newkey rsa:2048 -noenc
-keyout server.key -out server.csr
-config csr.confThe important detail is the link between req_extensions, the subjectAltName = @alt_names line, and the numbered DNS entries. Red Hat’s security documentation demonstrates this SAN-section pattern. Review the resulting CSR rather than assuming the configuration was parsed as intended.
Other identity types
This procedure is written for DNS names. If a CA requires another identity type, such as an IP address, use the extension syntax and policy that the CA documents. Do not label an IP address as a DNS name, and do not add an identity merely to make a configuration file appear complete.
Inspect and verify the CSR before submission
Always inspect the generated request:
openssl req -in server.csr -noout -text -verifyThis displays the subject, public-key algorithm, requested extensions, and signature-verification result without writing a second CSR. Check all of the following:
- The subject fields match the approved request.
- Every required DNS name appears under X509v3 Subject Alternative Name.
- There are no misspellings, stale hostnames, or unintended internal names.
- The public-key algorithm and key size meet the CA and service policy.
- The final line reports successful CSR signature verification.
If SAN is absent or incorrect, do not submit the file. Correct the command or configuration and generate a new request, preferably with a new key if the original request was distributed or logged.
Check the private key itself
Run:
openssl pkey -in server.key -check -nooutThis checks the internal consistency of the private key. Red Hat documents openssl pkey -check for this purpose. A successful check does not authorize sending the key anywhere; it only confirms that the file is structurally usable.
Match the key to the CSR
The CSR contains the public key corresponding to the private key. If you generated several requests, label directories and files clearly so that a certificate is installed with the matching key. Do not rely on filenames alone when a rotation is in progress; retain a documented mapping between the request, key, certificate, and service configuration.
Protect the private key on Linux
Immediately restrict the file:
chmod 600 server.keyThis allows the file owner to read and write it while denying access to other users. Ensure the parent directory is also protected, and set ownership to the account that legitimately runs the TLS service. Avoid placing private keys in world-readable web roots, shared upload directories, source-control repositories, ticket attachments, or chat messages.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The -noenc form creates an unencrypted key so an automated service can start without an operator typing a passphrase. That convenience increases the importance of filesystem permissions, host access controls, backups, and monitoring. If your service and operating procedure support encrypted keys, follow the service’s documented key-unlock process instead; the CA does not need the passphrase or the private key.
Back up a production key only through an approved, access-controlled backup system. Test that the backup can be restored securely, and document who can retrieve it. Never email the key to a CA, a vendor, or a support mailbox.
Submit the CSR and install the issued certificate
- Confirm the fully qualified domain names and the CA’s current subject and SAN policy.
- Generate
server.keyandserver.csrwith OpenSSL. - Apply restrictive ownership and permissions, including
chmod 600 server.key. - Run both verification commands and correct any mismatch before continuing.
- Submit only
server.csrthrough the CA’s enrollment portal or documented API. - Complete the CA’s domain or organization validation process.
- Save the issued certificate and any required intermediate chain in the locations specified by your web server or application.
- Update the service configuration to reference the certificate and the matching private key, then reload or restart the service according to its documentation.
The CA uses the CSR to issue the certificate; it does not need your private key. The exact certificate filename, chain order, configuration directive, and reload command vary by server software, so follow that application’s installation instructions rather than copying a command intended for another daemon.
RSA versus elliptic-curve keys
The example uses a 2048-bit RSA key because it is broadly represented in CA and server examples. An elliptic-curve key can be appropriate when your CA, TLS stack, and operational policy all support the selected curve and certificate profile. There is no single algorithm that is correct for every CA or deployment.
| Decision factor | Questions to answer |
|---|---|
| CA compatibility | Does the CA accept the algorithm and key parameters for this certificate profile? |
| Application compatibility | Will every client, load balancer, proxy, operating system, and library that uses the certificate support it? |
| Security policy | Does your organization mandate a particular algorithm, key size, or curve? |
| Performance | Do handshake and CPU characteristics matter for this service’s traffic pattern? |
| Operations | Can your monitoring, backup, renewal, and incident procedures handle the chosen key type? |
The cited OpenSSL and Red Hat procedures establish the controls for generating and checking keys and CSRs; they do not establish one universal algorithm choice for every environment. Choose the algorithm only after checking the CA and application requirements.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common mistakes and recovery steps
Sending the private key to the CA
A CA needs the CSR, not server.key. If the key was exposed, treat it as compromised: stop using the corresponding certificate, generate a replacement key and CSR, request revocation or replacement as required by the CA, and update the service with the new pair.
Putting the hostname only in CN
Regenerate the request with every client-facing DNS name in SAN. Inspect the CSR and confirm the SAN extension before submission; changing the CN alone does not repair an omitted SAN.
Requesting an incorrect or uncontrolled name
Stop the enrollment and create a corrected CSR. A CA may reject the name, or a certificate containing an unnecessary name may broaden the impact of a later key compromise.
Recommended Free Tools
Skipping inspection
Run openssl req -in server.csr -noout -text -verify and openssl pkey -in server.key -check -noout before upload. These checks catch transcription errors and malformed files while recovery is still cheap.
Overwriting a production key
Do not reuse server.key blindly. Preserve the currently deployed key and certificate as a rollback pair, generate the replacement under a distinct filename, test the new certificate, and record the planned cutover and rollback steps. Delete retired keys only under your organization’s retention and incident-response policy.
CSR verification fails
Check that the file was transferred without truncation, that you are reading the intended CSR, and that the command completed without an error. Regenerate the request if necessary rather than editing the CSR as text; a CSR is a signed binary structure, not a document to modify manually.
The certificate still produces a name warning
Inspect the issued certificate, not just the CSR, and compare its SAN list with the hostname the client uses. The CA may have applied its own policy or omitted a requested name. Ask the CA to correct the issuance, then install the corrected certificate and the required chain.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesA repeatable renewal and rotation checklist
- Inventory the names currently served and the names required after renewal.
- Confirm the CA’s current validation and subject requirements.
- Decide whether policy calls for a new key; do not overwrite the live key by accident.
- Generate the CSR and private key in a protected directory.
- Set ownership and
chmod 600on the private key. - Verify the CSR subject, SAN, public key, and signature.
- Verify private-key consistency.
- Submit only the CSR.
- Install the returned certificate and chain with the matching key.
- Reload the service, test every required hostname, and retain a documented rollback pair until the change is proven.
Following this sequence keeps identity selection, key custody, CA submission, and service deployment as separate, auditable steps.
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.
