Self-Signed Certificate Generator

Generate a self-signed X.509 certificate and its private key right here — ideal for localhost, internal services, test environments and development HTTPS. Enter the subject details, choose RSA or ECDSA, set a validity period, add Subject Alternative Names, and pick a server or CA profile. The tool builds a complete X.509 v3 certificate — proper basicConstraints, keyUsage, SAN and key-identifier extensions — signs it with the freshly generated key using WebCrypto, and outputs PEM. Nothing is uploaded.

How to use the Self-Signed Certificate Generator

Pick a key algorithm and a profile. Choose Server / leaf for an end-entity TLS certificate (it sets basicConstraints CA:FALSE, a digitalSignature + keyEncipherment keyUsage, and an extendedKeyUsage of serverAuth + clientAuth) or CA for a root you intend to sign other certificates with (CA:TRUE, keyCertSign + cRLSign). Set how many days the certificate should be valid, fill in the subject — Common Name at minimum — and list the hostnames and IPs it should cover in Subject Alternative Names. For a working localhost dev certificate, include both localhost and 127.0.0.1 there.

Click Generate. The tool produces a key pair, builds a full X.509 v3 TBSCertificate — version, random serial, validity window, issuer equal to subject (that is what "self-signed" means), public key, and the extensions above plus matching subject/authority key identifiers — signs it with the new private key, and outputs the certificate and private key as PEM. Copy or download both. Because no public CA signed it, browsers and clients will not trust it until you add it to a trust store; for local development you can import the certificate into your OS or browser, or run your dev server with the certificate and key directly. Inspect the result any time with openssl x509 -in certificate.crt -noout -text.

Self-signed certificates: what they are and when to use them

An X.509 certificate binds a public key to an identity, vouched for by a digital signature. In the normal case a certificate authority signs your certificate, and because clients already trust that CA, they transitively trust yours. A self-signed certificate skips the authority: the certificate's issuer and subject are the same entity, and it is signed with its own private key. Cryptographically it is a perfectly valid certificate — the TLS handshake, the encryption, the signature all work identically — but there is no external party attesting to the identity, so nothing trusts it by default. That is the entire trade-off: zero cost and instant issuance, in exchange for no automatic trust.

That makes self-signed certificates the right tool for situations where you control both ends. Local development over HTTPS is the classic case: a certificate for localhost and 127.0.0.1 lets you test secure cookies, service workers and mixed-content behaviour without a public domain. Internal services, CI runners, staging boxes, IoT devices and private APIs often use self-signed certificates (or a small self-signed CA) because the clients are configured to trust them explicitly. What they are not suitable for is a public website: visitors have no way to distinguish your self-signed certificate from an attacker's, so browsers show a prominent warning — which is correct behaviour, not a bug.

A correct certificate is more than a key and a name. This generator produces an X.509 v3 certificate with the extensions clients actually check: basicConstraints to declare whether it is a CA, keyUsage and extendedKeyUsage to constrain what the key may do, subjectAltName for the hostnames (browsers require SAN — a certificate with only a Common Name is rejected), and subject/authority key identifiers. Validity is encoded per RFC 5280 (UTCTime through 2049, GeneralizedTime beyond), the serial number is a random positive integer, and the whole TBSCertificate is signed with RSA or ECDSA using WebCrypto. Everything happens in your browser; the private key is generated locally and never transmitted, so the output is safe to use for real internal infrastructure as well as throwaway tests.

Common use cases

  • Local HTTPS for development. Generate a certificate for localhost and 127.0.0.1 so your dev server runs over TLS and secure-context features work.
  • Internal and staging services. Secure private APIs, dashboards and CI agents whose clients you control and can configure to trust the certificate.
  • A throwaway test CA. Use the CA profile to mint a root, then issue leaf certificates against it for a private environment.
  • Pinning and testing. Produce a deterministic certificate + key pair for integration tests, TLS client testing, or certificate-pinning experiments.

Frequently asked questions

Why does my browser still show a security warning?
Because no certificate authority signed it. Browsers only trust certificates that chain to a CA already in their trust store, and a self-signed certificate chains only to itself. The warning is expected. For local use you can add the certificate to your operating system or browser trust store, after which the warning disappears on that machine. Never expect public visitors to bypass the warning — for a public site, get a CA-issued certificate.

What is the difference between the server and CA profiles?
The server (leaf) profile marks the certificate as a non-CA end-entity: basicConstraints CA:FALSE, keyUsage of digitalSignature + keyEncipherment, and extendedKeyUsage serverAuth + clientAuth — what a TLS server certificate needs. The CA profile sets CA:TRUE with keyCertSign + cRLSign so the certificate can sign other certificates, which is what you want for a private root.

Do I need Subject Alternative Names?
Yes, for anything TLS. Modern browsers validate the hostname against the SAN extension and ignore the Common Name entirely, so a certificate without a matching SAN entry is rejected even if the CN looks right. List every hostname and IP the certificate must serve — for localhost development include both localhost and 127.0.0.1.

Is the private key sent anywhere?
No. The key pair is generated by your browser's WebCrypto engine and the certificate is assembled and signed locally in JavaScript; nothing is uploaded. The key cannot be recovered after you leave the page, so download or copy both the certificate and key before navigating away.

How do I confirm the certificate is valid?
Save it and run openssl x509 -in certificate.crt -noout -text to read the version, serial, validity, subject and extensions. To check the self-signature cryptographically, openssl verify -CAfile certificate.crt certificate.crt prints OK for a valid self-signed certificate — the same signature math a client performs.