Self-Signed Certificate Generator

What this tool does

A TLS certificate binds a public key to names such as localhost or dev.example.test. Normally a certificate authority signs it after checking that you control the names. A self-signed certificate is signed with its own key instead, so nothing vouches for it: browsers and other clients accept it only after you tell them to trust it.

That is exactly what you want for a development server, an internal test system or a test of TLS code. The tool creates a new key pair and a certificate in your browser with the Web Crypto API and gives you both as PEM text. The private key is never sent anywhere, and it is not kept after you leave the page.

Do not use a self-signed certificate for a public website. Visitors would see a warning that they cannot sensibly check, and teaching people to click through such warnings helps attackers. Public sites should use a certificate from a public certificate authority; several issue them free of charge.

How to use it

1. Enter the common name, usually the main host name, for example localhost.
2. Add more host names and IP addresses if the server is reached under several names, for example 127.0.0.1 and ::1 for local tests.
3. Choose the key type and how many days the certificate is valid.
4. Select “Generate certificate”. Creating an RSA key can take a moment.
5. Download the certificate and the private key, and configure your server with both files.
6. To avoid the browser warning on your own machine, add the certificate to the trust store of your operating system or browser. Remove it again when you no longer need it.

A minimal HTTPS server in Node.js that uses the two downloaded files:

import { readFileSync } from 'node:fs';
import { createServer } from 'node:https';

createServer(
  {
    key: readFileSync('private-key.pem'),
    cert: readFileSync('certificate.pem'),
  },
  (request, response) => response.end('hello over TLS\n'),
).listen(8443);

How the certificate is made

Your browser generates the key pair with crypto.subtle.generateKey: an ECDSA key on the curve P-256 or an RSA key with a 2048-bit modulus and the public exponent 65537. The tool then assembles an X.509 version 3 certificate in the DER encoding that RFC 5280 describes, lets Web Crypto sign it with the private key (ECDSA with SHA-256 or RSASSA-PKCS1-v1_5 with SHA-256), and writes the certificate and the PKCS #8 private key as PEM text.

Issuer and subject are the same name, CN= followed by your common name. The serial number is 16 random bytes. Validity starts one minute before you generate the certificate, so a client whose clock is slightly behind still accepts it, and lasts exactly the number of days you entered: the last second of validity is one second before that many days have passed, because RFC 5280 counts both ends.

The certificate carries the extensions that browsers and operating systems expect of a server certificate: basic constraints saying it is not a certificate authority, key usage for digital signatures (and key encipherment for RSA), extended key usage for TLS servers and clients, and the subject alternative names. Browsers read host names only from the subject alternative names, not from the common name, so a common name that is a host name or an IP address is added to that list automatically.

Worked example

Common name localhost, more names 127.0.0.1 and ::1, ECDSA P-256, 365 days. OpenSSL shows the result like this (serial number, dates and keys differ every time):

Version: 3 (0x2)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=localhost
Subject: CN=localhost
Public Key Algorithm: id-ecPublicKey
    ASN1 OID: prime256v1
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
    DNS:localhost, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1

The same certificate is accepted for https://localhost:8443, https://127.0.0.1:8443 and https://[::1]:8443 once it is trusted, and for no other name.

Reference: what goes into the certificate

Common mistakes

• Relying on the common name. Browsers ignore it for host name checks; a certificate without subject alternative names is rejected. The tool warns when the list is empty.
• Choosing a very long validity. Apple requires 825 days or fewer for every TLS server certificate issued after July 1, 2019, and in practice this includes self-signed certificates that you trust.
• Expecting a wildcard to cover the parent name. *.example.test matches api.example.test but not example.test itself and not a.b.example.test; add the parent name separately.
• Committing the private key. Keep it out of version control, or anyone with access to the repository can pose as your server.
• Leaving a test certificate trusted forever. Remove it from the trust store when the project ends.

If you often need trusted certificates on your own machines, a small local certificate authority is more convenient than trusting many self-signed certificates one by one. Tools such as mkcert install such an authority and issue certificates from it.

• mkcert on GitHub

Sources

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC 7468: Textual Encodings of PKIX Structures (PEM)
• RFC 9525: Service identity in TLS
• Apple: Requirements for trusted certificates in iOS 13 and macOS 10.15
• Web Cryptography API (W3C)