About CSR Generator

Generate Certificate Signing Requests (CSR) for CAs with subject information. Part of the DevTools Surf developer suite. Browse more tools in the Security / Crypto collection.

Use Cases

• Generate a CSR to submit to a CA for a commercial TLS certificate
• Create a CSR for a wildcard or multi-domain (SAN) certificate
• Produce a self-signed certificate for internal or development use
• Understand CSR structure and required fields before submitting to a CA

Tips

• Fill the Subject section accurately — Common Name (CN) must exactly match the domain you are securing; wildcard domains use *.example.com
• Generate the private key locally (or use your server's key) and never share it — the CSR contains only your public key and subject information
• Include Subject Alternative Names (SANs) for all domains and subdomains the certificate should cover — a single CN is insufficient for modern TLS requirements

Fun Facts

• A Certificate Signing Request is defined in PKCS#10 (RFC 2986), originally published in 1993. The format has barely changed in 30 years despite the complete transformation of the PKI landscape around it.
• The move from SHA-1 to SHA-256 certificate signing was triggered when Google announced in 2014 that it would stop trusting SHA-1 certificates in Chrome. This deadline forced global certificate migration at scale — over 250,000 SHA-1 certificates were replaced in 2015-2016.
• Let's Encrypt, which issues over 4 million certificates per day via the ACME protocol, made the CSR process largely invisible to users. ACME (RFC 8555) automates CSR generation, submission, and certificate installation — eliminating manual CSR generation for most web servers.

FAQ

What information goes into a CSR?

The CSR contains: Common Name (domain), Organization, Organizational Unit, City, State, Country, email, and Subject Alternative Names. It also includes the public key from your key pair. The CA uses this to issue the signed certificate.

Do I need to generate a new CSR for each certificate renewal?

Best practice is yes — generate a new private key and CSR for each renewal. This limits the exposure window if your old private key was ever compromised. Some CAs allow renewal without a new CSR, which is convenient but less secure.

What key size should I use for a TLS CSR?

RSA 2048-bit is the minimum current standard. RSA 4096-bit offers more security but slightly slower handshakes. ECDSA P-256 is equivalent to RSA 3072 in security with significantly smaller keys and faster operations — preferred for new certificates.