CSR generator

What is a CSR?

A certificate signing request (CSR) is a small block of encoded text you send to a certificate authority (CA) when applying for an SSL/TLS certificate. It contains your public key and the identity the certificate should carry — the domain name, and for OV/EV certificates, your organization's verified details. The CA signs this information to produce your certificate. The matching private key stays with you and is never part of the CSR.

DV, OV and EV: which fields do you need?

• Domain Validation (DV): the CA only proves you control the domain — the CSR needs just the Common Name. This is what Let's Encrypt and most standard certificates use.
• Organization Validation (OV): the CA also verifies your company, so the CSR must include the organization name, city, state and country.
• Extended Validation (EV): the strictest vetting — the CSR carries the same subject fields as OV; the extra verification happens at the CA, not in the CSR.

RSA or ECDSA, and which size?

RSA 2048 is the universal default — accepted everywhere, required minimum at every public CA. ECDSA P-256 offers equivalent security with far smaller keys and faster TLS handshakes; every modern CA and browser accepts it. Larger keys (RSA 3072–8192, P-384, P-521) add security margin that most deployments will never need, at a real cost in handshake time — choose them when a compliance policy requires it. Note that RSA 6144 and 8192 can take a minute to generate even on fast machines.

Building a private CA: root and intermediate certificates

For internal infrastructure — VPNs, dev environments, mutual TLS between services — you can be your own certificate authority. Generate a root CA (self-signed, long-lived, distributed to your trust stores), then an intermediate CA signed by that root (shorter-lived, does the day-to-day signing while the root key stays offline). This tool builds both entirely in your browser; keep the root key somewhere very safe. A private CA is never appropriate for public-facing sites — browsers won't trust it.

Is this safe? Where are keys generated?

Everything happens in your browser. Key pairs are created by your own device's Web Crypto API, and the CSR or certificate is assembled and signed locally — no field you type and no key material is ever transmitted to nslookup.io. You can confirm this in your browser's developer tools: no network requests are made when you generate. Never use an online generator that creates keys on a server.

Frequently asked questions

Is it safe to generate a CSR or CA online?

It is with this tool: key pairs, CSRs and certificates are generated entirely in your browser using the Web Crypto API. Nothing you type and no key material is ever sent to our servers — you can verify that in your browser’s network tab, or even generate while offline.

What is the difference between DV, OV and EV certificates?

They differ in how thoroughly the certificate authority verifies you. Domain Validation (DV) only proves control of the domain, so the CSR needs just a Common Name. Organization Validation (OV) and Extended Validation (EV) verify your company too, so the CSR must also carry the organization name and address.

Which key should I choose — RSA or ECDSA?

RSA 2048 is the universal default every CA accepts. ECDSA P-256 gives equivalent security with much smaller keys and faster TLS handshakes, and is accepted by all modern CAs — but a few legacy systems still expect RSA. Larger sizes (RSA 4096+, P-384/P-521) add margin most sites never need, at real handshake cost.

What are root and intermediate CA certificates for?

A private CA lets you issue certificates for internal infrastructure — VPNs, dev environments, mutual-TLS between services. The root signs intermediates, intermediates sign server certificates, and only the root needs distributing to trust stores. Never use a browser-generated CA for anything public-facing.

What do I do with the private key?

Store it securely on the system that will use it — the CSR or certificate is public, but the private key is the secret itself. We never see it, so we cannot recover it: if you lose it, generate a new key and reissue.

Why does my CA reject my CSR?

The usual causes: a typo in the Common Name, a country field that isn’t a 2-letter ISO code, or an unsupported key. Decode your CSR with our decoder to check exactly what it contains before submitting it.

Related tools

• CSR & certificate decoder — verify what your CSR or chain contains
• SSL checker — inspect the certificate a site is serving right now
• DNS propagation checker — watch DNS validation records spread worldwide
• DNS lookup — see all records for any domain