CSR Generator

A certificate signing request, with the key pair generated in your browser and the private key never sent anywhere — which is not a feature so much as the entire point of a signing request.

Where the private key comes from matters more than anything else here A CSR proves you hold a key by being signed with it. The key itself never needs to travel, and if it does, the certificate you are about to deploy is one somebody else can impersonate. Many online CSR generators produce the key pair on their server. This one uses your browser’s own Web Crypto implementation; the key is generated on your device, used once to sign the request, and offered to you to save. Nothing is uploaded — this page makes no network requests at all while it works.

Key

Subject

Common Name is the field every tutorial puts first and the one browsers stopped reading years ago. What matters is the list below.

Subject Alternative Names

What is wrong with it

Generating an RSA key takes a moment; ECDSA is instant.

Why the Common Name no longer works

Every CSR form puts Common Name first, every tutorial fills it with a hostname, and browsers stopped looking at it years ago.

RFC 2818 deprecated Common Name for hostname matching in 1999. Chrome removed support in version 58, in 2017; the other browsers had already gone. A certificate whose only hostname is in the CN produces a name-mismatch error, and the error points at the certificate rather than at the request that caused it — which is why the mistake usually surfaces at deployment rather than at issue.

Most public CAs paper over this by copying the CN into the SAN list for you. That is a courtesy, not a guarantee, and internal CAs frequently do not. Put every hostname in the SAN list.

What a wildcard actually covers

A wildcard matches exactly one label, and never the bare domain.

*.example.com matches www.example.com and api.example.com. It does not match a.b.example.com, and it does not match example.com itself. A site served at both the apex and its subdomains needs two entries, and the missing apex is one of the commonest reasons a new wildcard certificate half-works.

Choosing an algorithm

ECDSA P-256 gives security comparable to RSA 3072 with far smaller keys and signatures, faster handshakes, and support everywhere that matters. It is the better default for anything new.

RSA 2048 remains the safe choice when something old is involved. It is universally accepted and slower in a way nobody notices.

RSA 4096 costs noticeably more per handshake for a margin ECDSA reaches more cheaply. It is not wrong, just rarely the best answer to the question being asked.

What this does not do

It builds a request; it does not issue anything. Only a certificate authority can turn a CSR into a certificate, and what it will accept — which fields, which key sizes, which validation — is the CA’s policy and not this page’s.

It does not support IPv6 addresses in the SAN list, encrypt the private key with a passphrase, or handle the many extensions a CSR can carry beyond alternative names. And it cannot promise the key is erased from memory when you close the tab: JavaScript gives no way to guarantee that, and any tool claiming otherwise is guessing.

The key pair and the request are generated by your browser’s Web Crypto implementation. Nothing on this page is uploaded, and the page makes no network requests while it works.