Create a Self-Signed Localhost Certificate for an Isolated Lab

A self-signed certificate can be useful in an isolated development lab when its trust is established explicitly. It is not a public-trust replacement, and visitors should not be instructed to bypass certificate warnings.

Create disposable localhost material

The following Bash example uses OpenSSL 3.x and a new private temporary directory. It creates a seven-day localhost certificate with subject alternative names, not a production certificate for your public domain. It does not modify Apache, Nginx, a browser trust store or system certificates.

umask 077
workdir="$(mktemp -d "${TMPDIR:-/tmp}/tls-localhost.XXXXXX")" || exit 1
cd "$workdir" || exit 1
openssl req -x509 -newkey rsa:2048 -noenc -sha256 -days 7 \
  -keyout localhost.key -out localhost.crt -subj '/CN=localhost' \
  -addext 'subjectAltName=DNS:localhost,IP:127.0.0.1' \
  -addext 'basicConstraints=critical,CA:FALSE' \
  -addext 'extendedKeyUsage=serverAuth'

The unencrypted private key is protected by the private directory and file permissions, not a passphrase. Keep it private. Do not reuse this example key for production or place it in a web-accessible directory.

Inspect and verify explicitly

openssl x509 -in localhost.crt -noout -subject -issuer -dates -ext subjectAltName
openssl verify -CAfile localhost.crt -verify_hostname localhost localhost.crt

The second command trusts this particular lab certificate for this check. It does not make other clients trust it or establish a public CA chain. Verification without that explicit trust should fail, and verification for a different hostname should fail even when this certificate is trusted.

Using it in a lab server

Configure only the intended loopback development server using its current TLS documentation, then give the test client a narrowly scoped trust configuration. Do not disable verification. Keep the server’s configuration recoverable and validate it before a reload. The old CentOS/Ubuntu universal paths, malformed commands and obsolete Nginx ssl on recipe have been removed because layouts and supported directives differ.

Public sites should use an appropriately trusted certificate and a monitored renewal process. An internal production PKI needs its own managed identity/trust policy rather than ad hoc warning bypasses.

References: OpenSSL request/certificate generation; explicit trust and hostname verification.

Reviewed October 15, 2026. Generation, names and trust-failure cases tested with synthetic local files; no live web-server installation or browser trust change was tested.