Self-Signed Certificate
Generate a self-signed X.509 RSA certificate (PEM) for dev / staging.
Overview
The self-signed certificate generator produces an X.509 RSA certificate plus matching private key, in PEM format, for development and staging environments. Pick a common name, optional subject alternative names, validity period, and key size; the tool returns both halves of the bundle ready to drop into a web server or load balancer.
It is built for engineers spinning up a local HTTPS dev server, integration tests that need TLS but not a real CA, and self-hosters running services on a private network. A self-signed cert generator skips the round-trip to an internal CA or mkcert install when all you need is "any cert will do" for the next 30 days.
How it works
An X.509 certificate (RFC 5280) is a signed ASN.1 structure binding a public key to a subject. For a self-signed certificate, the issuer and subject are the same, and the signature is produced with the certificate's own private key. The tool generates a fresh RSA key pair (2048, 3072, or 4096 bits), constructs a TBSCertificate with the chosen subject, validity period (notBefore set to "now", notAfter based on your choice), and a few standard extensions — BasicConstraints (CA: TRUE/FALSE), KeyUsage, ExtendedKeyUsage (serverAuth, clientAuth), and SubjectAltName for the DNS names you list. The TBSCertificate is DER-encoded, signed with SHA-256-with-RSA, and the resulting Certificate structure is PEM-wrapped.
Examples
Common Name: localhost
SANs: DNS:localhost, DNS:dev.local, IP:127.0.0.1
Validity: 365 days
Key size: 2048
Output:
-----BEGIN CERTIFICATE-----
MIID...
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIE...
-----END PRIVATE KEY-----
Common Name: *.staging.example
Validity: 30 days
Output: wildcard cert + key
Common Name: api.internal
SANs: DNS:api.internal, DNS:api
Validity: 7 days
Output: short-lived dev cert
FAQ
Will browsers trust this?
No. Self-signed certificates are not in any root store, so browsers show a warning. Bypass it on dev hosts by adding the cert to your local trust store (or using mkcert for a locally-trusted CA setup instead).
Why include SubjectAltName?
Modern browsers (Chrome since 2017) ignore the Common Name field entirely for hostname matching. Without a subjectAltName extension listing the hostname, the cert will not validate — even past the trust warning.
Is this suitable for production?
For internal services on a private network with explicit trust pinning, yes — many companies do exactly this. For the public internet, use Let's Encrypt or a real CA.
Can I generate ECDSA or Ed25519 certs?
This tool focuses on RSA self-signed certs because of broadest compatibility. For ECDSA P-256 or Ed25519, use OpenSSL or cfssl — the X.509 structure is the same, only the key algorithm changes.