Generate a self-signed X.509 certificate plus matching public and private keys in the browser with Web Crypto. The certificate is signed by its own private key rather than by a public Certificate Authority (CA), so it is ideal for local TLS, lab environments, and development—not for public trust on the open web.
How it works
You choose key size, validity in days, signature algorithm, and optional subject attributes (common name, organization, and similar Distinguished Name fields). The tool creates an asymmetric key pair, builds a certificate with those attributes and a validity window, then signs it with the private key. Output is typically PEM-encoded certificate, public key, and private key material you can install in a local server, reverse proxy, or trust store for testing.
When to use it
- HTTPS on
localhostor internal staging hosts without buying a CA certificate - Smoke-testing TLS clients, mutual TLS setups, or certificate-parsing code
- Teaching how certificates, keys, and validity periods relate without waiting for ACME issuance
Limitations
Browsers and operating systems do not trust self-signed certificates by default; users see warnings unless the cert is explicitly trusted. They do not replace Let’s Encrypt or commercial CA certificates for production public sites. Key material never leaves your browser session, but anyone with the private key can impersonate the subject—store and delete keys carefully. Algorithm and key-size choices must match what your server stack accepts.
Example
A 2048-bit RSA key valid for 365 days with common name dev.local yields a PEM certificate beginning -----BEGIN CERTIFICATE-----, a PEM private key, and a public key. Importing that private key and certificate into a local nginx or Node HTTPS server enables encrypted connections that still show an untrusted-issuer warning until the cert is added to the machine trust store.