bg-tutorials

How to Generate a CSR on Debian

This guide shows you how to generate a CSR (Certificate Signing Request) on Debian using the OpenSSL command line. You run a single command over SSH that creates two files at once: a private key that stays on your server, and the CSR you submit to your Certificate Authority (CA). The steps work on Debian 13 (trixie), Debian 12 (bookworm), and earlier releases, since OpenSSL ships in the base system.

A CSR is a small text block that holds your domain details and a public key. The CA reads it, validates your request, and issues a certificate that matches the private key created alongside it. The private key never leaves your server, so keep it safe: if you lose it, the issued certificate becomes unusable and you have to start over.

Step 1: Log into your Debian server

Open a terminal and connect to the server over SSH. Replace your-user with your account name and your-server-ip with the server’s IP address or hostname:

ssh your-user@your-server-ip

OpenSSL is included in the Debian base system, so there is nothing extra to install. To confirm it is available, check the version:

openssl version

Step 2: Generate the private key and CSR

Run the command below. It creates the private key and the CSR in one step and includes the Subject Alternative Names (SANs) that modern browsers and CAs require. Run it from a directory you can write to, such as your home directory:

openssl req -new -newkey rsa:2048 -nodes \
-keyout mywebsite.key \
-out mywebsite.csr \
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mywebsite.com" \
-addext "subjectAltName=DNS:mywebsite.com,DNS:www.mywebsite.com"

Here is what each part does:

  • req -new creates a new certificate signing request.
  • -newkey rsa:2048 generates a new 2048-bit RSA private key. 2048 bits is the current minimum for public certificates; you can use rsa:4096 for a larger key.
  • -nodes leaves the private key unencrypted (no passphrase), so the web server can start without prompting for a password.
  • -keyout mywebsite.key writes the private key. Keep this file private and never send it to anyone.
  • -out mywebsite.csr writes the CSR you submit to the CA.
  • -subj fills in the subject fields inline so the command runs without interactive prompts. Set CN (Common Name) to your fully qualified domain name.
  • -addext “subjectAltName=…” adds the SAN entries. CAs issue against the SAN list, so include every hostname the certificate must cover.

Replace mywebsite.com with your real domain, and edit the -subj values to match your organization. The two-letter country code (C) must be uppercase, for example US or GB. For a domain-validated (DV) certificate, the organization fields are not verified, but the command still needs valid values.

If you prefer to fill in the fields interactively instead of with -subj, drop that line and OpenSSL will prompt you for each value:

openssl req -new -newkey rsa:2048 -nodes \
-keyout mywebsite.key \
-out mywebsite.csr \
-addext "subjectAltName=DNS:mywebsite.com,DNS:www.mywebsite.com"

When prompted, leave the challenge password and optional company name blank by pressing Enter. CAs ignore those fields, and a challenge password can cause problems later.

Adding more domains or a wildcard

Add more hostnames to the SAN list, separated by commas. For example, to include an API subdomain:

-addext "subjectAltName=DNS:mywebsite.com,DNS:www.mywebsite.com,DNS:api.mywebsite.com"

For a wildcard certificate, use *.mywebsite.com. A wildcard covers one level of subdomains but not the bare domain, so list both if you want the apex covered too:

-addext "subjectAltName=DNS:*.mywebsite.com,DNS:mywebsite.com"

Prefer an ECDSA key?

ECDSA keys are smaller and faster than RSA at the same security level and are widely supported. To generate a P-256 (prime256v1) key and CSR instead, swap the -newkey argument:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
-keyout mywebsite.key \
-out mywebsite.csr \
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mywebsite.com" \
-addext "subjectAltName=DNS:mywebsite.com,DNS:www.mywebsite.com"

Modern OpenSSL signs the CSR with SHA-256 by default, which is what CAs require. There is no need to add a separate digest flag.

Step 3: Verify the CSR

Before you submit the request, confirm it contains the right domain and SANs and that its signature is valid. This command prints the decoded contents and checks the signature locally:

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

Look for verify OK in the output, check that the Subject line shows your Common Name, and confirm the X509v3 Subject Alternative Name section lists every hostname you expect. If a SAN is missing, regenerate the CSR with the correct -addext value. You can also paste the CSR into our online CSR decoder to check these fields in a browser.

Step 4: Submit the CSR

Open the CSR file and copy its entire contents, including the BEGIN and END lines:

cat mywebsite.csr

The block looks like this. Copy everything from the first line to the last, including the five hyphens on each side of the BEGIN and END markers:

-----BEGIN CERTIFICATE REQUEST-----
MIIC...base64-encoded data...AB
-----END CERTIFICATE REQUEST-----

Paste that block into your SSL order form. After the CA validates the CSR and issues the SSL certificate, follow the Debian SSL installation instructions to deploy it. Keep the mywebsite.key file on the server: you need it together with the issued certificate to enable HTTPS, and you must never send it to the CA or anyone else.

If you would rather not use the command line, you can build the request with our CSR Generator and paste the result into your order.

Generate a CSR on other platforms

Using a different Linux distribution or server? See our other CSR guides:

Save 10% on SSL Certificates when ordering from SSL Dragon today!

Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10

A detailed image of a dragon in flight
Written by

I've been writing for SSL Dragon for over 10 years, focusing entirely on SSL certificates and digital security. My job is to take complex cybersecurity topics and strip away the jargon, making sure you get the clear, practical information you need to keep your website safe.