Certificate CSR Generator & Format Converter

Generate a CSR or self-signed certificate with RSA or ECDSA keys, convert between PEM, DER, PFX and P7B, and verify chains. All in your browser.

Advertisement

Free Online CSR Generator and SSL Certificate Format Converter

This tool generates certificate signing requests, creates self-signed certificates for testing, converts certificates between PEM, DER, PFX/PKCS#12 and P7B/PKCS#7, and verifies certificate chains — all in the browser. Cryptographic operations use the Web Crypto API and PKI.js running as client-side JavaScript. The private key is generated on your device and is never transmitted: there is no upload step and no server involved in key generation.

That property is the reason to use a client-side CSR generator at all. A CSR is harmless — it is meant to be sent to a certificate authority. The private key created alongside it is not, and any online generator that produces the key pair on its server has had your private key in its memory. Here the key material exists only in the tab you have open, which you can confirm by watching the network panel while you generate, or by generating with the network disconnected after the page has loaded.

Even so, treat the output with care. Download the private key straight into secure storage, never paste it into a ticket, an email or a chat, and remember that production keys are conventionally generated on the server that will use them — with openssl req or the platform’s own certificate tooling — so that the key never travels at all. This tool is well suited to lab and test certificates, to appliances and devices with no usable command line, and to the format-conversion and inspection work that comes up constantly and has nothing to do with key generation.

The Four Tabs

  • Generate CSR — build a certificate signing request with a full subject and Subject Alternative Names, or produce a self-signed certificate with a chosen validity period.
  • Import Cert — load an existing certificate in PEM, DER, PFX or P7B and read its details: subject, issuer, validity dates, key algorithm, extensions and fingerprints.
  • Convert Format — move a certificate between all the major encodings, including an iOS-compatible PFX export.
  • Verify Chain — check that a certificate, its intermediates and its root form a valid chain, and confirm that a certificate and a private key are actually a matching pair.

How to Generate a CSR

  1. Choose the key algorithm. RSA-2048, RSA-4096, ECDSA P-256 or ECDSA P-384.
  2. Fill in the subject. Common Name (CN) is the primary hostname — www.example.com, or *.example.com for a wildcard. Organization, Organizational Unit, Country (a two-letter ISO code), State, Locality and Email are optional for domain-validated certificates and required for organisation- and extended-validation ones.
  3. Add Subject Alternative Names. This is the field that actually matters. Add a DNS entry for every hostname the certificate must cover; IP, Email and URI SANs are also supported.
  4. Generate, then save both outputs. The CSR goes to your certificate authority; the private key stays with you and must be present on the server when the signed certificate is installed.

The single most common mistake is relying on the Common Name alone. Every current browser ignores CN for hostname matching and validates only against the SAN extension, a change that has been in force since Chrome 58 in 2017. A certificate whose CN is example.com with no SAN entries will fail in every modern browser. Put every name in the SAN list, including the one you also put in the CN.

Choosing a Key Algorithm

AlgorithmSecurity levelWhen to use it
RSA-2048~112-bitThe safe universal default. Accepted everywhere, including old appliances, embedded devices and legacy Java stacks.
RSA-4096~140-bitHigher margin, but noticeably more CPU per TLS handshake. Sensible for long-lived internal CA roots; rarely necessary for a web server certificate.
ECDSA P-256~128-bitStronger than RSA-2048 with far smaller keys and much cheaper handshakes. The right choice for a modern public web server.
ECDSA P-384~192-bitHigher margin ECC; occasionally mandated by a compliance profile.

ECDSA P-256 gives better performance and stronger security than RSA-2048 at a fraction of the key size, which is why large sites have moved to it. The one caveat is old clients: if you must serve traffic from equipment that predates widespread ECDSA support, either stay on RSA or run a dual-certificate configuration.

Certificate Formats, Decoded

The format zoo is mostly an encoding question layered on a container question. Three facts resolve most of the confusion.

FormatWhat it isContains a private key?Typically seen on
PEMBase64 text wrapped in -----BEGIN CERTIFICATE----- headersOnly if a key block is included in the fileApache, Nginx, most Linux tooling
DERThe same ASN.1 structure in raw binary rather than Base64No (a key would be a separate DER file)Windows, Java keystores, appliances
PFX / PKCS#12Password-protected bundle of certificate, private key and chainYes — treat the file as secretIIS, Windows, load balancers, code signing
P7B / PKCS#7A certificate chain containerNoWindows, Java, chain distribution
CER / CRTA file extension, not a format — the contents may be PEM or DERNoEverywhere, confusingly

So “convert CRT to PEM” usually means “this file is DER and I need Base64”, and the reason a certificate imports on one platform but not another is almost always an encoding mismatch rather than anything wrong with the certificate. Because PFX carries the private key, a PFX file is exactly as sensitive as a private key: password-protect it properly and do not pass it around casually. The tool’s iOS-compatible PFX export uses TripleDES encryption, which is what Apple’s configuration profile import still expects.

Chain Order and Why Installs Fail

A working TLS install serves the leaf certificate first, then each intermediate in order up towards the root, and normally omits the root itself — clients already have it. The two failures that account for most “works in my browser, fails in curl” reports are a missing intermediate (desktop browsers often paper over it by fetching the issuer, while command-line clients and mobile apps do not) and a chain assembled in the wrong order. The Verify Chain tab checks both, and also confirms that a certificate and a private key genuinely correspond — the check worth running before a maintenance window rather than during one.

Related Tools

To inspect an existing certificate in detail, use the X.509 certificate decoder. To test what a live server is actually serving — chain, expiry, protocol and cipher support — use the SSL certificate checker. For OpenPGP rather than TLS keys, see the PGP key generator, and use the DNS lookup tool to confirm the CAA records that govern which CA is allowed to issue for your domain.

Frequently Asked Questions

Is my private key sent anywhere?

No. Key generation and every other cryptographic operation run in your browser through the Web Crypto API and PKI.js. Nothing is uploaded. Once the page has loaded, the tool works with the network disconnected.

Should I generate production keys in a browser?

For a high-value production certificate, the conventional and safest practice is to generate the key on the server that will use it, so the private key never exists anywhere else. Browser generation is well suited to test and lab certificates, to devices with no usable command line, and to situations where you will immediately move the key into a secrets manager or an HSM-backed store.

What is a CSR?

A certificate signing request is a signed blob containing your public key and the identity details you want certified. You send it to a certificate authority; the CA validates the identity and returns a signed certificate. The CSR never contains your private key.

What is the difference between CN and SAN?

Common Name is the legacy single-hostname field. Subject Alternative Name is the modern list of names a certificate covers. Browsers validate against SAN only, so every hostname must appear there — CN alone will fail.

Can I generate a wildcard CSR?

Yes. Use *.example.com as the Common Name and add it as a DNS SAN. Remember that a wildcard covers one label only: *.example.com matches www.example.com but not api.eu.example.com, and it does not match the bare example.com — add that as a second SAN entry.

What can I use a self-signed certificate for?

Development, internal testing, and services where you control every client and can distribute the certificate as trusted. Public browsers will warn on it, because nothing outside your own environment has any reason to trust it.

How long should a certificate be valid?

Public CAs issue for a maximum of about 13 months, and that ceiling is being reduced further over the coming years, so automated renewal is no longer optional for public certificates. Internal and self-signed certificates can be longer-lived, but short validity with automation is still the more resilient pattern.

Why does my certificate work in Chrome but fail in curl?

Almost always a missing intermediate certificate. Browsers can often fetch the issuer themselves; command-line clients and mobile SDKs generally will not. Install the full chain — leaf, then intermediates — and the problem disappears.

Do I need a new private key when I renew?

Not strictly — you can re-sign the same CSR — but generating a fresh key pair at renewal limits the damage from a key that has been quietly exposed. Rekey unless you have a specific reason such as certificate pinning not to.

How do I convert a PFX to separate PEM files?

Import the PFX on the Import tab with its password, then use Convert Format to export the certificate and the key as PEM. The equivalent OpenSSL commands are openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem and openssl pkcs12 -in cert.pfx -nocerts -nodes -out key.pem.

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

FieldOIDRequiredExample
Common Name (CN)2.5.4.3Yeswww.example.com
Organization (O)2.5.4.10For OV/EVExample Corp
Organizational Unit (OU)2.5.4.11OptionalIT Department
Locality (L)2.5.4.7For OV/EVSan Francisco
State (ST)2.5.4.8For OV/EVCalifornia
Country (C)2.5.4.6For OV/EVUS
Email1.2.840.113549.1.9.1Optionaladmin@example.com
SAN2.5.29.17RecommendedDNS:example.com, DNS:*.example.com

Certificate Types

TypeValidationTrust LevelIssuance Time
DV (Domain Validation)Domain ownership onlyBasic (lock icon)Minutes
OV (Organization Validation)Domain + organization verifiedMedium (org name visible)1-3 days
EV (Extended Validation)Thorough organization vettingHighest (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.
This tool is provided for informational and educational purposes only. All processing happens in your browser — no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results.