A complete guide to generating a PKCS#10 Certificate Signing Request, how it differs from a self-signed certificate, and why Certificate Authority verification matters.
Launch the CSR Generator →The CSR Generator creates a PKCS#10 Certificate Signing Request (CSR) and a matching private key, entirely in your browser, using the same subject fields, algorithm choices, and cryptographic libraries as the SSL Self-Signed Certificate Tool. Rather than producing a finished, usable certificate, this tool produces the specific request document you submit to a real Certificate Authority (CA) — such as a free public CA like Let's Encrypt, a commercial CA, or an internal enterprise CA — in order to receive a properly signed, trusted certificate back.
The output includes a downloadable .csr file (the request itself, in PEM format, ready to paste into whatever submission process your CA requires) and a separate .key file containing the matching private key, which must be kept secret and will later be paired with the certificate the CA eventually issues.
It's worth being precise about the distinction between this tool and the SSL Self-Signed Certificate Tool elsewhere on this site, since they share almost identical input fields and the same underlying cryptography libraries, but produce fundamentally different outputs serving different purposes.
The Self-Signed Certificate Tool produces a complete, finished X.509 certificate that is signed by its own private key and immediately usable, with the significant caveat that no browser or operating system trusts a self-signature automatically. This CSR Generator instead produces an unsigned request: a document containing your desired certificate details and your public key, cryptographically bound together and self-verified for integrity, but deliberately not yet signed by any certificate-issuing authority. The actual trusted signature only gets added later, by whichever real CA you submit the CSR to.
In short: use the Self-Signed Certificate Tool when you want a certificate you'll manually trust yourself (development, internal tools, testing). Use this CSR Generator when you want a certificate that will eventually be trusted automatically by other people's browsers, which requires getting it signed by a real, publicly or organizationally trusted CA.
A Certificate Signing Request, formally defined by the PKCS#10 standard, contains three essential pieces: the subject information you want the eventual certificate to assert (Common Name, Organization, and the other fields you fill in), your public key (generated as part of the same key pair whose private half stays on your device), and a signature over all of that information, created using your own private key, proving that whoever submitted the CSR genuinely possesses the matching private key.
That self-signature inside the CSR is not the same thing as a self-signed certificate's signature. It doesn't make the eventual certificate trusted; it simply lets the receiving Certificate Authority cryptographically verify that the request hasn't been tampered with in transit and that the requester genuinely controls the private key corresponding to the public key being submitted, before the CA goes on to perform its own separate identity verification process and issue a properly signed certificate.
This tool verifies that self-signature immediately after generating it, before ever presenting the CSR for download, using the same verification function (csr.verify()) a receiving CA would use, specifically to catch any possibility of a subtly malformed or incorrectly signed request before it's ever submitted anywhere.
This tool deliberately reuses the exact same RSA (via node-forge) and ECDSA (via @peculiar/x509, built on the native Web Crypto API) key generation approach already proven working in the Self-Signed Certificate Tool, rather than building a separate, independent cryptographic implementation. This is a deliberate choice: once a particular library integration and loading approach has been verified correct and working (including fixing the real CDN-loading bug documented in the Self-Signed Certificate Tool's own documentation), reusing that same verified foundation for a closely related tool reduces the chance of introducing a new, different bug while duplicating effort that's already been done correctly once.
The actual CSR-specific logic — building the PKCS#10 request structure, attaching the extension-request attribute that carries Subject Alternative Names, and signing the whole thing — uses node-forge's dedicated createCertificationRequest() function for RSA, and @peculiar/x509's dedicated Pkcs10CertificateRequestGenerator for ECDSA, both of which are purpose-built, separate code paths from the certificate-generation functions used by the Self-Signed Certificate Tool, even though they share the same underlying key-generation building blocks.
It's worth stepping back to explain why the entire CSR-and-CA process exists at all, rather than everyone simply self-signing their own certificates. The fundamental problem a Certificate Authority solves is establishing trust between parties who have never directly interacted before: when your browser connects to a bank's website for the first time, it has no independent way of knowing whether the server it's talking to is genuinely the bank, or an attacker intercepting the connection, unless some trusted third party has already verified that identity and vouched for it cryptographically.
Certificate Authorities perform exactly that verification before issuing a signed certificate — checking domain ownership at minimum, and for certain certificate types, verifying organizational identity through more extensive documentation review. Browsers and operating systems then extend automatic trust to any certificate signed by a CA whose own root certificate is included in their built-in trust store, which is a carefully curated, security-audited list maintained by browser and OS vendors specifically because the entire web's security model depends on that trust being well-placed.
This is precisely why self-signed certificates can't simply be "upgraded" to automatic trust by anyone other than you manually choosing to trust them yourself: no browser vendor extends blanket trust to arbitrary self-signatures, since doing so would defeat the entire purpose of the CA system, which exists specifically to ensure that trust is only extended after some actual verification has occurred. Going through the CSR submission and CA verification process is what allows a certificate to be automatically trusted by people who have never interacted with you before and have no independent reason to trust your server directly.
.csr file to submit to your Certificate Authority, and the .key file to keep secret and safe — you will need it later to install the certificate once your CA issues it.Requesting a certificate for an internal company tool at intranet.example.local might involve generating a CSR with Common Name intranet.example.local, Organization set to the company name, and submitting that CSR to the organization's own internal Certificate Authority, which would then verify the request internally and return a properly signed certificate trusted by every device already configured to trust that internal CA.
All key generation and CSR creation happen entirely within your browser. Your private key is never transmitted anywhere, logged, or stored by NexTechTools — it exists only in your browser's memory during generation and in the file you download. The only network activity involved is the one-time loading of the cryptography libraries from a public CDN when the page first loads.
Submitting the generated CSR to a real Certificate Authority is a separate action you take entirely outside this tool, using whatever submission process that CA requires, and is governed by that CA's own privacy practices, not NexTechTools'.
Submit it to whichever Certificate Authority you're requesting a certificate from, following their specific submission process (often pasting the CSR's text content into a web form, or uploading the file directly). The CA will verify your identity according to their own policies and, if approved, issue you a signed certificate.
Yes, absolutely. The private key generated alongside your CSR is what makes the eventual certificate yours to use — anyone who obtains a copy of it could potentially impersonate your certificate's identity. It should be stored securely and never shared or transmitted insecurely.
Technically yes, since a CSR just contains your request details and public key, but most workflows generate a fresh CSR and key pair for each new certificate request as a matter of good practice, rather than reusing the same key material across multiple issued certificates.
This is a safeguard against submitting a subtly malformed request to a real Certificate Authority, which could result in a confusing rejection or delay. Verifying the signature locally, using the same check a CA would perform, catches that kind of problem immediately rather than after submission.