CSR Generator

Because a private key that reaches someone else's server meets the industry's own definition of a compromised key — whatever that server then does with it.

The CA/Browser Forum's Baseline Requirements define it without room for argument: "A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it." No misuse is required. Arrival is enough.

That is not theoretical. In 2020 DigiCert found 337 private keys that customers had pasted in alongside their requests, revoked every certificate involved, and reported it publicly: "by sending the private key to DigiCert along with the CSR, the customer has compromised the private key", adding that "the only part of a CSR we use is the public key". A generator that makes the key on its own server and hands you a copy has, by that definition, already compromised it. This page cannot do that: crypto.subtle.generateKey runs in your browser, inside a sandboxed frame that is not allowed to connect anywhere, and the page around it only ever sees the public key.

ECDSA P-256 for anything new: it is as strong as a 3072-bit RSA key, much smaller, and allowed by the rules every public certificate authority follows. RSA 2048 when an older device has to read the key.

NIST puts P-256 and RSA-3072 at the same 128-bit security strength, and gives RSA-4096 no strength of its own at all — the next step in its table is 7680 bits. So 4096 costs every visitor extra handshake work for no documented gain. P-384 is the 192-bit step, and the Baseline Requirements allow P-521 too, but Let's Encrypt refuses P-521: a request can be perfectly legal and still fail at the CA you meant to use.

Ed25519 is offered here because it is excellent for SSH, for signing and for a private CA — but no public certificate authority will issue a TLS certificate against it. The rules list RSA and the three NIST curves and then say "no other algorithms or key sizes are permitted". The same goes for post-quantum ML-DSA: the ballot that would have allowed it in public TLS was closed unmerged in October 2026. The generator says so beside each choice rather than letting you find out from a rejection email.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr makes the key and the request in one step.

The generator writes the command for whatever you have filled in, including the alternative names and every extension, and our tests run it through OpenSSL to check it makes the same subject and extensions as the page. Add -subj "/CN=example.com" to skip the questions, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" for the names, and -utf8 so an accented name survives. -nodes leaves the key unencrypted: OpenSSL 3 prefers the newer spelling -noenc but still accepts -nodes, which is the only spelling the LibreSSL built into macOS knows. That LibreSSL cannot make an Ed25519 key at all; use OpenSSL 1.1.1 or later for one.

To check what you made: openssl req -in example.com.csr -text -verify -noout prints every field and verifies the self-signature, stopping before it prints anything if the signature fails. To confirm the key belongs to the request, compare openssl req -in example.com.csr -pubkey -noout with openssl pkey -in example.com.key -pubout. No standard assigns a CSR a file extension, so .csr, .pem, .req and .txt are all correct.