About the Self-Signed Certificate Generator
A self-signed certificate is one where the subject and the issuer are the same entity, so nothing outside the certificate vouches for it. That makes it perfectly adequate for encrypting a link you control on both ends, and unsuitable for anything a stranger's browser has to trust.
Everything here is generated in your browser, and the private key never leaves the page — which is the only acceptable arrangement, since a private key that has touched someone else's server is no longer private and cannot be made so again.
The field that causes the most trouble is the Subject Alternative Name. Modern clients ignore the Common Name entirely for hostname verification and look only at the SAN extension, so a certificate with the hostname in CN and no SAN is rejected by every current browser with an error that does not mention SAN at all.
Frequently asked questions
Why does my browser still reject the certificate?
Two causes account for nearly all of it. Either the certificate has no Subject Alternative Name entry for the hostname being used — CN has been ignored for this purpose for years — or the issuer is not in the client's trust store, which is inherent to being self-signed. The second is expected; the first is a mistake.
What is the difference between self-signed and a private CA?
A self-signed certificate vouches only for itself, so every client must trust each certificate individually. A private CA is one root you distribute and trust once, after which every certificate it issues is accepted automatically. Past two or three services, the private CA is far less work and is what internal PKI actually means.
Can I use a self-signed certificate in production?
For internal service-to-service traffic where you control both ends and pin the trust, yes — that is essentially what a service mesh does. For anything a browser or third-party client reaches, no. Public certificates are free and automatable through ACME, so the only thing a self-signed certificate buys on a public endpoint is a warning users learn to click through.
How long should the validity period be?
Short, and automated. Public certificate lifetimes have been compressed repeatedly and are heading towards weeks rather than months, on the reasoning that a compromised certificate with a long life is a long-lived problem and revocation does not work reliably. For internal certificates, pick a period your renewal automation comfortably handles — a ten-year certificate is a decade-long liability with no revocation story.
RSA or ECDSA?
ECDSA with the P-256 curve for anything new. It gives security comparable to a 3072-bit RSA key with far smaller keys and signatures, which means faster handshakes and less bandwidth per connection. RSA 2048 remains the compatibility choice for genuinely old clients, and some hardware and embedded stacks still require it.