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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Generate both files with OpenSSL using one command, then verify them before sending anything to your certificate authority (CA):
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"The command writes the private key to server.key and the certificate signing request (CSR) to server.csr. Keep the key on the server; submit only the CSR to the CA.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What a CSR and private key do
A TLS certificate request always involves a key pair. The private key stays under your control, while the CSR carries the public key and the names you want the CA to certify.
server.key: the private key
server.key contains the private half of the key pair generated by OpenSSL. A web server or other TLS service uses it to prove possession of the certificate’s corresponding key. Anyone who obtains the file may be able to impersonate the service, so do not email it, upload it to a support ticket, or send it to the CA. Restrict its permissions and store it in the service’s protected key directory.
server.csr: the signing request
server.csr is a PKCS#10 certificate signing request. It contains the requested subject, the public key, and any requested extensions such as Subject Alternative Name (SAN). The CA uses this file to decide whether and how to issue a certificate. A CSR does not become a certificate by itself; the CA must sign and return the issued certificate and, when required, an intermediate chain.
Prepare the Linux server
Confirm every name the certificate must cover
List the fully qualified domain names that users will actually access. A certificate for example.com does not automatically cover www.example.com unless that name is included as a SAN. Include each required DNS name in the request, and remove names that the service will not use or that you cannot control.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Check the CA’s enrollment policy
Before generating files, check the CA’s current requirements for subject fields, SANs, key algorithms, validation, and any organization information. The exact distinguished-name fields accepted by a CA can vary. A syntactically valid CSR can still be rejected if it asks for a name or identity that the CA’s policy does not permit.
Make sure OpenSSL is available
The procedure uses the openssl command-line program. Run openssl version to confirm that it is installed and that the shell can find it. If the command is missing, install OpenSSL through your Linux distribution’s normal package-management process, then run the version check again. Use a protected working directory rather than a shared temporary location while creating the key.
Generate an RSA CSR and private key
Run this non-interactive command after replacing the example identity values with the values required for your server:
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"OpenSSL’s req command creates and processes certificate requests in PKCS#10 format. In this invocation it generates a new RSA key, writes the private key and CSR to separate files, sets the subject from the supplied string, and adds a SAN extension.
Free tools Windows power users keep installed
One-click scans. No signup required.
Understand each option
| Option | Purpose | What to change |
|---|---|---|
req |
Creates and processes certificate requests. | Leave it unchanged. |
-new |
Creates a new certificate request. | Leave it unchanged for a new CSR. |
-newkey rsa:2048 |
Generates a new 2048-bit RSA private key for the request. | Use the algorithm and size accepted by your CA and application. |
-noenc |
Writes the generated private key without an encryption passphrase prompt. | Use only when your service’s key-handling policy permits an unencrypted key file; protect the file with filesystem permissions and other controls. |
-keyout server.key |
Sets the private-key output path. | Choose the protected path used by your service. |
-out server.csr |
Sets the CSR output path. | Choose a temporary or controlled path from which you can submit the CSR. |
-subj |
Supplies the distinguished-name fields without interactive prompts. | Replace the country, state, locality, organization, and common name values. |
-addext |
Adds a request extension, here the SAN list. | Add every DNS name that must appear in the certificate. |
Set the subject correctly
The -subj value uses slash-separated fields. In the example, C is the country, ST the state or region, L the locality, O the organization, and CN the common name. Substitute values that match your enrollment request. The common name is still useful as a descriptive subject field, but current TLS name matching depends on SAN entries, so do not rely on the common name alone.
Add multiple DNS names with SAN
Separate DNS entries with commas in the subjectAltName value:
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,DNS:api.example.com"Use the exact hostnames users will request. Do not add an internal or unrelated name simply because it is available; requesting a name that is not required or not controlled can cause validation failure and creates unnecessary certificate scope.
Use interactive prompts when appropriate
If you omit -subj, OpenSSL prompts for distinguished-name fields such as country, organization, and common name. This can be useful for a one-off request when you want to review every field as it is entered. It is less suitable for repeatable provisioning because manual entry can introduce spelling, capitalization, or hostname errors.
An interactive command still needs a SAN extension. On OpenSSL versions that support -addext, you can retain that option while allowing the subject prompts:
openssl req -new -newkey rsa:2048 -noenc
-keyout server.key -out server.csr
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"For automated server builds, use a fixed -subj string or a configuration file and review the generated CSR before submitting it.
Use a configuration file for larger SAN lists
A configuration file is easier to audit when the request has several names or when you need a structured request-extension section. The following pattern places SAN values in an alt_names section and tells the request section to include them:
[ req ]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
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.comSave the file with restrictive permissions, then reference it when generating the request:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchopenssl req -new -newkey rsa:2048 -noenc
-keyout server.key -out server.csr
-config server-san.cnfUse the section names and syntax supported by the OpenSSL installation on the server. After generation, inspect the CSR rather than assuming that a configuration file was interpreted as intended.
Verify the CSR before sending it
Never submit a request you have not inspected. Run:
openssl req -in server.csr -noout -text -verifyThe output should show a successful self-signature verification, the expected public-key algorithm, the complete subject, and the requested SAN extension. Check every hostname character by character, including punctuation and spelling. Also confirm that the organization and locality fields match the CA enrollment form when those fields matter to validation.
What to check in the CSR output
- Subject: The distinguished-name fields are the ones you intended to request.
- Public key: The algorithm and size match your operational and CA requirements.
- Requested extensions: The SAN extension contains every required DNS name and no accidental names.
- Verification result: OpenSSL verifies the CSR’s signature successfully.
- File identity: You are inspecting the CSR generated for this server, not an older file left in the directory.
Check the private key
Validate the key file independently:
openssl pkey -in server.key -check -nooutA successful check confirms that OpenSSL can read the file and that the private-key structure is internally consistent. If the command fails, stop the enrollment process, protect or remove the damaged file according to your incident policy, and generate a new key and CSR rather than submitting a request whose key cannot be used reliably.
Keep the key and CSR together until the CA issues the certificate, but do not treat them as equally sensitive. The CSR is designed to leave the server; the private key is not.
Protect the key on disk
Immediately restrict access to the private key:
chmod 600 server.keyThe command grants read and write access to the file owner and removes access for the group and other users. Store the file in the service’s protected key directory, apply the ownership required by the service, and ensure that backups and log collection do not expose it. If your organization requires encrypted private keys or a dedicated key-management system, follow that policy instead of accepting an unencrypted file merely because the command completed.
Do not paste the key into a terminal transcript, issue tracker, chat message, or diagnostic bundle. When copying files for backup or migration, use an approved encrypted channel and record where the backup is kept and how it will be destroyed.
Submit the CSR and install the response
- Confirm the server’s fully qualified domain names and the CA’s current subject and SAN policy.
- Generate
server.keyandserver.csrwith OpenSSL. - Run both verification commands and review the complete CSR text.
- Submit only
server.csrthrough the CA’s enrollment process. Never uploadserver.key. - Complete the CA’s required control or organization validation for the requested names.
- Receive the issued certificate and any required certificate chain.
- Install the certificate, chain, and private key according to the web server or application documentation.
- Reload or restart the service using its documented procedure, then test the endpoint from a client that uses the expected hostname.
The exact installation path, file names, ownership, and reload command depend on the web server or application. Keep the original key in its protected location and retain the issued certificate and chain with clear versioning so that a rollback is possible.
Recommended Free Tools
RSA and elliptic-curve choices
The command above uses RSA 2048 because it is a documented, broadly recognizable example. Elliptic-curve keys are another possible design, but there is no single algorithm choice that is correct for every CA and deployment. Evaluate the choice against the receiving CA, the TLS application, your security policy, performance requirements, and the operational tools used to renew and install certificates.
| Decision factor | RSA request | Elliptic-curve request |
|---|---|---|
| Example covered here | 2048-bit RSA with -newkey rsa:2048. |
Not specified by the supplied command. |
| CA compatibility | Confirm the CA accepts the requested RSA size and policy. | Confirm the CA and validation workflow accept the selected curve and key format. |
| Application support | Check the server and clients that will use the certificate. | Check the server, clients, libraries, and management tooling before deployment. |
| Operational impact | Fits the documented example and familiar key-management workflow. | May require additional compatibility testing and a documented curve choice. |
Choose deliberately and document the decision. Do not switch algorithms during renewal without checking compatibility and planning a controlled change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common mistakes and how to recover
The private key was sent to the CA
Stop using the exposed key. Notify the responsible security and certificate-management teams, revoke or replace any certificate associated with it as required by your policy, and generate a new key and CSR. A CA needs the CSR, not the private key.
The hostname appears only in the common name
Generate a replacement CSR with every required DNS name in subjectAltName. A common name by itself is not a reliable substitute for SAN-based hostname coverage in current TLS deployments.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →A required SAN is missing
Add the omitted name to the -addext list or configuration file, generate a new CSR, and inspect it with openssl req -in server.csr -noout -text -verify. A CA-issued certificate cannot add a name that was not requested and permitted by its policy.
The CSR contains a typo or an obsolete name
Do not submit it. Correct the subject or SAN list and create a new request. Keep the old file clearly separated or remove it according to your retention policy so that an operator cannot accidentally upload the wrong CSR.
OpenSSL prompts unexpectedly
An omitted -subj causes interactive distinguished-name prompts. For unattended provisioning, provide -subj or use a configuration file with prompt = no. Review shell quoting carefully, especially when a subject or SAN list contains punctuation.
The key check fails
Preserve the failed file for investigation only if your security policy requires it, restrict access, and generate a fresh key and CSR. Do not attempt to submit a CSR whose corresponding key cannot be read and checked.
An existing production key would be overwritten
Do not run the command in a directory containing an in-use key unless you have a documented rotation plan. Copy or version the current production files using protected storage, generate the replacement under a new name, verify it, and schedule installation with a rollback path. Overwriting the old key can leave the running service, certificate, and deployment records out of sync.
Renewal and key rotation planning
A renewal is an operational change, not just another command. Decide whether policy requires a new key, identify the service account that must read it, and record the certificate, key, SAN list, and chain as one deployment set. Generate and verify the replacement before changing the live configuration. Keep the previous working set available until the new certificate has been installed and the service has been tested.
When a server has several names, compare the new CSR’s SAN list with the names currently used by clients. Removing a legacy name may be desirable, but it should be an intentional migration rather than an accidental omission. Likewise, adding a name should be tied to a service requirement and CA validation.
Quick Recap
Practical pre-submission checklist
- OpenSSL runs on the intended Linux server.
- The working directory is protected from unrelated users.
- The CA’s current enrollment requirements are understood.
- Every required fully qualified domain name is listed.
- The subject fields are accurate.
- The SAN extension contains the complete, correct DNS list.
- The private key has restricted permissions, such as
chmod 600 server.key. openssl req -in server.csr -noout -text -verifysucceeds and shows the expected request.openssl pkey -in server.key -check -nooutsucceeds.- Only
server.csris sent to the CA. - A protected rollback copy and rotation plan exist before replacing a production key.
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.
