Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Free tools / Self Signed Certificate Generator: Certificate and Key in Your Browser

Free tool

Self Signed Certificate Generator: Certificate and Key in Your Browser

A self signed certificate generator creates a certificate that signs itself, for testing, internal services and token signing. This one builds the certificate and key in your browser, checks its own signature and uploads nothing.

Request a trial

Generate the certificate here

Enter a name, add at least one subject alternative name, choose the key and its use, and select Generate certificate and key. To see a complete set of values first, select Fill in an Acme example.

A label for people. Browsers match the names below, not this one.

The type is detected: a host name or wildcard is DNS, a number list is an IP address, a name with @ is an email address and a name with a scheme such as https:// is a URI.

Leave this off for a normal server, client or signing certificate.

Private by design. The key pair is made in this page with your browser's Web Crypto API and is never sent anywhere. Use the result for testing and internal systems, keep the private key off email and chat, and clear this page when you are done.

Free, in your browser. The Web Crypto API makes the key pair, and the page builds and signs the certificate. Nothing is sent anywhere, which you can confirm in the Network tab.

What a self-signed certificate is

A self-signed certificate is an X.509 certificate signed with its own private key. Its issuer and subject are the same, so no certificate authority (CA) vouches for it.

RFC 5280 section 4.1 defines the structure: the signed part holds the serial number, issuer, validity, subject, public key and extensions.

Use one where you control both ends:

  • Testing. A test server.
  • Internal use. An internal service.
  • Lab. A client certificate in a lab.
  • Token signing. A signing certificate for SAML or JWT.

Do not use one for a public website, where visitors have no reason to trust it.

What the generator puts in the certificate

Field Value set by this tool Why
Version 3 Extensions require version 3
Serial number 128 random bits, positive RFC 5280 section 4.1.2.2 requires a positive integer of at most 20 octets
Subject and issuer C, O, OU and CN you enter, identical in both The certificate is its own issuer
Subject alternative name Every entry you add: DNS, IP, email or URI Clients match these names (section 4.2.1.6)
Basic constraints Critical; CA:FALSE unless you tick the CA box Section 4.2.1.9 says whether the subject is a CA
Key usage Critical; set by the use you choose Section 4.2.1.3 limits what the key may do
Subject and authority key identifier The same SHA-1 hash of the public key Section 4.2.1.2 and 4.2.1.1; equal for a self-signed certificate

The tool detects the type of each name:

  • DNS. A host name or wildcard.
  • IP address. A numeric address.
  • Email. A name with @.
  • URI. A name with a scheme such as https://.

Choose the use, key and hash

Use Key usage Extended key usage
TLS server digitalSignature, plus keyEncipherment for RSA serverAuth
TLS client digitalSignature clientAuth
SAML or JWT signing digitalSignature none
Code signing digitalSignature codeSigning

Ticking the CA box adds keyCertSign and cRLSign. Key usage follows section 4.2.1.3: the digitalSignature bit applies when the key verifies digital signatures.

  • RSA 2048 is the widest compatible choice. RSA 3072 adds margin and is slower to generate.
  • ECDSA P-256 and P-384 give small certificates and fast handshakes. Very old clients may not support them.
  • SHA-256 suits most uses. SHA-384 pairs with P-384.

Validity: public CA limits do not apply

Public CAs may issue a TLS certificate for at most 200 days since 2026-03-15, and the Baseline Requirements (Relevant Dates table, section 1.2.2) set 100 days from 2027-03-15 and 47 days from 2029-03-15.

A self-signed certificate is not under these caps.

  • SAML and JWT signing. Often valid for several years, so partners do not need to update metadata often.
  • TLS. A short life limits the damage of a leaked key, and the tool warns above 200 days.
  • Default. 365 days.

Trust the certificate for local development

A browser or library trusts a self-signed certificate only when you add it as a trusted certificate on that machine.

  1. Generate the certificate with a SAN for the exact host name or IP address you open, for example gateway.acme.example.
  2. Save the PEM as certificate.pem and the key as private-key.pem, and configure your server to use both.
  3. Import certificate.pem into the trust store of the operating system or browser you test with, or point the client at it. For example: curl --cacert certificate.pem https://gateway.acme.example/.
  4. Remove the certificate from the trust store when the test ends.

Trust one certificate per purpose. A CA-marked certificate that you trust lets its holder issue valid certificates for any name.

Why browsers warn about self-signed certificates

A browser builds a chain from the server certificate to a root it already trusts. A self-signed certificate is its own end of the chain, and its root is not in the trust list, so the browser shows a warning.

A second cause is a missing SAN. Browsers match the host name against the SAN and ignore the common name, so a certificate with only a CN fails even after you trust it.

This is why the tool requires at least one name.

Common mistakes

  • Common name only. Add the same name to the SAN list.
  • Name mismatch. The SAN must match what the client types, including an IP address if you connect by IP.
  • Shared private key. Anyone with the key can impersonate the certificate. Generate a new pair for each system.
  • Reused serial or key. Generate a fresh certificate; each one gets a new random serial.
  • Production TLS. Use a CA-issued certificate for anything public.

Questions people ask

How do I generate a self-signed certificate online?
Enter a common name and at least one subject alternative name, choose the key type and use, and select Generate. The browser makes the key pair and the certificate, then shows the PEM files and an OpenSSL command. Copy or download both, and keep the private key secret.
Is it safe to generate a self-signed certificate in a browser?
The key is created with the Web Crypto API on your device and is never sent anywhere. That is suitable for tests and internal systems. Treat the private key as a secret, avoid email and chat, and generate production keys on the server or in a hardware module.
How long should a self-signed certificate be valid?
There is no external cap. Public CAs may issue TLS certificates for at most 200 days since 2026-03-15, and a self-signed certificate is not under that rule. TLS test certificates are usually valid for months; SAML and JWT signing certificates are often valid for years.
Why does my browser still reject a self-signed certificate?
The usual causes are a missing subject alternative name, a name that does not match the address you opened, an expired certificate, or a certificate that is not in the trust store. Check the SAN list first, then import the certificate as trusted.
What is the difference between a self-signed certificate and a CSR?
A self-signed certificate is finished: it signs itself. A certificate signing request asks a CA to issue a certificate, and the CA signs it. Generate a request with the CSR generator when a CA must vouch for the name.

Where to go next

Sources, all read 2026-10-27: RFC 5280 (sections 4.1, 4.2.1.1, 4.2.1.2, 4.2.1.3, 4.2.1.6 and 4.2.1.9); CA/Browser Forum Baseline Requirements (version 2.3.1, Relevant Dates table in section 1.2.2).