Generate SSL/TLS certificates for local development, with hostnames placed in the Subject Alternative Name where browsers look. Exports PKCS#8, PKCS#1 and PKCS#12, with fingerprints and install config.
Initializing in your browser…
Build a PKCS#10 certificate signing request with subject alternative names, RSA, ECDSA or Ed25519. Signed and verified in the page before you send it to a CA.
Decode an X.509 certificate field by field, check which host names it covers, and verify that each certificate in a chain was signed by the one above it
Read the certificate chain a server sends and say whether it is complete, in order and in date, and build the OpenSSL commands that fetch it.
You need HTTPS on a local dev server at app.example.test, including its subdomains.
Input
CN app.example.test · SAN *.app.example.test, localhost, 127.0.0.1 · RSA 2048 · 365 days
Output
app.example.test.crt + .key (PKCS#8), covering 4 names, SHA-256 signed
The common name is folded into the Subject Alternative Name automatically, which is the part that decides whether the certificate works: browsers stopped matching hostnames against the Common Name years ago. The chips under the names field show the exact list before you generate, so you can see api.app.example.test is covered by the wildcard rather than finding out from an error page.
Generate SSL/TLS certificates for local development, with the hostnames placed in the Subject Alternative Name extension where browsers actually look. See exactly which names will be covered before you generate, then get the certificate, the key in both PKCS#8 and PKCS#1, a PKCS#12 bundle and the config to install it. Everything runs in your browser.
The single thing that makes a development certificate work or not work is the Subject Alternative Name extension. Browsers stopped using the Common Name for hostname matching years ago (Chrome since version 58, and RFC 2818 deprecated the practice), so a certificate whose hostname appears only in the CN is rejected outright with ERR_CERT_COMMON_NAME_INVALID. The previous version of this tool left SAN as a free text field pre-filled with "localhost,127.0.0.1", which meant anyone who typed their own domain into Common Name and pressed generate received a certificate that did not cover it. Here the common name is folded into the SAN list automatically, the list is shown as chips before you generate so you can see exactly which names will be covered, and the first chip is labelled as coming from the common name.
The extension set has been brought in line with what RFC 5280 and real tooling expect. Basic constraints and key usage are both marked critical. A certificate authority gets CA:TRUE with a path length constraint, and both certificate signing and CRL signing in its key usage, which it needs to be usable as a root. A leaf certificate gets key encipherment and extended key usage for server and client authentication instead. Every certificate carries a Subject Key Identifier, whose absence makes several tools complain. The serial number is sixteen random bytes with the top bit cleared, an even-length positive hex string; the previous scheme produced thirteen hex characters, an odd length that the hex decoder could not read cleanly. And notBefore is backdated by an hour, so a certificate generated on a machine whose clock runs slightly ahead of the server is not immediately "not yet valid".
SAN entries are classified as you type: IPv4 and IPv6 addresses become IP entries, addresses containing an @ become email entries, anything with a scheme becomes a URI, and everything else including wildcards becomes a DNS name. Duplicates are removed case-insensitively. Keys are RSA at 2048, 3072 or 4096 bits, signed with SHA-256, SHA-384 or SHA-512, and generation runs asynchronously in slices so a 4096-bit key does not freeze the tab.
After generation the tool parses its own output and shows you what it produced: subject, issuer and whether they match, serial, signature algorithm, key size, CA flag, validity dates with days remaining, the full list of covered names, and both SHA-256 and SHA-1 fingerprints. The private key is offered in PKCS#8 ("BEGIN PRIVATE KEY", which Node, Java and Go expect) and PKCS#1 ("BEGIN RSA PRIVATE KEY", the traditional OpenSSL form nginx and Apache use); both contain the same key. There is also a PKCS#12 bundle for Windows, IIS, macOS Keychain and Java keystores, and ready-to-paste nginx, Apache and Node configuration alongside the OpenSSL commands to verify that the key really does belong to the certificate. All of it runs in your browser; no key material is ever transmitted.
Set the common name to localhost and add 127.0.0.1 and ::1 to the names field. The chips confirm DNS:localhost, IP:127.0.0.1 and IP:::1 will be covered. Download the certificate and the PKCS#8 key, point your dev server at them, and trust the certificate once to stop the warning.
Common name app.example.test, names field *.app.example.test. Both appear as chips, and the generated certificate covers the bare host and every subdomain, so api.app.example.test and web.app.example.test both work from one certificate.
Turn on Certificate authority and generate a root. The summary confirms CA:TRUE with certificate and CRL signing. Add that root to your trust store once and every certificate you sign with it is trusted, instead of trusting each one individually.
Run your dev server over HTTPS so service workers, secure cookies and other features that require it behave as they will in production.
Try out cipher suites, protocol versions and certificate handling without waiting on a real certificate authority.
Secure an internal tool on a private network where a public certificate authority cannot issue for the hostname.
Create a root you trust once, then sign as many host certificates as you like without trusting each one separately.
Almost always because the hostname is not in the Subject Alternative Name. Browsers ignore the Common Name for host matching. This tool now adds the common name to the SAN list automatically and shows you the resulting list as chips before you generate, so you can confirm the name is covered.
Only the container. PKCS#8 starts "BEGIN PRIVATE KEY" and is what Node, Java, Go and most current tooling expect. PKCS#1 starts "BEGIN RSA PRIVATE KEY" and is the traditional OpenSSL form still used by nginx and Apache configuration examples. Both files contain the same RSA key.
Add the certificate to your operating system or browser trust store. The cleaner approach is to generate a CA certificate here, trust that once, and use it to sign your server certificates, so you do not have to trust each host individually.
Run the two OpenSSL commands shown under the output: one prints the modulus hash from the certificate and the other from the key. If the hashes match, they are a pair. The tool also shows the SHA-256 fingerprint, which you can compare with openssl x509 -fingerprint -sha256.
It bundles the certificate and private key into one password-protected file, which is the format Windows, IIS, macOS Keychain and Java keystores import. Use it when a system wants a single file rather than a separate certificate and key.
A plain leaf certificate is enough for a single host you trust directly. Make a CA if you want to sign several certificates, or you would rather add one thing to your trust store than one per hostname. A CA gets CA:TRUE and certificate signing key usage; a leaf gets server and client authentication instead.
No. The key pair is generated by JavaScript in your browser and never leaves the page. Nothing is uploaded, and closing the tab discards it, so download what you need before you go.
No. Nobody else trusts a certificate you signed yourself, so visitors will see a security warning. Use a public certificate authority for anything on the internet. This is for local development, testing and internal use where you control the trust store.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.