CSR Generator (Certificate Signing Request)
Create a Certificate Signing Request (CSR) and its matching private key without leaving the page. Fill in the distinguished name — Common Name, Organization, Country and the rest — pick RSA (2048/3072/4096) or ECDSA (P-256/P-384), add any Subject Alternative Names (extra DNS names or IPs), and the tool builds a real PKCS#10 request, signs it, and PEM-encodes both the CSR and the PKCS#8 key. Keys are generated with the browser's native WebCrypto, so the private key is created on your machine and never uploaded.
How to use the CSR Generator (Certificate Signing Request)
Choose a key algorithm and fill in the distinguished name. Only the Common Name is strictly required — for a TLS certificate the CN is the primary hostname (for example example.com or a wildcard *.example.com); the other fields (Organization, Organizational Unit, Country, State, Locality, Email) are added to the subject if you provide them. Country must be a two-letter ISO code such as US or GB. Put any additional hostnames or IP addresses the certificate should cover in Subject Alternative Names, one per line; modern browsers ignore the CN and validate against the SAN list, so include every name there, including the one in the CN.
Click Generate. The tool creates a fresh key pair with WebCrypto, builds the CertificationRequestInfo (version, subject, public key, and a SAN extension request if you added any), signs it with the new private key, and emits two PEM blocks: the CSR to send to your certificate authority, and the private key (PKCS#8) to keep. Copy or download each. The CSR is safe to share — it contains only your public key and subject details — but the private key must stay secret and is never recoverable from this page once you navigate away, so save it before you do. You can sanity-check the request with openssl req -text -verify -noout -in request.csr.
What a CSR is and what goes in it
A Certificate Signing Request is the standard message you send to a certificate authority (CA) to ask it to issue a certificate. Its format is defined by PKCS#10: a DER-encoded structure containing the subject (the distinguished name identifying who the certificate is for), the subject public key, an optional set of requested attributes and extensions, and a self-signature made with the corresponding private key. That self-signature proves to the CA that whoever submitted the request actually holds the private key for the public key inside it — a proof of possession. The CA validates your control of the domain, then issues a certificate that binds your public key and subject to its own signature.
The private key never goes into the CSR and is never sent to the CA. It is generated alongside the request and stays with you; the certificate the CA returns is useless without it. This separation is the whole point of public-key infrastructure: the public half travels in the CSR and the issued certificate, while the secret half stays on your server. The most important modern detail is Subject Alternative Names. Historically the hostname lived in the Common Name, but every current browser and the CA/Browser Forum baseline requirements now validate the SAN extension instead, treating the CN as legacy. A request for a real TLS certificate therefore carries the hostname (and any alternates — extra subdomains, IP addresses, a wildcard) in the SAN extension request, which a CA copies into the issued certificate.
Algorithm choice comes down to compatibility versus size and speed. RSA 2048 is the universally accepted baseline; RSA 3072 adds margin; ECDSA on P-256 or P-384 produces much smaller keys and faster handshakes and is widely supported, though a few old clients still expect RSA. This generator runs entirely client-side: the key pair is produced by the browser's WebCrypto implementation, the PKCS#10 structure is assembled and signed locally, and nothing — neither the key nor the request — is transmitted anywhere. That makes it safe for production keys, and it means you can generate a request offline.
Common use cases
- Request a TLS certificate. Generate the CSR and key, submit the CSR to your CA (or paste it into a hosting panel), and install the returned certificate with your saved key.
- Multi-domain / SAN certificates. List every hostname and IP the certificate must cover in the SAN box to request a single certificate that validates them all.
- Wildcard certificates. Put
*.example.comin the Common Name and SAN to request a certificate covering all subdomains. - Re-key or renewal. Produce a brand-new key pair and matching CSR when rotating keys or renewing an expiring certificate.