CSR Generator

A CSR (Certificate Signing Request) is a block of encoded text that contains information about your organization and domain. You submit it to a Certificate Authority (CA) to apply for an SSL/TLS certificate. The CSR includes your public key, while the corresponding private key remains on your server. The CA uses the CSR to issue a signed certificate that browsers will trust.

Yes — when using a tool like ours. All cryptographic operations (key generation, CSR signing) happen entirely inside your browser using JavaScript. Your private key never leaves your device and is never transmitted to any server. However, always ensure you are on a trusted website and download your private key immediately. We recommend using tools that run client-side only, like this one.

• 2048-bit: The industry standard. Sufficient for most use cases and recommended by NIST until 2030. Fast generation and low server overhead.
• 3072-bit: Offers higher security. Recommended if you need long-term security beyond 2030. Slightly slower.
• 4096-bit: Maximum security for RSA. Significantly slower to generate (may take 5–15 seconds in browser) and higher CPU usage on servers. Overkill for most websites.

For EC keys, P-256 offers security comparable to ~3072-bit RSA and is much faster.

SANs (Subject Alternative Names) allow a single certificate to secure multiple domain names (e.g., example.com, www.example.com, api.example.com). Modern browsers — especially Google Chrome — require SANs for SSL/TLS certificates. Without them, your certificate may be rejected. When filling out the SAN field, include all domains and subdomains you want to secure, separated by commas.

SHA-256 is the recommended choice for virtually all use cases. It is universally supported by all Certificate Authorities and browsers. SHA-384 and SHA-512 offer theoretically stronger collision resistance but provide no practical benefit for SSL/TLS certificates. Some older systems or CAs may not support SHA-512. Stick with SHA-256 unless you have a specific compliance requirement.

• RSA: The traditional standard. Widely supported by all CAs and systems. Larger key sizes (2048–4096 bits). Slower to generate and verify.
• EC (Elliptic Curve): Modern alternative. Much smaller keys with equivalent security (P-256 ≈ 3072-bit RSA). Faster generation, less CPU overhead, and better performance on mobile devices. Increasingly supported by all major CAs.

Choose EC if your CA and server support it for optimal performance. Choose RSA for maximum compatibility.

The private key is critically important and must be kept secret. After generating a CSR:

1. Download the private key immediately and store it in a secure location.
2. Install it on your web server along with the SSL certificate you receive from the CA.
3. Set restrictive file permissions (e.g., chmod 600 on Linux).
4. Never share it via email, chat, or unencrypted channels.
5. Consider storing a backup in an encrypted vault or hardware security module (HSM).

Common reasons for CSR rejection include:

• Missing SANs: Modern CAs require Subject Alternative Names. Always include at least the primary domain as a SAN.
• Invalid Common Name: The CN should be a valid FQDN (not an IP address or incomplete hostname for public certificates).
• Incorrect Country Code: Must be a valid 2-letter ISO 3166-1 alpha-2 code.
• Weak Key: Some CAs reject keys smaller than 2048 bits.
• Special Characters: Avoid emojis or non-ASCII characters in organization fields unless using proper encoding.
• Mismatched Information: The domain ownership must match the organization details you provide.