openssl req -x509: Self-Signed Certificates
openssl req -x509 generates a private key and a self-signed certificate together in a single call.
This is the go-to for a throwaway HTTPS cert in integration tests. One command yields a key plus a cert, no CA required.
What it does
With -x509, req signs the request with its own key instead of producing a CSR, emitting a self-signed X.509 certificate. Combined with -newkey it generates the key in the same step.
Common usage
openssl req -x509 -newkey rsa:2048 -nodes \
-keyout key.pem -out cert.pem -days 365 \
-subj "/CN=localhost" \
-addext "subjectAltName=DNS:localhost,IP:127.0.0.1"Options
| Flag | What it does |
|---|---|
| -x509 | Output a self-signed certificate instead of a CSR |
| -newkey rsa:2048 | Generate a new RSA key of the given size |
| -nodes | Leave the private key unencrypted (no passphrase) |
| -keyout <file> | Where to write the generated private key |
| -days N | Validity period of the certificate |
| -addext "subjectAltName=..." | Add a SAN so modern clients accept the cert |
In CI
Generate a self-signed cert into /tmp at the start of an integration test, point your server at it, and let the runner discard it when the job ends. Modern clients (Go, Chromium, Node) reject certs without a SAN, so always include -addext "subjectAltName=...". On OpenSSL 3.x, -nodes still works but is aliased to -noenc.
Common errors in CI
A server that loads the cert but clients reject it with "x509: certificate relies on legacy Common Name field" means you omitted the SAN; add -addext. "unable to load Private Key" after generation usually means -keyout and the later -key path disagree. RANDFILE/entropy warnings on slim images are fixed by setting HOME or RANDFILE.