Self-Signed Certificate Generator

Mints a complete X.509 certificate and its private key on your device: subject fields you choose, a subject alternative name list that handles hostnames, wildcards, and IP addresses, a validity window in days, and a key usage profile for a TLS server, a TLS client, or a small certificate authority. It returns the certificate and the PKCS#8 private key as PEM blocks, plus the SHA-256 and SHA-1 fingerprints and a plain summary of everything that went into the certificate.

Set the common name to the hostname you will actually connect to, then list every name and IP that should work in the subject alternative names field, since modern clients ignore the common name and check only the SAN list. Pick a key algorithm and a usage preset, set how long it should last, and generate. Save the two PEM blocks as cert.pem and key.pem, point your server at them, and add cert.pem to the trust store you are testing with, because nothing else vouches for it.

The alternative is a five flag openssl req incantation that nobody remembers, or a website that generates the key on its server and emails it to you. This one builds the certificate with a real X.509 library running in the tab, so your files and inputs never leave your device, and it shows the extensions it wrote instead of hiding them. It also defaults the SAN list to the common name, which is the single most common reason a hand-rolled openssl certificate is rejected.

Why does my browser still say the connection is not private?

Because the certificate signed itself, and no browser trusts an issuer it has never heard of. That is not a fault in the certificate, it is the entire meaning of self-signed. Either add the certificate to your operating system or browser trust store for development, or generate one with the certificate authority preset, trust that, and use it to sign the certificates your services actually present.

Why does it insist on subject alternative names?

Chrome dropped common name matching in 2017 and every other current client followed, so a certificate whose hostname appears only in CN is rejected outright. The SAN list is what gets checked. It also has to include IP addresses separately from hostnames, which is why 127.0.0.1 goes in the list rather than being covered by localhost.

What lifetime should I choose?

For anything a browser will check, keep it at or under 398 days, since that is the maximum lifetime public clients accept and some of them apply it to private certificates too. For a certificate that only your own tooling checks, the default of 825 days is convenient. For a development certificate authority, a longer life is normal, because reissuing the root means re-trusting it everywhere.

ECDSA or RSA?

ECDSA on P-256 for anything current: the keys and handshakes are smaller and every modern client supports it. Choose RSA 2048 when something old is in the path, such as an embedded device, a legacy Java stack, or a load balancer that predates elliptic curve support. RSA key generation also takes noticeably longer in a browser tab, which you will see when you press generate.