Certificate CSR Generator & Format Converter

What Is a Certificate Signing Request (CSR)

A Certificate Signing Request (CSR) is a block of encoded text containing the public key and identifying information (domain name, organization, location) that an organization submits to a Certificate Authority (CA) to apply for an SSL/TLS certificate. The CSR is generated on the same server where the certificate will be installed, ensuring the private key never leaves the server.

Generating a properly formatted CSR is the first step in obtaining any SSL/TLS certificate — whether from Let's Encrypt, DigiCert, Comodo, or any other CA. Incorrect CSR generation is a common source of certificate issuance delays and errors.

CSR Contents

Field	OID	Required	Example
Common Name (CN)	2.5.4.3	Yes	www.example.com
Organization (O)	2.5.4.10	For OV/EV	Example Corp
Organizational Unit (OU)	2.5.4.11	Optional	IT Department
Locality (L)	2.5.4.7	For OV/EV	San Francisco
State (ST)	2.5.4.8	For OV/EV	California
Country (C)	2.5.4.6	For OV/EV	US
Email	1.2.840.113549.1.9.1	Optional	[email protected]
SAN	2.5.29.17	Recommended	DNS:example.com, DNS:*.example.com

Certificate Types

Type	Validation	Trust Level	Issuance Time
DV (Domain Validation)	Domain ownership only	Basic (lock icon)	Minutes
OV (Organization Validation)	Domain + organization verified	Medium (org name visible)	1-3 days
EV (Extended Validation)	Thorough organization vetting	Highest (org name in certificate)	1-2 weeks

Common Use Cases

• SSL/TLS certificate procurement: Generate the CSR required to purchase or request a certificate from any Certificate Authority
• Certificate renewal: Generate a new CSR when renewing certificates, especially when changing key algorithms or adding SANs
• Wildcard certificate requests: Create CSRs for wildcard certificates (*.example.com) covering all subdomains
• Multi-SAN certificates: Generate CSRs with Subject Alternative Names to cover multiple domains in a single certificate
• Internal PKI: Generate CSRs for internal certificate authorities used in enterprise environments

Best Practices

1. Use RSA-2048 or ECDSA P-256 minimum — RSA-2048 is the minimum acceptable key size. ECDSA P-256 (or P-384) provides equivalent security with smaller keys and faster operations.
2. Include all SANs — Modern browsers check the Subject Alternative Name extension, not the Common Name. Include all hostnames and domain variations in the SAN field.
3. Generate a new key pair for each CSR — Don't reuse private keys across certificate renewals. Generate a fresh key pair each time to limit the impact of key compromise.
4. Protect the private key — The private key generated alongside the CSR must be protected. Set appropriate file permissions (600) and never share or transmit it.
5. Verify the CSR before submitting — Use this tool or OpenSSL (openssl req -verify -in request.csr) to confirm the CSR contains correct information before submitting to the CA.