Self-Signed Certificate Generator

Generate X.509 certificates with SAN support for development and testing

By Anish Nath
Client-Side Processing X.509 v2/v3 Support SAN Support Custom Expiry
Certificate Details
Private Key Option
Subject Information
Common Name - usually your domain name
Certificate Options
Comma-separated list of additional domain names or IPs
Generated Certificate

Your certificate will appear here

Fill in the form and click Generate
OpenSSL Command Reference
Generate Self-Signed Certificate
# Generate a new private key and self-signed certificate
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privatekey.key -out certificate.crt
Generate with Existing Key
# Generate certificate using existing private key
$ openssl req -x509 -sha256 -days 365 -key privatekey.key -out certificate.crt
Generate with SAN Extension
# Generate certificate with Subject Alternative Names
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
-keyout key.pem -out cert.pem \
-subj '/CN=example.com' \
-addext 'subjectAltName=DNS:example.com,DNS:*.example.com'
Verify Certificate
# View certificate details
$ openssl x509 -in certificate.crt -text -noout
Related Certificate Tools
Certificate Parser

Decode and analyze X.509 certificates
CA Chain Generator

Create Root CA, Intermediate, and Server certificates
CSR Generator

Generate Certificate Signing Requests
Extract Public Key

Extract public key from certificates

Support This Free Tool

Every coffee helps keep the servers running. Every book sale funds the next tool I'm dreaming up. You're not just supporting a site — you're helping me build what developers actually need.

500K+ users
200+ tools
100% private
☕ One-time support Buy me a coffee 📚 Learn & support 9-Book Bundle - $9 Stay updated Follow @anish2good
Privacy Guarantee: Private keys you enter or generate are never stored on our servers. All tools are served over HTTPS.
Understanding Self-Signed Certificates
What is a Self-Signed Certificate?

A self-signed certificate is a public-key certificate whose digital signature is verified by the public key contained within the certificate itself. Unlike CA-signed certificates, self-signed certificates are signed with their own private key rather than a trusted Certificate Authority.

In the PKI (Public Key Infrastructure) trust model, certificates are normally signed by a Certificate Authority (CA) that vouches for the identity of the certificate holder. With self-signed certificates, you are essentially saying "trust me, I am who I say I am" without third-party verification. This makes them unsuitable for public trust but perfectly valid for controlled environments.

How Certificate Trust Works
CA-Signed Certificate
Browser/Client Your Certificate Intermediate CA Root CA

The browser trusts the Root CA (pre-installed in the trust store), which trusts the Intermediate CA, which signed your certificate. This creates a verifiable chain of trust.

Self-Signed Certificate
Browser/Client Your Certificate (self-signed)

No chain of trust exists. The certificate signed itself. Browsers show warnings because they cannot verify identity through a trusted third party.

Anatomy of an X.509 Certificate

Every X.509 certificate contains these essential fields:

Field Description Example
Subject (DN) Distinguished Name identifying the certificate owner CN=example.com, O=My Corp, C=US
Issuer (DN) Who signed the certificate (same as Subject for self-signed) CN=example.com, O=My Corp, C=US
Serial Number Unique identifier assigned by the issuer 0x7A3B2C1D
Validity Period Not Before and Not After timestamps 2024-01-01 to 2025-01-01
Public Key The public key and algorithm (RSA, ECDSA, etc.) RSA 2048-bit
Signature Digital signature from the issuer SHA256withRSA
Extensions (v3) Additional attributes like SAN, Key Usage subjectAltName: DNS:*.example.com
Use Cases for Self-Signed Certificates
  • Local Development: Testing HTTPS on localhost without purchasing certificates
  • CI/CD Pipelines: Automated testing environments that need TLS
  • Internal APIs: Microservices communication within a controlled network
  • Learning & Education: Understanding PKI, TLS handshakes, and certificate structures
  • IoT & Embedded: Devices in closed networks where you control all endpoints
  • Air-Gapped Systems: Networks without internet access to reach CAs
  • Temporary Services: Short-lived services where CA overhead isn't justified
  • Root CA Creation: Your own PKI starts with a self-signed root certificate
X.509 Certificate Versions
Version 3 (Recommended)

The current standard, introduced in 1996. Required for modern TLS.

  • Subject Alternative Names (SAN): Multiple domains/IPs in one cert
  • Key Usage: digitalSignature, keyEncipherment, etc.
  • Extended Key Usage: serverAuth, clientAuth, codeSigning
  • Basic Constraints: CA:TRUE/FALSE, path length
  • CRL Distribution Points: Where to check revocation
  • Authority Info Access: OCSP responder URLs
Version 1 & 2 (Legacy)

Original versions with limited functionality.

  • Version 1 (1988): Basic fields only - subject, issuer, validity, public key
  • Version 2 (1993): Added Issuer/Subject Unique Identifiers
  • No extension support
  • Cannot specify SAN (only CN for hostname)
  • Modern browsers may reject v1/v2 certificates
  • Only use for legacy system compatibility
Subject Alternative Names (SAN) Explained

The SAN extension is critical for modern certificates. It allows a single certificate to secure multiple identities:

# Example SAN entries in a certificate
X509v3 Subject Alternative Name:
DNS:example.com
DNS:www.example.com
DNS:api.example.com
DNS:*.staging.example.com
IP Address:192.168.1.100
IP Address:10.0.0.1

Important: Since 2017, browsers like Chrome ignore the Common Name (CN) field for hostname validation and only check SANs. Always include your primary hostname in both CN and SAN for maximum compatibility.

Installing Self-Signed Certificates

To avoid browser warnings, you can add your self-signed certificate to the system trust store:

macOS
  1. Open Keychain Access
  2. Drag certificate to "System" keychain
  3. Double-click cert, expand Trust
  4. Set "Always Trust"
Windows
  1. Double-click .crt file
  2. Click "Install Certificate"
  3. Choose "Local Machine"
  4. Place in "Trusted Root CA" store
Linux (Ubuntu/Debian)
  1. sudo cp cert.crt /usr/local/share/ca-certificates/
  2. sudo update-ca-certificates
  3. Restart browser/application
Common Browser Errors
Error Cause Solution
NET::ERR_CERT_AUTHORITY_INVALID Certificate not signed by trusted CA Add to system trust store or click "Proceed anyway"
NET::ERR_CERT_COMMON_NAME_INVALID Hostname doesn't match certificate CN/SAN Regenerate with correct hostname in SAN
NET::ERR_CERT_DATE_INVALID Certificate expired or not yet valid Check system clock; regenerate if expired
SSL_ERROR_BAD_CERT_DOMAIN Firefox: domain mismatch Ensure domain is in SAN extension
Security Considerations
Important: Self-signed certificates should not be used for production public-facing websites. They will trigger browser security warnings because they're not signed by a trusted CA. For production use, obtain certificates from trusted Certificate Authorities like Let's Encrypt (free), DigiCert, or Comodo.
Pro Tip: For development, consider using mkcert - a simple tool that creates locally-trusted certificates. It automatically installs a local CA in your system trust store, making your self-signed certificates trusted without manual steps.
Quick Access