OpenSSL CSR Command Generator

Fill in your certificate details to generate ready-to-run OpenSSL commands for CSR creation, self-signed certificates, key generation, and CSR verification.

The domain name the certificate will secure (e.g. example.com or *.example.com)
2-letter ISO country code (e.g. US, GB, DE)
Add additional domains or IPs. Use "IP:1.2.3.4" for IP addresses. Wildcards like *.example.com are also valid.
Fill in the form and click Generate Commands.

How to Use the CSR Command Generator

  1. Choose key type — select RSA (default, widest compatibility) or ECDSA (smaller keys, faster TLS handshakes).
  2. Enter your Common Name (CN) — this is the primary domain name the certificate will secure. For wildcard certificates, use *.example.com. For multi-domain certs, use the primary domain here and add others as SANs.
  3. Fill in organization details — Organization (O), Country (C), State (ST), and Locality (L) are typically required by paid CAs for OV (Organization Validated) certificates. For DV (Domain Validated) certificates from Let's Encrypt, they are optional.
  4. Add Subject Alternative Names — for any certificate that needs to cover multiple domains or IPs (e.g. both example.com and www.example.com), add them as SANs. Modern browsers require the domain to be listed as a SAN.
  5. Click Generate Commands — the tool generates ready-to-run OpenSSL shell commands. Copy each command or download the full script as a .sh file.

Understanding the Generated Commands

The tool generates five types of OpenSSL commands:

  • Key generation — creates your RSA or ECDSA private key file. Keep this file secure and never share it. The private key is used to sign your CSR and later to decrypt TLS sessions.
  • CSR generation from existing key — creates a CSR from an existing private key. Use this if you already have a private key and want to renew or replace your certificate without generating a new key pair.
  • Key + CSR in one step — the most common approach for new deployments. Generates both the private key and CSR in a single command.
  • Self-signed certificate — creates a certificate signed by your own private key. Useful for development and testing. Set the validity period with the -days flag.
  • CSR verification — reads the generated CSR and displays its contents in human-readable form. Use this to verify the domain name, organization, and SANs are correct before submitting to a CA.

RSA vs. ECDSA: Which Should You Choose?

RSA 2048 is the safe default — it has been the industry standard for over a decade, is supported by every CA and TLS client, and provides adequate security. RSA 4096 offers a larger security margin but generates slightly larger key files and takes marginally longer for TLS handshakes. ECDSA (Elliptic Curve DSA) with P-256 provides equivalent security to RSA 3072 but with a 256-bit key (much smaller). ECDSA keys result in faster TLS handshakes and smaller certificate files, which is why major web platforms like Google, Cloudflare, and Facebook have migrated to ECDSA. If your CA supports ECDSA (all major ones do), P-256 is the recommended choice for new deployments in 2024 and beyond.

Subject Alternative Names (SANs) Explained

A single TLS certificate can cover multiple hostnames using the Subject Alternative Name (SAN) extension. For example, a certificate can cover example.com, www.example.com, api.example.com, and staging.example.com with a single CSR. This is more efficient than obtaining separate certificates for each subdomain. Wildcard SANs like *.example.com cover all immediate subdomains (www, api, mail) but not sub-subdomains (app.api.example.com). For IP addresses, prefix with "IP:" in the SAN field (e.g. "IP:192.168.1.100") — this is required for certificates used with direct IP access rather than domain names.

Working with Let's Encrypt

Let's Encrypt (via Certbot or ACME protocol) automates the entire CSR → certificate process. You do not need to manually generate CSRs for Let's Encrypt unless you are using a manual/DNS challenge or a custom ACME client. However, understanding CSRs is valuable for migrating certificates, working with internal CAs, generating certificates for on-premises servers not reachable by ACME, or using paid OV/EV certificates that require manual submission to a CA portal. The commands generated by this tool work with any CA that accepts PEM-format CSRs.

Security Best Practices

  • Never share your private key — the .key file must stay on your server. If it is compromised, revoke your certificate immediately and generate a new key pair.
  • Use strong key sizes — RSA 2048+ or ECDSA P-256+ for all new certificates.
  • Verify the CSR — always run the verify command before submitting to a CA to confirm the CN and SANs are correct.
  • Set appropriate certificate validity — CAs now issue certificates for a maximum of 398 days. Let's Encrypt uses 90 days. Self-signed certificates can be longer but should still be rotated regularly.
  • Store private keys with restricted permissions — on Linux, use chmod 600 private.key to restrict access to the file owner only.

Frequently Asked Questions

A Certificate Signing Request (CSR) is a block of encoded text containing your public key and identity information (domain name, organization, country, etc.). You send this to a Certificate Authority (CA) like Let's Encrypt, DigiCert, or Sectigo. The CA verifies your identity and returns a signed TLS/SSL certificate that browsers will trust. Without a CSR, you cannot obtain a CA-signed certificate for HTTPS.
RSA 2048 is the current minimum recommended key size and is universally compatible. RSA 4096 doubles the key size for extra security with minor performance cost. ECDSA with P-256 provides equivalent security to RSA 3072 with much smaller keys and faster TLS handshakes. Most modern CAs and clients support all three; ECDSA P-256 is increasingly the recommended choice for new deployments.
SANs are additional hostnames or IPs that a single certificate can cover. For example, a certificate can cover example.com and www.example.com and api.example.com with one CSR by listing them as SANs. Modern browsers require the domain to be listed as a SAN (not just the CN field). Wildcard certs (*.example.com) cover all first-level subdomains as a SAN.
Yes. This tool runs 100% in your browser and never sends any data to a server. All processing happens locally in JavaScript. The tool generates OpenSSL command strings that you run on your own machine. No private keys are generated or transmitted by this tool.
A CSR is submitted to a Certificate Authority, which returns a trusted certificate. A self-signed certificate is signed by your own private key and is not trusted by browsers (they show a security warning). Self-signed certificates are appropriate for development and internal tools. For production public websites, use a CA-signed certificate — Let's Encrypt provides free DV certificates.