SSL CSR Generator

Generate a CSR with SANs and export a matching private key in PEM format.

SSL CSR Generator

Create a CSR and matching private key for any certificate authority.

Settings Prefilled examples
Use your primary hostname (the main domain you want the certificate to secure).
Two-letter country code (ISO 3166-1 alpha-2), e.g. US, GB, PL.
One entry per line. Optional prefixes: DNS: or IP:.
0 entries
Required only when key encryption is enabled.
Security note: The safest practice is to generate private keys on the server where the certificate will be installed.
Result PEM output
No output yet
Fill in your certificate details and click Generate.
Copied

About SSL CSR Generator

SSL CSR Generator for Certificate Signing Requests

An SSL Certificate Signing Request (CSR) is the standardized payload you submit to a certificate authority (CA) to request an SSL/TLS certificate. This SSL CSR Generator helps you create a properly formatted CSR and a matching private key, with support for Subject Alternative Names (SANs) so the issued certificate works across multiple hostnames.

If you have ever copied a CSR from a server terminal, you have seen the familiar PEM header and footer lines. Between those lines is a base64-encoded structure containing your public key and identity fields. Generating it correctly is important because the CA will issue a certificate that mirrors the exact names and key contained in the CSR.

How SSL CSR Generator Works

A CSR bundles your certificate identity details (also called the distinguished name, or DN) together with a public key. The public key is derived from the private key that stays on your server. When you submit the CSR to a CA, the CA validates your request and signs a certificate that matches the CSR’s public key and identity information.

Different validation levels focus on different parts of the CSR. For DV (Domain Validation), the CA primarily verifies control of the domain names listed in SAN. For OV and EV, the subject fields such as Organization and address details become more important, because the CA must confirm your organization identity in addition to domain control.

Step-by-step CSR creation

  • 1) Enter certificate identity fields: Provide the Common Name (CN) and, if needed, Organization (O), Organizational Unit (OU), Locality (L), State/Province (ST), and Country (C). These values become the subject of your certificate and should reflect the information your CA expects.
  • 2) Add SAN hostnames and IPs: Include one domain or IP per line (for example, example.com, www.example.com, or IP:203.0.113.10). SANs let a single certificate cover multiple names and are the modern standard for hostname validation.
  • 3) Choose key size and hash algorithm: Select a secure RSA key size (2048 or 4096) and a digest algorithm (such as SHA-256) used to sign the CSR. Strong digests help prevent tampering and keep your request aligned with current CA policies.
  • 4) Generate the private key: The tool creates a fresh private key. You can optionally protect it with a passphrase for additional at-rest security, especially when the key is stored outside of a hardware or managed key vault.
  • 5) Generate and export the CSR: The CSR is produced in PEM format, ready to paste into your CA order form. The private key is exported separately and should be stored securely on the server where the certificate will be installed.
  • 6) Submit to your CA and complete validation: After ordering, you will typically prove domain control by DNS record, HTTP file upload, or email challenge. Once the CA finishes checks, you download the certificate and any intermediate chain.
  • 7) Install the certificate with the same private key: The certificate must be paired with the private key generated here. If the key is lost or regenerated, the certificate will not work and you will need to reissue using a new CSR.

Key Features

CSR and private key generated together

A CSR is only useful when you also have the private key that created it. This generator outputs both files in PEM format so you can complete the CA request and later install the issued certificate on the same system that holds the private key. Keeping the files together also reduces the risk of ordering a certificate with one key and attempting to deploy it with another.

Many deployment issues come down to mismatched keys. By generating a fresh key pair and exporting the CSR in one workflow, you minimize confusion and can archive the CSR alongside your certificate order notes for future troubleshooting.

Subject Alternative Names support

Modern TLS relies on SANs rather than the CN alone. By listing domains and IP addresses in SAN, you ensure browsers and clients recognize the certificate for each hostname you plan to serve, including API subdomains, staging hosts, and load-balanced endpoints.

SAN planning is also helpful for migrations. If you are moving traffic from an old hostname to a new one, you can temporarily include both names in SAN to avoid certificate warnings during cutover windows.

Secure defaults and broad CA compatibility

The tool uses RSA keys with modern digest algorithms and emits standard PEM blocks accepted by most providers. Use RSA 2048 for broad compatibility, or RSA 4096 when you want a larger key size and are confident your environment can handle the additional CPU overhead during handshakes.

PEM output is the most common format for web servers and certificate portals. If your CA asks for the CSR “as text,” you can paste the CSR block exactly as shown, including the header and footer lines.

Optional private key encryption

You can encrypt the private key with a passphrase. This is helpful when the key must be stored outside of a secure key store, or when you need to transfer it between trusted admins. Remember that a passphrase may require manual entry during service startup, depending on your web server and automation strategy.

If you are deploying with automation (containers, CI/CD, infrastructure as code), you may prefer an unencrypted key stored in a locked-down secret manager and injected at runtime. In that case, keep the passphrase option disabled and focus on access controls and auditing.

Readable subject and SAN preview

Alongside the output, the generator summarizes the selected subject fields and SAN list so you can quickly verify what you are requesting before you submit the CSR to a CA. This reduces common mistakes such as inverted locality/state values, missing SAN entries, or incorrect country codes.

A quick review is especially valuable for OV and EV certificates where organization data must match official records. A minor typo can delay issuance, so validating your input before ordering saves time.

Copy-ready and download-friendly output

CSR and private key blocks can be copied directly into a CA portal, saved into deployment notes, or downloaded as text files for server installation. The tool formats the output cleanly to avoid hidden characters and whitespace issues that sometimes appear when copying from terminals or chat apps.

Use Cases

  • Buying a new SSL/TLS certificate: Generate a CSR for DV, OV, or EV orders and submit it to your chosen CA.
  • Renewing an expiring certificate: Create a fresh key pair and CSR for renewal to follow best practices and reduce key reuse across years.
  • Multi-domain certificates: Add several SAN entries for a single certificate that covers multiple sites or services under the same management boundary.
  • Wildcard preparation: Generate CSRs for wildcard requests such as *.example.com while keeping the CN aligned with CA requirements and internal naming conventions.
  • Load balancers and reverse proxies: Produce CSRs for TLS termination on a proxy tier (Nginx, HAProxy, cloud load balancers) rather than on application servers, keeping private keys centralized.
  • Internal PKI and private CAs: Create CSRs for certificates issued by corporate or lab CAs where you control the signing process and can standardize subject fields.
  • Dev, test, and staging environments: Generate CSRs for non-production endpoints to validate automation, confirm SAN planning, and practice renewals before production deadlines.

Whether you manage one domain or a fleet of microservices, a consistent CSR workflow reduces configuration errors and helps keep your TLS posture predictable and auditable. It also makes handoffs easier: you can generate the CSR, attach it to a ticket, and let a security or compliance team complete the order with the CA.

For teams that rotate certificates frequently, having a repeatable “CSR checklist” is a major win. You can standardize key sizes, default to SHA-256, keep SAN naming patterns consistent, and reduce the chance of issuing a certificate that does not cover a critical endpoint.

Optimization Tips

Match the Common Name to your primary hostname

Many CAs still expect the CN to match the main domain you plan to secure, even when SANs are present. Use your most important hostname as the CN (for example, example.com) and list additional names in SAN, including www and API subdomains. When you are requesting a wildcard, the CN is often the wildcard name itself, such as *.example.com, while SAN can include both the wildcard and the apex domain if your CA supports it.

Prefer SANs for all hostnames you serve

Clients validate hostnames primarily against SAN. If you want the certificate to work for example.com and www.example.com, include both in SAN explicitly. For IP-based access (less common on the public web), add IP entries using the IP prefix. Keep the SAN list minimal and intentional: only include names that belong to the same security boundary, because any server holding the private key can impersonate any SAN name covered by the certificate.

Protect keys and validate your request before ordering

Limit file permissions, avoid emailing private keys, and use an HSM or managed key store when possible. If you enable key encryption, ensure your operational model supports it; otherwise, you may create startup friction when services require the passphrase. Before submitting to a CA, double-check your SAN list and consider verifying the CSR with your local tooling (for example, using OpenSSL on a server) to confirm the subject and extensions match what you intended.

FAQ

A CSR is a signed request that contains your public key and certificate identity details. Certificate authorities use it to create and sign an SSL/TLS certificate that matches your key pair and the names you want to secure. The CSR does not contain your private key.

RSA 2048 is the standard choice for compatibility and performance. RSA 4096 provides a larger key size but can increase CPU usage during handshakes; it is often used when policy requires it or when performance impact is acceptable. If you are unsure, RSA 2048 with SHA-256 is a widely accepted default.

SANs are additional hostnames or IP addresses that a certificate should cover. Browsers validate names against SAN first, so including every hostname you serve is the safest approach, even if it duplicates the Common Name. SANs are essential for multi-domain certificates and are common even for single-domain deployments.

Reusing a key is possible, but rotating keys at renewal is a common best practice. Generating a new key pair reduces long-term exposure risk and helps keep cryptographic material fresh across certificate lifecycles. If you must reuse a key, ensure it is stored securely and has not been exposed.

The safest approach is to generate keys and CSRs on the server that will use the certificate, so the private key never leaves that environment. If you generate online, treat the private key as highly sensitive, store it securely, and avoid transmitting it over insecure channels. Consider using key encryption and secure secret storage if your workflow requires moving the key.

Why Choose This SSL CSR Generator?

Creating a CSR should be quick, accurate, and compatible with the CA you trust. This tool focuses on the essentials: correct subject formatting, SAN support, and exportable PEM output that integrates cleanly into common certificate workflows. The interface is designed to reduce mistakes by making the important fields obvious and by summarizing what will be included in the request.

Use it whenever you need a fresh CSR, whether you are preparing a certificate purchase, rotating keys during renewal, or provisioning secure endpoints for new services. With sensible defaults and copy-ready output, you can move from configuration to CA submission in minutes while keeping your private key under your control. For larger teams, the generator also supports consistent naming habits, which helps when certificates are reviewed during audits or incident response.