How to Generate a CSR on Sentora

This guide shows you how to generate a CSR (Certificate Signing Request) on Sentora using OpenSSL. Sentora’s control panel has no built-in CSR tool, so you create the request on the server itself, which runs on Apache and Linux. A single command produces two files at once: a private key that stays on your server, and the CSR you submit to your Certificate Authority (CA).

Sentora itself is slow-moving but not abandoned; the current stable release is v2.0.2 (May 2024, on PHP 7.4), maintained by former ZPanel developers, and the OpenSSL workflow below is unaffected by the panel version.

If you already generated your CSR and received the issued certificate from your CA, skip ahead to installing your SSL certificate on Sentora. Otherwise, follow the steps below.

Step 1: Log into the server as root

Open an SSH session to the server that runs Sentora and become root. Generating a CSR does not strictly require root, but you will need it to install OpenSSL in the next step if it is missing:

sudo -i

Step 2: Confirm OpenSSL is installed

OpenSSL ships with every current Debian, Ubuntu, CentOS, AlmaLinux, and Rocky Linux release, so it is almost certainly already present. Check the version:

openssl version

If the command reports a version number, skip to Step 3. If it is not installed, add it with your distribution’s package manager.

On Debian or Ubuntu:

apt update && apt install -y openssl

On CentOS, AlmaLinux, or Rocky Linux:

dnf install -y openssl

On older systems where dnf is unavailable, yum install -y openssl works the same way.

Step 3: Generate the private key and CSR

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

openssl req -new -newkey rsa:2048 -nodes \
-keyout example.key \
-out example.csr \
-subj "/C=US/ST=New York/L=New York/O=Example LLC/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Here is what each part does:

• req -new creates a new certificate signing request.
• -newkey rsa:2048 generates a fresh 2048-bit RSA private key. 2048 bits is the current minimum for public certificates; use rsa:4096 if you want a larger key.
• -nodes leaves the private key unencrypted (no passphrase), so Apache can start without prompting for a password. This is the portable spelling and works on every OpenSSL build.
• -keyout example.key writes the private key. Keep this file private and never send it to anyone.
• -out example.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 every placeholder with your real details:

• example.com: your actual domain, in both the CN and the SAN list.
• C, ST, L, O: your two-letter country code (uppercase, for example US or GB), state or province, city, and legal organization name. For a domain-validated (DV) certificate these fields are not verified, but the command still needs valid values.
• example.key and example.csr: any filenames you like, as long as you stay consistent.

Modern OpenSSL signs the request with SHA-256 by default, which is what CAs require, so there is no separate digest flag to add.

Securing a wildcard or extra subdomains

To add more hostnames, extend the SAN list with additional DNS: entries separated by commas, for example DNS:api.example.com. For a wildcard certificate, set the CN to *.example.com and keep the apex domain in the SAN list. A wildcard covers exactly one level of subdomains (www.example.com, mail.example.com) but not the bare apex (example.com), so the apex must be listed separately to be covered:

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

Prefer an ECDSA key?

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

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes \
-keyout example.key \
-out example.csr \
-subj "/C=US/ST=New York/L=New York/O=Example LLC/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"

The ec_param_enc:named_curve option keeps the curve stored by name, which is what PKIX requires; without it some OpenSSL builds embed the full curve parameters and the CA rejects the request.

Step 4: Verify the CSR

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

openssl req -noout -text -verify -in example.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 request into our online CSR decoder to check these fields in a browser.

Step 5: Locate and submit the CSR

List the working directory to confirm both files exist:

ls -l example.key example.csr

You are on a Linux server, so open the CSR with a terminal viewer, not a Windows editor. Print it to the screen with:

cat example.csr

Copy the entire block, including the first and last lines. A CSR is delimited by CERTIFICATE REQUEST markers with five hyphens on each side, not the CERTIFICATE markers of an issued certificate:

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

Paste that block into your SSL order form. After the CA validates the request and issues your certificate, follow our guide on installing an SSL certificate on Sentora to deploy it. Keep the example.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 at all, you can build the request with our CSR Generator and paste the result into your order.