Generate a certificate signing request and private key.
Runs against a live TLS connection or the certificate you paste in — nothing here is stored or sent anywhere else.
Two PEM blocks. The first is the certificate signing request, which you paste into your certificate authority's ordering form. The second is the private key that goes with it, which you keep.
Requests are signed with SHA-256. You can choose an RSA 2048, RSA 4096, or ECDSA P-256 key, and set the common name plus an optional organization and two-letter country code.
The fully qualified hostname the certificate will protect — example.com or api.example.com. Use the exact name clients will connect to. Do not include a scheme, a port, or a path.
If you need both the apex and the www subdomain, or a wildcard, that is normally handled in your CA's ordering interface rather than in the CSR.
Both are optional here, and for domain-validated certificates — which is what Let's Encrypt and most low-cost commercial certificates are — the CA discards them anyway. They matter for organization-validated and extended-validation certificates, where the CA verifies them against company records. Leave them blank if you are unsure.
If you would rather the key never left the machine that will use it, this produces the same result locally:
openssl req -new -newkey rsa:2048 -nodes \
-keyout example.com.key \
-out example.com.csr \
-subj "/CN=example.com"For an ECDSA P-256 key instead:
openssl req -new -nodes \
-newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
-keyout example.com.key \
-out example.com.csr \
-subj "/CN=example.com"Once the certificate comes back, the Cert Decoder will confirm you were issued what you asked for, and the Cert Converter will bundle the certificate and key into a PKCS#12 file if your server wants one.
A new certificate starts a clock. Whatever lifetime your CA issued — 90 days, a year — you now have a date to remember, on top of every other certificate you already own.
Renew Radar keeps that list for you and warns you well before anything expires, so the renewal happens on a Tuesday afternoon rather than during an outage. Free while in beta for up to 20 certificates.
A certificate signing request is a small signed document that bundles your public key with the identity details you want certified — the common name, and optionally an organization and country. You send it to a certificate authority; the CA validates the identity and returns a signed certificate. The CSR itself is not secret.
RSA 2048 is the safe default and is accepted everywhere. ECDSA P-256 gives equivalent security with a much smaller key and faster handshakes, and is supported by every current browser and TLS library, but some older appliances still reject it. RSA 4096 is slower with no meaningful security gain over 2048 for a certificate that lives a year or less.
On the server handling your request, using OpenSSL, and it is returned to your browser over TLS. It is not written to disk, logged, or stored. Even so, a key that has crossed a network is not the same as a key that has never left the machine it will be used on.
For internal services, staging, and lab work, this is a reasonable shortcut. For a production certificate protecting real user traffic, generate the key on the server that will use it: openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr. That way the private key never crosses a network at all.
Yes, and it is the one thing here you cannot regenerate. The certificate your CA issues is mathematically bound to this specific key. Lose the key and the certificate is useless — you have to start over with a new CSR.
This generator produces a single-name CSR. Most certificate authorities now let you specify additional names in their ordering interface and ignore the SANs in the CSR entirely. If your CA requires them in the request, generate the CSR locally with an OpenSSL config that includes a subjectAltName section.