Keys & Certificates

Key Pair Generator

Generate RSA, ECDSA, Ed25519 or X25519 key pairs as PEM and OpenSSH, optionally with a CSR or self-signed certificate. Keys are created in your browser and never transmitted.

Key pair generator options

Key type

Encrypt the private key with a passphrase

PBES2: PBKDF2-HMAC-SHA256 → AES-256-CBC with a random 16-byte salt and IV. Output is an ENCRYPTED PRIVATE KEY that openssl pkey opens with the passphrase.

Also create a CSR or self-signed certificate
Certificate

Keyboard shortcuts

Esc
Close a menu or overlay, then leave full screen
↓ on a menu
Open it; ↑ ↓ move through its items
← → in the menu bar
Move between menus

Where your data goes
Using this page API, MCP and A2A
Where it runs In your browser. Keys are generated by your browser's Web Crypto implementation (crypto.subtle.generateKey, backed by the operating system's CSPRNG) and formatted by code on this page. The private key exists only in this tab's memory until you copy or download it, and the browser's Content-Security-Policy blocks the page from sending it anywhere. Not available. This tool exists only on this page by design: the server never receives or creates secrets.
What leaves your device Nothing you enter. After the page and its scripts load, no request carries your input. The browser enforces this: the page's Content-Security-Policy sets connect-src 'none' and form-action 'none', which block fetch, XHR, WebSocket, EventSource, beacons and form posts. —
Stored Nothing leaves the page. No cookies, analytics or third-party scripts; the browser keeps only your View → Inline config choice. —
Logged Nothing (no requests are made). —
Access Open to anyone. —

Details and how to verify this yourself: Security & privacy.

User guide

The tool sits in a window that works like a desktop app: menus on the top row and the full-screen icon at its right (Esc leaves full screen). The set-up options described below are in Settings → Options…, an overlay, and the Settings menu also lists the common choices directly. To keep the options in view instead, choose View → Inline config; the page remembers that choice. Help → Keyboard shortcuts… lists the keys.

  1. Choose a key type. If you are unsure, use Ed25519. Types your browser cannot generate are crossed out.
  2. Set the options: RSA size, ECDSA curve, and an optional SSH comment such as you@laptop.
  3. Optionally encrypt the private key with a passphrase, and/or create a CSR (to send to a certificate authority) or a self-signed certificate (for testing and internal services).
  4. Click Generate key pair. Every output can be copied or downloaded as a file; downloads are built in the page and saved by your browser.
  5. Store the private key safely now. The page keeps no copy: reload or close it and the key is gone.

Which key type?

UseChoose
SSH (personal keys, deploy keys, host keys)Ed25519
TLS certificates for public websitesECDSA P-256 (widest support), or RSA 2048/3072 for very old clients
Code or document signing with older toolingRSA 3072
Key agreement (age, HPKE, WireGuard-style protocols)X25519

Using the output.

  • SSH: save the OpenSSH private key as ~/.ssh/id_ed25519 (permissions 600) and add the OpenSSH public key line to the server’s ~/.ssh/authorized_keys (or to GitHub/GitLab). Add a passphrase with ssh-keygen -p -f ~/.ssh/id_ed25519.
  • OpenSSL / TLS servers: use private.pem (PKCS#8) and public.pem. For a certificate authority, send request.csr.
  • Encrypted private key: the page outputs ENCRYPTED PRIVATE KEY. Read it with openssl pkey -in private.pem (you will be asked for the passphrase). No unencrypted OpenSSH copy is produced in this mode, because it would defeat the passphrase.

Check your work. The Equivalent commands box shows how to produce the same kind of key with OpenSSL and OpenSSH, if you prefer to generate it offline yourself.

Specification

Key generation (Web Crypto, CSPRNG-backed).

TypeParametersSecurity level
Ed25519RFC 8032 EdDSA over Curve25519~128-bit
ECDSAP-256, P-384 or P-521 (FIPS 186-5), with signature hash SHA-256, SHA-384 or SHA-512 respectively~128 / 192 / 256-bit
RSA2048, 3072 or 4096-bit modulus, public exponent 65537; signatures use RSASSA-PKCS1-v1_5 with SHA-256~112 / 128 / 152-bit
X25519RFC 7748 key agreement; cannot sign~128-bit

Output formats.

OutputFormat
Private keyPRIVATE KEY PEM: PKCS#8 / RFC 5958 OneAsymmetricKey, unencrypted
Encrypted private keyENCRYPTED PRIVATE KEY PEM: RFC 5958 EncryptedPrivateKeyInfo with PBES2 (RFC 8018). Key derivation is PBKDF2 with HMAC-SHA256, 600,000 iterations by default (configurable from 100,000 to 10,000,000), and a 16-byte random salt. Encryption is AES-256-CBC with a 16-byte random IV and PKCS#7 padding. Passphrase: minimum 8 characters, UTF-8
Public keyPUBLIC KEY PEM: X.509 SubjectPublicKeyInfo (RFC 5280)
OpenSSH public key<type> <base64> [comment] (RFC 4253 §6.6, RFC 5656, RFC 8709)
OpenSSH private keyOPENSSH PRIVATE KEY (openssh-key-v1), cipher none, random 32-bit check integers, padded to 8 bytes. Only produced without a passphrase
CSRPKCS#10 (RFC 2986), signed by the new key, carrying SANs in an extensionRequest attribute
Self-signed certificateX.509 v3, details below

Self-signed certificate contents.

  • Serial number: 128 random bits, top bit cleared so the number is positive.
  • Validity: from now, for 1 to 3650 days (365 by default).
  • Basic constraints: CA:FALSE, critical.
  • Key usage: digitalSignature, plus keyEncipherment for RSA. Critical.
  • Extended key usage: TLS server and client authentication.
  • Subject key identifier.
  • Subject alternative names: the ones you entered. If you give only a common name that looks like a domain, it is also added as a DNS SAN, because browsers ignore the CN.

Subject fields.

  • Order: C, ST, L, O, OU, CN, as openssl req -subj writes them.
  • Country: must be a two-letter ISO 3166 code.
  • SANs: each is classified automatically as an IPv4/IPv6 address, an email address (contains @) or a DNS name (LDH labels; * allowed as the left-most label).

Verified compatibility. The project’s tests produced keys with this code and checked them with OpenSSL 3 and OpenSSH:

  • openssl pkey reads every private-key format, and the public key it derives matches byte-for-byte.
  • Encrypted keys decrypt with the passphrase and are rejected with a wrong one.
  • ssh-keygen -y reads the OpenSSH private keys.
  • ssh-keygen -l fingerprints match the ones shown here.
  • openssl verify accepts the self-signed certificates.
  • openssl req -verify accepts the CSRs.

No API, by design. Key generation is not available through the API, MCP or A2A, and never will be. A key generated on a server has been seen by that server, and this service’s rule is that it never creates or receives secrets. The equivalent commands above produce the same formats offline.