CSR Generator — générateur de CSR

What a CSR is

A certificate signing request (CSR) is a small signed file in the PKCS #10 format of RFC 2986. It carries three things: the subject — the distinguished name the certificate should name — the public key, and optional attributes, of which only one matters in practice: an extensionRequest with the X.509 extensions you would like, above all the subject alternative names. The whole request is signed with the matching private key. That signature is the proof of possession: whoever sends the CSR to a certificate authority demonstrably holds the private key, without revealing it.

The CA never sees your private key and does not need it. It checks that you control the names in the request (for public CAs, through ACME challenges or other domain validation), copies the public key into a certificate and signs that certificate with its own key.

What happens in your browser

Everything this tool does runs on your device; the page makes no request with your data.

• New key. RSA keys are generated with the browser's Web Crypto API; ECDSA, Ed25519, Ed448 and ML-DSA keys with the audited @noble libraries, from the browser's cryptographic random number generator. The key is shown once, as PKCS #8 PEM (RFC 5958), for you to save. It is not stored anywhere — reload the page and it is gone.
• Existing key. Paste a PKCS #8, PKCS #1 or SEC1 private key, or open the key file. It is parsed and used to sign in the page, and it is never written into a share link: the link carries only the request fields.
• The request. The generator encodes the CSR exactly as openssl req -new does with its default string_mask = utf8only: the same string types (PrintableString for the country, UTF8String for names), the same attribute layout and the same extension order. That is why the OpenSSL command printed under the result produces the same request body, and why the example — the RSA test key testRSA2048 published in RFC 9500 — reproduces OpenSSL's output byte for byte: RSA PKCS #1 v1.5 signatures are deterministic.

Choosing a key type

ECDSA P-256 is the default here and the best choice for web servers today: small keys and signatures, fast handshakes, accepted by every browser and every public CA. P-384 and P-521 add security margin at some cost in speed. RSA is still what some older clients and appliances require; use at least 2048 bits — public CAs refuse less — and 3072 bits for keys that must stay secure past 2030. Generating a 4096-bit RSA key takes a few seconds in a browser.

Ed25519 and Ed448 (RFC 8410) are excellent algorithms, but the CA/Browser Forum Baseline Requirements allow only RSA and ECDSA keys in publicly trusted TLS certificates, so use them for private CAs, client certificates and internal services. ML-DSA, the post-quantum signature standard of FIPS 204, is encoded in certificates as RFC 9881 defines; no public CA issues ML-DSA TLS certificates yet, so these requests are for private CAs and testing (OpenSSL 3.5 and later can sign with them).

Names: the SAN list, not the common name

Browsers have ignored the common name (CN) since Chrome 58 in 2017, and since Go 1.15 Go programs refuse certificates whose only host name is in the CN — the error x509: certificate relies on legacy Common Name field. The rule of RFC 5280 and current practice is simple: every name a client connects to goes into the subject alternative names. The generator therefore adds the common name to the SAN list when it is a host name (you can switch that off), detects the type of each entry — DNS name, IP address, email address or URI — and warns about names a public CA cannot issue: internal names such as .local, private IP addresses, malformed wildcards, underscores.

What a CA actually reads

A public CA takes the public key and the names it has validated from your request, and decides everything else itself under the Baseline Requirements: key usage, extended key usage, basic constraints, validity and policies. Organization and locality fields are kept only for organization-validated certificates after the CA has checked them. The extensions section of this tool matters when your own CA signs the request — a private CA such as step-ca or Active Directory Certificate Services, or openssl x509 -req -copy_extensions copy — for client certificates, code signing or an intermediate CA certificate with CA:TRUE and a path length.

With certificate lifetimes falling towards 47 days, most public certificates are now ordered by ACME clients that create the key and the CSR automatically. A hand-made CSR still has its place: certificates ordered through a portal, appliances that cannot run ACME, private CAs, and testing.

After the CSR

When the CA returns the certificate, check that it belongs to your key with the key, certificate and CSR matcher — a certificate installed with the wrong key fails with errors such as key values mismatch. To produce CSRs in scripts and pipelines, see the recipes for OpenSSL, Node.js, Python and Go, or build any other openssl command with the OpenSSL command builder.