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.
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.
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.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.
| Algorithm | Security level | When to use it |
|---|---|---|
| RSA-2048 | ~112-bit | The safe universal default. Accepted everywhere, including old appliances, embedded devices and legacy Java stacks. |
| RSA-4096 | ~140-bit | Higher 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-bit | Stronger than RSA-2048 with far smaller keys and much cheaper handshakes. The right choice for a modern public web server. |
| ECDSA P-384 | ~192-bit | Higher 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.
The format zoo is mostly an encoding question layered on a container question. Three facts resolve most of the confusion.
| Format | What it is | Contains a private key? | Typically seen on |
|---|---|---|---|
| PEM | Base64 text wrapped in -----BEGIN CERTIFICATE----- headers | Only if a key block is included in the file | Apache, Nginx, most Linux tooling |
| DER | The same ASN.1 structure in raw binary rather than Base64 | No (a key would be a separate DER file) | Windows, Java keystores, appliances |
| PFX / PKCS#12 | Password-protected bundle of certificate, private key and chain | Yes — treat the file as secret | IIS, Windows, load balancers, code signing |
| P7B / PKCS#7 | A certificate chain container | No | Windows, Java, chain distribution |
| CER / CRT | A file extension, not a format — the contents may be PEM or DER | No | Everywhere, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
| 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 |
| 1.2.840.113549.1.9.1 | Optional | admin@example.com | |
| SAN | 2.5.29.17 | Recommended | DNS:example.com, DNS:*.example.com |
| 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 |