Generate Certificate Signing Requests (CSR) for SSL/TLS certificates with RSA key pairs. Submit to CAs for certificate issuance
Generate an RSA Certificate Signing Request (CSR) and matching private key directly in your browser. Fill in your Common Name and organization details, choose an RSA key size, and download the PEM files, ready to submit to any certificate authority. Generation runs locally with node-forge; the private key never leaves the page.
Initializing in your browser…
Generate self-signed SSL/TLS certificates for local development and testing. Includes Subject Alternative Names support
Generate secure SSH key pairs (Ed25519, RSA) for server authentication and Git. Creates public/private keys with fingerprints
Decode and analyze PEM-encoded X.509 SSL/TLS certificates. View subject, issuer, validity, extensions, and fingerprints
A CA needs a Certificate Signing Request for api.example.com and you want the private key generated where it never leaves your machine.
Request details
CN api.example.com · SAN api.example.com, www.example.com · Org Example Inc · Key RSA 2048
Generated artifacts
-----BEGIN CERTIFICATE REQUEST----- MIHxMIGYAgEAMDYx… (PKCS#10, send this to the CA) -----END CERTIFICATE REQUEST----- -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49… (keep this secret, never sent) -----END PRIVATE KEY-----
The keypair is generated in your browser with the forge crypto library; only the CSR, which contains the public key and your requested names, is meant to go to the CA. The private key stays on your side, which is the entire security premise of a CSR: the signer never sees the secret half.
Generate an RSA Certificate Signing Request (CSR) and matching private key directly in your browser. Fill in your Common Name and organization details, choose an RSA key size, and download the PEM files, ready to submit to any certificate authority. Generation runs locally with node-forge; the private key never leaves the page.
This tool builds a PKCS#10 Certificate Signing Request entirely in the browser using node-forge. When you click Generate, it calls forge.pki.rsa.generateKeyPair to create an RSA key pair at the size you select (2048 bits, labeled "recommended"; 3072; or 4096, labeled "strongest"), then constructs a certification request, attaches the public key, and sets the subject distinguished name from the form. The CSR is self-signed with the matching private key using SHA-256 (forge.md.sha256.create), which is what proves to the Certificate Authority that you hold the private key for the public key in the request. The CA never sees the private key, which is exactly why generation can run locally: the key pair is created in a setTimeout callback (so the UI can show a spinner) and the private key PEM stays on the page.
The subject fields map directly to standard X.500 short names: Common Name (CN) is the only required field and is meant to hold the domain or hostname (placeholder www.example.com); the rest are optional and only added to the request if filled in, namely Organization (O), Organizational Unit (OU), City/Locality (L), State/Province (ST), Country (C), and Email (E). Country is chosen from a dropdown of roughly 60 ISO 3166-1 alpha-2 codes (US, GB, DE, JP, and so on) and is validated to be exactly two characters and upper-cased before signing; submitting a non-two-character country, or leaving CN blank, produces an inline error rather than a CSR. The key type selector is fixed to RSA (the dropdown is disabled with the note "RSA is the most widely supported"); despite an ECDSA value existing in the form type, no ECDSA path is implemented, so every request is RSA.
On success the tool emits three separate PEM blocks and lets you copy or download each: the CSR itself (downloaded as <commonName>.csr), the RSA private key (<commonName>.key), and the public key (<commonName>.pub), produced via forge.pki.certificationRequestToPem, privateKeyToPem, and publicKeyToPem respectively. The private key panel is deliberately flagged in red with a "Keep Secret" badge because losing it makes any certificate the CA issues from this CSR unusable, you cannot install a cert without its matching key. One important limitation to plan around: the request carries only the subject DN; it does not add a subjectAltName (SAN) extension, so if your certificate needs to cover multiple hostnames or satisfy modern browsers that ignore CN, you will need to supply those SANs when ordering through your CA or build the CSR with OpenSSL instead.
Enter www.example.com as the Common Name, fill O/L/ST and pick US from the country dropdown, choose 2048-bit RSA, then download the .csr and .key. Submit the .csr to a CA like DigiCert or Sectigo and keep the .key to install the issued certificate.
Select 4096-bit RSA (labeled "strongest") for a key you intend to keep in service longer; generation is slower but the resulting CSR and private key are produced the same way.
Generate the CSR required by certificate authorities like DigiCert, Sectigo, or others.
Generate a fresh RSA key pair and CSR when rotating certificates on a scheduled basis.
See exactly what fields a CSR encodes and how the subject distinguished name is structured.
Yes. The key is generated locally in your browser with node-forge and is never transmitted anywhere.
RSA only, at 2048, 3072, or 4096 bits. ECDSA is not currently available in this tool; if you need an ECDSA CSR, generate it with OpenSSL.
This tool builds the subject distinguished name (CN and organization fields) but does not add SAN entries. If your certificate needs SANs, add them when ordering through your CA or generate the CSR with OpenSSL including a SAN extension.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.