Self-Signed SSL Certificate Generator — Free OpenSSL Command Builder

Visual builder for the openssl req -x509 command. Configure subject, SANs, validity, and key type — copy the command and run it on your machine. The private key never leaves your server.

lockLive OpenSSL command builder

Certificate Subject & Key

Common Name (CN)

Country (C)

State / Province (ST)

Locality (L)

Organization (O)

Organizational Unit (OU)

Subject Alternative Names (comma-separated)

Validity (days)

Key Type

Key File

Certificate File

Generated Commands

Simple variant (CN-only)

openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout server.key \
  -out server.crt \
  -subj "/C=US/ST=California/L=San Francisco/O=Dev/OU=Engineering/CN=localhost"

Full variant (with SANs & extensions)

openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout server.key \
  -out server.crt \
  -subj "/C=US/ST=California/L=San Francisco/O=Dev/OU=Engineering/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:*.localhost,IP:127.0.0.1,IP:::1" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth"

macOS trust (system keychain)

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain server.crt

Chrome (Linux): sudo cp server.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates

Firefox: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import.

Windows: certutil -addstore -f "ROOT" server.crt

What is a Self-Signed Certificate?

A self-signed certificate is an X.509 certificate that is signed by the same private key it certifies — there is no Certificate Authority in the chain. It still terminates TLS the same way a Let's Encrypt cert does, but a browser cannot verify identity without manual trust. Self-signed certs are perfect for https://localhost, internal staging, mTLS between owned services, and any situation where you control the trust store on every client.

This generator builds the exact openssl req -x509 -nodes command for the parameters you choose. Nothing is generated server-side; the actual key material is created when you run the command on your machine, so the private key never traverses a network.

How to generate a self-signed certificate — 4 steps

Fill in the subject. Common Name (typically localhost or your internal hostname) and ISO 3166 Country code are the two fields that matter. Organization and OU are cosmetic but useful when you have many internal certs.
Add SANs and pick a key. Modern browsers ignore CN and only look at SAN, so always include DNS:localhost,IP:127.0.0.1,IP:::1 for local dev. Pick RSA 2048 for compatibility, ECDSA P-256 for performance, Ed25519 for newest setups.
Copy the full command. Run it in your project directory. OpenSSL writes server.key (private key, no passphrase thanks to -nodes) and server.crt (PEM certificate).
Trust the cert. Add it to your OS keychain (snippets above). Chrome and Safari read the system store; Firefox uses its own. Restart the browser after import.

Sample output

# Run this in your project directory
openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout server.key \
  -out server.crt \
  -subj "/C=US/ST=California/L=San Francisco/O=Dev/OU=Engineering/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:*.localhost,IP:127.0.0.1,IP:::1" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth"

# Result:
# server.key  (PEM, RSA 2048, no passphrase)
# server.crt  (PEM, X.509 v3, valid 365 days, self-signed)

Private Key Stays Local

We only build the command text — the key is generated by OpenSSL on your machine and never touches our servers.

Modern Algorithms

RSA 2048/4096, ECDSA P-256/P-384, and Ed25519 are all one click away. Browsers, curl, and Node TLS all support these out of the box.

Cross-Platform Trust

Includes copy-paste trust snippets for macOS Keychain, Linux ca-certificates, Windows certutil, and Firefox.

Common use cases

check_circleLocal HTTPS for Vite, Next.js, Express, FastAPI, and Rails dev servers
check_circleTesting TLS code paths, certificate pinning, and SNI routing in CI
check_circlemTLS between internal microservices in Kubernetes ClusterIP/Headless Services
check_circleFixture certificates for integration tests of HTTPS clients (axios, requests, reqwest)
check_circleInternal Grafana, Prometheus, Jenkins dashboards behind a corporate VPN
check_circleLocal Docker registry with TLS so docker pull does not require --insecure-registry
check_circlePersonal home-lab services (Pi-hole, Home Assistant, Proxmox) with HTTPS
check_circleOn-prem appliances, IoT devices, and lab equipment that ship with a self-signed cert

Self-signed vs Let's Encrypt vs internal CA

A self-signed cert is the simplest option but every client that talks to your server must trust it manually — that is fine for one laptop, painful for a fleet. Let's Encrypt is free, automated, trusted by every browser and OS, and is the right answer for any DNS-resolvable hostname (use certbot, acme.sh, or Caddy which handles it natively). For internal-only hostnames that cannot pass an HTTP-01 or DNS-01 challenge, run a small internal CA (step-ca, cfssl, or HashiCorp Vault PKI) and distribute its root cert via MDM — clients automatically trust everything that CA signs without per-cert work.

security

Your private key stays on your machine

We generate the command — you run it locally so the private key never leaves your server. OpenFormatter cannot see, store, log, or transmit the server.key file produced by the OpenSSL CLI. Verify in DevTools Network: zero requests are made when you copy the command.

Continue your TLS workflow

Decode certificates and CSRs, build OpenSSL commands, or generate hardened nginx/Apache TLS config — all browser-side.

OpenSSL Command Generator SSL Config Generator CSR Decoder

Frequently Asked Questions

When should I use a self-signed certificate?

Self-signed certificates are appropriate for local development (https://localhost), internal staging behind a corporate VPN, automated testing of TLS code paths, mTLS between trusted internal services where you control both endpoints, and any environment where you can pre-install the cert into the trust store of every client. Anything public-facing must use a CA-issued certificate (Let’s Encrypt is free) so browsers do not warn visitors.

Why does my browser show "Not secure" for a self-signed cert?

Browsers trust certificates that chain up to a Certificate Authority listed in their root store (DigiCert, Let’s Encrypt, Sectigo, etc.). A self-signed certificate has no such chain — it signs itself — so the browser cannot verify identity and shows NET::ERR_CERT_AUTHORITY_INVALID. Either install the cert into the OS/browser trust store, or use a real CA for anything outside your machine.

How do I trust a self-signed cert in Chrome, Firefox, and macOS?

macOS / Chrome / Safari (system keychain): sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain server.crt. Linux Chrome: sudo cp server.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates. Firefox uses its own trust store — Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import. Windows: certutil -addstore -f "ROOT" server.crt.

How long should validity be for development certificates?

For local dev pick 365 days so you re-generate yearly and reset the trust store. For CI fixtures, 30–90 days is fine — they are regenerated by automation. Avoid setting the validity beyond 825 days because Apple, Chrome, and Mozilla now reject server certs with longer lifetimes even if you trust the issuer manually.

Can I use a self-signed cert in production?

No — never for a public website. Visitors will see browser warnings, search engines deprioritize the site, and any HSTS header will permanently lock users out. Use Let’s Encrypt (free, automated via certbot, acme.sh, or Caddy) or a paid CA. Self-signed is acceptable only for non-public infrastructure where you control the trust store on every client.

What are SANs (Subject Alternative Names) and why do I need them?

Modern browsers ignore the Common Name field entirely and look only at the SAN extension to validate the hostname. A certificate with CN=localhost but no SAN will fail validation in Chrome, Firefox, and Safari since 2017. Always include subjectAltName with at least DNS:localhost,IP:127.0.0.1 (and IP:::1 for IPv6 loopback) when generating a cert for local HTTPS.

How do I generate a self-signed certificate for localhost?

Use this generator with CN=localhost and SANs DNS:localhost,DNS:*.localhost,IP:127.0.0.1,IP:::1. Run the produced openssl req -x509 command in your project directory; you will get server.key (private) and server.crt (public). Point your dev server (Vite, Next.js https mode, Express https) at the two files and trust the cert in your OS keychain.

How do I include 127.0.0.1 in the certificate?

Add IP:127.0.0.1 to the SAN field — for example DNS:localhost,IP:127.0.0.1,IP:::1. Note the IP: prefix is required (DNS: is the default if you omit it). Without an IP SAN, Chrome will reject https://127.0.0.1 even if it accepts https://localhost on the same cert, because IP literals must be matched against IP-type SAN entries.