CSR generated for {{ cn || '[no CN]' }}
Certificate Signing Requests (CSRs) are standardized files used within public-key infrastructure to prove control of a domain or identity when applying for a digital certificate. Each CSR bundles a newly generated public key with descriptive subject attributes, then cryptographically signs the package so certificate authorities can validate its integrity before issuing TLS, S/MIME, or code-signing credentials.
By combining the details you enter—common name, alternative names, organization data, and a preferred RSA key size—the generator produces a fresh key-pair in the browser, assembles a PKCS #10 request with your attributes, signs it with a SHA-256 digest, and presents both the base64-encoded CSR and the matching PEM-formatted private key for immediate download.
For example, a system administrator can create a wildcard CSR for *.example.com seconds before uploading it to a certificate authority, guaranteeing the private key never leaves their workstation or transient browser memory. Always store the generated key securely; anyone with that file can impersonate your site, server, application, or code.
RSA public-key cryptography relies on modular exponentiation: a private exponent d is chosen such that e·d ≡ 1 (mod φ(n)) where n = p·q. The algorithm’s hardness derives from the difficulty of factoring n. A CSR follows the PKCS #10 specification, embedding an ASN.1 structure that encapsulates subject attributes, the DER-encoded public key, and a SHA-256 signature so certificate authorities can verify integrity and identity before issuing a certificate.
| Key Size (bits) | Approximate Security Window |
|---|---|
| 2048 | Suitable for most public websites until 2030 |
| 3072 | Extra margin for high-value assets into mid-2030s |
| 4096 | Long-term archival or sensitive code-signing |
Example (CN = example.com, key size = 2048):
The resulting CSR hashes to SHA-256 and signs in ≈2 seconds on a modern laptop.
Concepts align with RFC 2986 (PKCS #10), RFC 5280, and NIST SP 800-57 Pt 1. Security margins draw on Lenstra & Verheul (2001) and ECRYPT-CSA (2023) key-size recommendations.
The generator processes all data locally, and no sensitive information leaves the user’s browser, satisfying GDPR principles on data minimisation.
Follow these steps to obtain a ready-to-submit CSR and its matching private key.
No. All calculations occur in your browser and disappear once the page is closed.
2048-bit suits typical websites; choose 3072 or 4096 for long-term or high-risk deployments.
Reusing private keys undermines security. Generate a fresh pair for each new certificate request.
No. Current validation accepts IPv4 or DNS names only.
If your browser blocks clipboard access, use the download buttons instead to save the files.