Certificate Signing Request Generator

A Certificate Signing Request is what you hand to a Certificate Authority instead of your private key. The CA reads the subject fields, confirms you control the domain, and issues a signed certificate using the public key embedded in the request. CSR Generator builds one in your browser tab using the WebCrypto API: no upload, no server, no third-party library.

The private key is generated here and signed here. The CSR comes out as a PEM file starting with -----BEGIN CERTIFICATE REQUEST-----, ready to paste directly into your CA’s order form or pipe into openssl req -verify. Copy before navigating away — the key is gone when the tab closes.

Worked Example: Generating a TLS Certificate Request

Fill in Common Name as api.example.com, Organization as Example Ltd, Country as GB, leave the rest blank, pick RSA 2048 and SHA-256, and click Generate CSR. The output is a PKCS#10 DER structure wrapped in base64 and PEM armour. Take the CSR to Let’s Encrypt, DigiCert, or any other CA. They read the subject fields and issue a certificate embedding the same public key; they never see the private key that stays on this page.

Verify the result without leaving the browser: copy the CSR, open SSL Certificate Decoder (this category), and paste it in. The subject DN and public key algorithm reflect back exactly as you typed them. That round-trip confirms the DER encoding is valid before you submit it anywhere.

What Each Field Controls

• Common Name (CN) is required. For a TLS certificate this is the fully-qualified domain name: api.example.com or *.example.com for a wildcard. For a client or person certificate it is the full name.
• Organization (O) is the legal name of the company. OV and EV certificates require this to match the CA’s validated record. DV certificates ignore it entirely.
• Country (C) accepts exactly 2 letters, ISO 3166-1 alpha-2. The tool rejects anything longer and shows “Country must be exactly 2 letters.” Entering UK instead of GB is the single most common country-code mistake; some CAs reject the non-standard form.
• Key type and hash: RSA 2048 is the safe default for compatibility. RSA 4096 takes several seconds to generate in the browser and doubles TLS handshake cost for no meaningful gain over 2048. EC P-256 is faster than both and produces a shorter key; pair it with SHA-256. Use SHA-384 when pairing with P-384.

Edge Cases Worth Knowing

• Subject Alternative Names are not included. Modern browsers require SANs for TLS validation and ignore CN entirely. Most CAs let you add SANs during the order form step after you submit the CSR, so this is not a blocker for standard DV certificates.
• The private key is PKCS#8 unencrypted. Most web servers accept this directly. If your server requires a traditional PKCS#1 key (starting with -----BEGIN RSA PRIVATE KEY-----) convert with: openssl pkcs8 -nocrypt -in private.key -out rsa.key.
• RSA 4096 can take 10 seconds on a low-end device. Generation runs on the browser’s main thread. EC P-256 finishes in under 1 second on any modern device and is the better choice when speed matters.
• PrintableString vs UTF-8 is chosen automatically. The 74 characters allowed in PrintableString (letters, digits, spaces, '()+,-./:=?) encode as 0x13. Anything else — accented characters, Cyrillic, CJK — encodes as UTF-8 0x0c. Both are valid PKCS#10 and the tool picks for you.