CSR Generator
Generate Certificate Signing Requests (CSRs) locally with custom parameters.
CSR Generator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The CSR Generator produces a Certificate Signing Request — the PKCS#10 structure you submit to a Certificate Authority to request a signed certificate — along with the private key it's built on. A CSR bundles the identity information you want the certificate to assert (Common Name, Organization, Country, and similar Distinguished Name fields) together with your public key, all signed with the corresponding private key as proof that you actually hold it.
- That self-signature is the mechanically important part of a CSR: it doesn't make the CSR trusted by anyone (nothing is trusted until a CA signs it), but it proves possession of the private key matching the enclosed public key, which is exactly what a CA needs to confirm before it will issue a certificate binding that key to your claimed identity.
- This tool generates both halves locally for testing and prototyping — the CSR you'd submit to a CA, and the private key that must be kept secret and used later to install the certificate the CA eventually returns.
How It Works
- You provide the Distinguished Name fields the certificate should assert — Common Name (the primary hostname or entity name), Organization, and Country are the most commonly required.
- A key pair is generated, and the Distinguished Name plus the public key are assembled into the PKCS#10 CertificationRequestInfo structure.
- That structure is signed with the corresponding private key, producing the self-signature that proves possession of the private key without any external party's involvement.
- The signed request is PEM-encoded with CERTIFICATE REQUEST headers, ready to submit to a CA, alongside the private key you'll need later to install the resulting certificate.
Usage
- Enter the Common Name (the primary hostname), Organization, and Country for the certificate you're requesting.
- Generate the CSR — this also produces the private key needed later.
- Copy the CSR block to submit to your Certificate Authority or internal PKI issuance system.
- Store the private key securely — you will need it to install and use the certificate once the CA returns it, and it should never be shared with the CA or anyone else.
Examples
- Generating a CSR for a multi-word Organization name to confirm special characters in Distinguished Name fields are escaped and submitted correctly.
- Producing a test CSR to walk through a new CA's or ACME provider's submission flow before doing it against a production domain.
- Creating a throwaway CSR and key pair to configure a local development TLS certificate without touching real production identity information.
- Using the CSR Decoder afterward to confirm the generated request actually contains the Distinguished Name fields you intended before submitting it anywhere.
Real-World Use Cases
- Generating a test CSR with specific Distinguished Name fields to verify a CA's or internal PKI's submission process before doing it against a production identity.
- Prototyping the exact subject fields a certificate request should contain before scripting automated certificate issuance in a real environment.
- Understanding what information a CSR actually contains and why it's structured the way it is, before working with a real CA's submission portal or ACME client.
- Producing a throwaway CSR and key pair for local development environments that need a self-signed or internally-issued test certificate.
Best Practices
- Treat the private key generated alongside a CSR as sensitive from the moment it's created — it's the key the eventual certificate will be bound to, and it should never be submitted to the CA or shared with anyone.
- Double-check Distinguished Name fields for typos before submitting — a CA will issue a certificate for exactly what the CSR asserts, and a misspelled Organization or Common Name means requesting a new certificate from scratch.
- Generate a fresh key pair for each new certificate request rather than reusing an old private key indefinitely — key rotation limits the impact if a private key is ever compromised.
- Use the CSR Decoder to verify a generated request before submitting it to a CA, especially for automated or scripted issuance workflows where a subtle field error could go unnoticed.
Common Mistakes
- Submitting a CSR without keeping a copy of the private key it was generated with — without that key, a returned certificate is useless, since only the matching private key can actually use it.
- Assuming the CSR itself is a trusted credential — a CSR is just a signed request; nothing about it is trusted by anyone until a CA reviews it and issues a certificate in response.
- Putting the wrong Common Name (e.g. a internal-only hostname) in a CSR meant for a publicly-trusted certificate — public CAs will reject or mis-issue certificates for names they can't validate ownership of.
- Reusing the same private key across multiple, unrelated certificate requests — this couples the security of unrelated systems to a single key's secrecy for no operational benefit.
Limitations
- This tool generates a CSR and key pair for testing and prototyping in your browser; it does not submit the request to any real Certificate Authority — that step happens outside this tool, using whatever CA or ACME provider you're working with.
- Generated keys and CSRs exist only in local browser memory during the session — reloading the page clears them, so copy both the CSR and the private key before navigating away.
- This tool does not include CSR extension requests (like a SAN list) beyond the core Distinguished Name fields — a production CSR for a multi-domain certificate typically also needs a SAN extension request, which some CAs require submitted through their own tooling.
Technical Reference Guide
- Certificate Signing Requests are defined by RFC 2986 (PKCS #10), which specifies the CertificationRequestInfo structure: the subject Distinguished Name, the public key, and optional attributes, all covered by the enclosing self-signature.
- The self-signature over a CSR proves possession of the private key corresponding to the enclosed public key — it establishes no trust on its own; trust is established only once a CA signs a certificate in response.
- Distinguished Name attribute types (Common Name, Organization, Country, and similar) used in a CSR's subject field follow the X.520 naming conventions referenced by RFC 5280.
FAQ
What's the difference between a CSR and a certificate?
A CSR is a request you generate and submit — it contains your desired identity fields and public key, self-signed to prove you hold the matching private key. A certificate is what the CA sends back: the same information, now signed by the CA, making it trusted by anyone who trusts that CA.
Do I need to keep the private key generated with a CSR?
Yes — without it, the certificate the CA eventually issues is unusable, since only the matching private key can actually use it for TLS or signing. Store it securely and never share it, including with the CA itself.
Can I generate a CSR for multiple domains?
This tool generates the core Distinguished Name fields; a multi-domain (SAN) certificate typically requires submitting a SAN extension request as well, which some CAs and ACME clients handle through their own submission process beyond the base CSR.
Is the CSR itself sensitive information?
No — a CSR contains only your public key and requested identity fields, both meant to be shared with the CA. The private key generated alongside it is what must be kept secret.
What happens if I make a typo in the Organization or Common Name field?
The CA will issue a certificate for exactly what the CSR asserts, typo included. You'd need to generate a new CSR with the corrected fields and request a new certificate.
Why does the CSR need to be signed if nothing trusts it yet?
The self-signature doesn't establish trust — it proves you actually hold the private key matching the public key you're asking the CA to certify, which is exactly what the CA needs to confirm before issuing a certificate.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools