Introduction
Every TLS certificate starts with a Certificate Signing Request (CSR). Before a Certificate Authority like Let's Encrypt, DigiCert, or Sectigo issues an X.509 certificate for your domain, you generate a key pair and a PKCS#10 request that binds your public key to your organization's identity details. This csr generator online tool creates that key pair and CSR entirely in your browser using the node-forge library, so your private key never leaves your machine. You fill in the Common Name, Organization, and location fields, pick an RSA key size, and get a PEM-encoded CSR you can submit to any CA along with the matching private key. No OpenSSL command line, no server round-trip, no risk of a private key leaking through a web form.
What this tool does
- Generates an RSA key pair (2048, 3072, or 4096 bits) and a PKCS#10 CSR in PEM format, fully client-side.
- Collects standard X.509 subject fields: Common Name (CN), Organization (O), Organizational Unit (OU), Locality (L), State (ST), Country (C), and Email.
- Optionally encrypts the private key PEM with an AES-256 passphrase for safer storage.
- Outputs a PEM-encoded CSR (-----BEGIN CERTIFICATE REQUEST-----) compatible with Let's Encrypt, DigiCert, Sectigo, and Cloudflare SSL for SaaS.
- Provides copy and download buttons for both the CSR and the private key so you can submit the CSR and store the key separately.
- Verifies the CSR signature before displaying it, so you know the request is well-formed before submitting it to a CA.
How this tool works
The tool uses node-forge, a pure-JavaForge cryptographic library, to perform all key generation and CSR signing inside your browser. You enter the subject fields (Common Name is required, the rest are optional) and choose an RSA key size. When you click Generate, the library calls rsa.generateKeyPair to produce a fresh key pair, constructs a PKCS#10 certification request, assigns your subject attributes (commonName, organizationName, localityName, and so on), attaches the public key, and signs the request with the private key using SHA-256. The tool then verifies the signature and outputs two PEM blocks: the CSR you submit to a CA, and the private key you keep. If you provide a passphrase, the private key is encrypted with AES-256 before display. RSA 2048 generates in under a second; RSA 4096 can take several seconds because the browser is doing the primality tests in JavaScript. Nothing is uploaded, which is the safest way to handle a private key on a machine you control.
How CSR generation works
A CSR is a PKCS#10 structure defined in RFC 2986. It contains a subject name (the identity details like CN and O), a public key, and a signature made with the corresponding private key. The signature proves that the entity requesting the certificate actually holds the private key matching the public key in the request. When you submit the CSR to a Certificate Authority, the CA validates your identity (through domain validation, email validation, or extended validation) and then issues an X.509 certificate defined by RFC 5280. That certificate binds your public key to your identity and is signed by the CA's private key, which browsers trust because the CA's root is in their trust store. The CA/Browser Forum Baseline Requirements govern what subject fields CAs accept and how they validate them. For example, Organization Validation (OV) certificates require a verified organization name, while Domain Validation (DV) certificates only require proof of domain control and typically ignore the O and OU fields. The Common Name should be the fully qualified domain name (FQDN) you want to secure, like www.example.com, and modern certificates can also cover additional names via Subject Alternative Names (SANs), which the CA adds during issuance.
How to use this tool
- Enter the Common Name (CN) as the fully qualified domain name you want to secure, such as example.com or api.example.com.
- Fill in optional identity fields: Organization, Organizational Unit, City, State, Country (2-letter ISO code), and Email.
- Select an RSA key size. 2048 is the minimum most CAs accept; 4096 is stronger but slower during the TLS handshake.
- Optionally set a passphrase to encrypt the private key PEM with AES-256 for safer storage.
- Click Generate CSR. The tool creates the key pair, builds the PKCS#10 request, signs it, and verifies the signature.
- Download or copy the CSR and submit it to your CA. Download the private key and store it securely. Never send the private key to the CA.
Real-world examples
Requesting a Let's Encrypt certificate via manual CSR
A sysadmin wants a certificate for blog.example.com but cannot use the standard HTTP-01 challenge because the server is behind a load balancer. They generate a CSR here with CN=blog.example.com, RSA 2048, and submit the PEM to Let's Encrypt's ACME API using certbot's --csr flag. Let's Encrypt issues the certificate, and the sysadmin installs it alongside the private key they downloaded from this tool. Because the key was generated in the browser, it never passed through the ACME client's storage or a remote server.
Generating an internal CA CSR for a Kubernetes ingress
A platform engineer runs an internal PKI with step-ca or HashiCorp Vault as the CA. They need a certificate for grafana.internal.corp for a Kubernetes ingress. They generate a CSR here with CN=grafana.internal.corp, O=Platform Team, L=Berlin, C=DE, and RSA 4096. They copy the CSR and submit it to the internal CA's signing endpoint, then store the returned certificate and the downloaded private key as a Kubernetes TLS secret. The passphrase-encrypted private key adds a layer of protection if the laptop is later compromised.
Renewing an expiring certificate without downtime
A certificate for shop.example.com is expiring in 7 days. The original private key was lost, so the admin generates a new CSR here with CN=shop.example.com and RSA 2048, submits it to DigiCert for renewal, and receives the new certificate. They swap the certificate and private key on the load balancer during a maintenance window. Using this tool avoids running openssl req on a shared jump host where the private key would sit in shell history or a temp file visible to other users.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| RSA 2048 CSR (this tool) | Low | Standard web certificates accepted by all CAs and browsers |
| RSA 4096 CSR (this tool) | Low | Higher security margin, slightly slower TLS handshake |
| ECDSA P-256 CSR (OpenSSL) | Medium | Smaller keys and faster handshakes, requires EC support from the CA |
| Self-signed certificate | Low | Internal testing only, triggers browser warnings because no CA vouches for it |
Limitations or considerations
This tool generates RSA key pairs only. ECDSA keys (P-256, P-384) are not supported here because node-forge's browser-side EC generation is slower and less common in CSRs. The CSR does not include Subject Alternative Names (SANs); most modern CAs ignore the Common Name and rely on SANs instead, so you may need to specify SANs through your CA's dashboard after submitting the CSR. RSA 4096 generation can take several seconds and may appear to freeze the tab on low-powered devices. The private key is shown in the browser DOM, so avoid generating keys on a shared or monitored machine. This tool does not submit the CSR to any CA; you must do that separately.
Frequently asked questions
What is the difference between a CSR and a certificate?
A CSR is a request you generate to ask a CA for a certificate. The certificate is what the CA issues after validating your identity. The CSR contains your public key; the certificate contains your public key plus the CA's signature.
Which RSA key size should I choose?
2048 bits is the minimum most CAs and browsers accept and is fine for most websites. 3072 and 4096 offer a larger security margin but produce larger keys and slightly slower TLS handshakes. Avoid 1024, which is deprecated.
Do I send the private key to the Certificate Authority?
No. Never share the private key with the CA or anyone else. You submit only the CSR. The CA uses the public key inside the CSR to issue the certificate, which you then pair with your locally stored private key.
Why does my CA ignore the Common Name field?
Modern browsers rely on Subject Alternative Names (SANs) rather than the Common Name. Most CAs copy the CN into a SAN during issuance or let you add SANs in their dashboard. RFC 5280 defines SANs as the preferred way to list covered domains.
Can I generate an ECDSA CSR with this tool?
Not currently. This tool supports RSA 2048, 3072, and 4096. For ECDSA CSRs, use OpenSSL (openssl req -newkey ec) or a tool with native EC key generation support.
Conclusion
This csr generator online tool produces a standards-compliant PKCS#10 CSR and RSA private key without exposing your key to a server. Fill in the subject fields, pick a key size, and submit the resulting PEM to your CA of choice. Keep the private key offline and passphrase-protected, and remember that losing it means starting over. The tool follows RFC 2986 for the CSR format and produces keys compatible with the X.509 certificate framework in RFC 5280. Generate your CSR above when you are ready to request a certificate.