SSL Certificate Generator

Create self‑signed SSL/TLS certificates and Certificate Signing Requests (CSR) instantly. Now with Subject Alternative Name (SAN) to cover multiple domains/IPs. All cryptographic operations happen in your browser – your private key is never transmitted.

Certificate Subject
Subject Alternative Names (SAN)
These will be added to the subjectAltName extension. The Common Name (CN) is automatically included.
Key & Validity
If checked, a CSR will be generated alongside the private key (no self‑signed cert). SAN is included in the CSR.
? localhost (development) ? production‑style ? multi‑domain with SAN ? ECDSA P-256 ? minimal (CN only)
100% client‑side: All keys and certificates are generated locally. Your private key never leaves this page.

Understanding SSL/TLS Certificates and SAN

An SSL/TLS certificate enables encrypted communication between a client and a server. It contains the server's public key, identity information, and a digital signature from a trusted authority (or itself, in case of self‑signed certificates). Our generator creates X.509 certificates compliant with RFC 5280, usable with Apache, Nginx, IIS, Node.js, and many other platforms.

“Self‑signed certificates are perfect for development and internal networks, but for public sites you need a CA‑signed certificate to avoid security warnings.” – Mozilla SSL Configuration Generator

Subject Alternative Name (SAN) Extension

Modern browsers and clients require that certificates list all domain names and IP addresses they protect in the subjectAltName extension. The Common Name (CN) field is deprecated for multi‑domain validation. Our tool automatically includes the CN as a SAN entry and lets you add additional DNS names or IP addresses. This is essential for certificates that need to secure multiple services, e.g., example.com, www.example.com, and mail.example.com.

When to Use This Generator

  • Development & Testing: Quickly create certificates for localhost, staging servers, or internal APIs.
  • Internal Networks: Secure communication within a private organization without purchasing a CA certificate.
  • IoT Devices: Generate unique device certificates for mutual TLS authentication.
  • Learning & Education: Understand X.509 structure, key generation, and certificate chains.

How It Works (Behind the Scenes)

We use the jsrsasign library, a pure JavaScript implementation of RSA, ECDSA, and X.509. When you click "Generate":

  1. A new private key is generated according to your selected key type (RSA 2048/4096 or ECDSA P-256/P-384).
  2. The subject DN is built from the provided fields (CN, O, OU, L, ST, C, E).
  3. If SAN entries are provided, a subjectAltName extension is constructed and added to the certificate/CSR.
  4. If "Generate CSR" is checked, a PKCS#10 CSR is created and displayed.
  5. Otherwise, a self‑signed X.509 certificate is built using the subject, validity, signature algorithm, and signed with the private key.

All operations are asynchronous but fast. The private key is displayed in PEM format and can be downloaded as .key file; the certificate as .crt or .pem.

Self‑signed vs CA‑signed Certificates

Type Trust Use Case Browser Warning
Self‑signed Not automatically trusted Dev, testing, internal Yes (unless manually added to trust store)
CA‑signed (e.g., Let's Encrypt) Trusted by default Public websites No
Private CA Trusted within organization Enterprise internal apps No after CA certificate installed

Case Study: Securing a Multi‑Domain Development Environment

A developer working on a microservices architecture needed to test HTTPS across multiple services: api.dev.local, auth.dev.local, and app.dev.local. Using this generator with SAN, they created a single certificate covering all three domains, installed it on their development machine's trust store, and eliminated browser warnings while testing OAuth and secure cookies.

Common Pitfalls & Best Practices

  • SAN is mandatory for modern browsers: Chrome and Firefox require that the domain name be present in the SAN extension; CN is no longer checked. Our tool includes CN automatically as a SAN entry, so you're covered.
  • Private Key Protection: Never share your private key. Store it securely and set file permissions to 600.
  • Key Strength: RSA 2048 is currently considered secure; 4096 offers extra margin but slightly slower. ECDSA P-256 is fast and secure.
  • Expiration: Self‑signed certificates are often created with long validity (e.g., 1 year). For production, Let's Encrypt certificates expire after 90 days – this improves security.

Built by security engineers & crypto enthusiasts – The tool leverages the widely audited jsrsasign library and follows IETF standards. We've consulted NIST SP 800‑57 for key length recommendations. SAN implementation adheres to RFC 5280. Reviewed by the GetZenQuery Tech team, March 2026.

Frequently Asked Questions

Technically yes, but visitors will see a security warning because the certificate isn't issued by a trusted CA. For public sites, use Let's Encrypt or a commercial CA.

Enter each DNS name or IP address on a separate line in the SAN textarea. The Common Name (CN) is automatically included, so you don't need to repeat it.

Yes, when you generate a CSR, the subjectAltName extension is included in the CSR request. A CA that receives this CSR will see the SANs and can issue a certificate accordingly.

Yes. All computations happen in your browser's JavaScript engine. The key is never sent to any server. You can verify by disconnecting your network after the page loads.

Use OpenSSL: openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.crt for PKCS#12. For DER, use openssl x509 -outform der -in certificate.crt -out certificate.der.
References: RFC 5280 (X.509) · NIST SP 800-57 · Let's Encrypt.