Certificate Signing Request (CSR) Generator

Field	Value	Copy
{{ r.k }}	{{ r.v }}
No data.

A certificate request sits between key creation and certificate issuance. It carries the public half of a key pair, names the identity being requested, and signs that request with the matching private key. The signature proves possession of the private key, but it does not prove that the requested name is valid, authorized, or ready to deploy.

That review point matters because CSR mistakes often survive until an issuer rejects the order or a deployed certificate fails a client check. A missing host name can break TLS for one endpoint, a wildcard can cover more than the team intended, and copied organization details can create cleanup work in asset inventories or private-PKI policy reviews.

CSR concepts and practical meaning
Concept	Plain meaning	Common mistake
Private key	The secret key kept by the requester and used to sign the CSR.	Sending it to an issuer or storing it beside the CSR as if both files were equally safe.
Public key	The key material the future certificate would bind to the requested identity.	Regenerating the key by accident during renewal when continuity was expected.
Subject	The distinguished-name fields such as common name, organization, locality, and country.	Treating the common name as the whole TLS identity set.
Subject Alternative Name	Typed DNS names or IP addresses requested for certificate identity matching.	Leaving out aliases, apex domains, service names, or literal IP addresses that clients must trust.
Requested extensions	Hints such as key usage, Extended Key Usage, and SAN that the issuer may honor or adjust.	Assuming the final certificate will copy every requested extension exactly.

The common name is still a familiar field, but modern TLS service identity is built around Subject Alternative Name entries. DNS names and IP addresses are different SAN types, and clients match those typed entries when deciding whether a certificate fits a host. A request for www.example.com that omits example.com or api.example.com does not silently cover those names.

Usage fields need the same care as names. Key usage describes what the public key is meant to do, while Extended Key Usage narrows the application purpose, such as TLS server authentication or client authentication. Private PKI systems, appliances, and older workflows may also ask for a challenge password, but many public TLS orders ignore it.

A CSR also leaves out important certificate facts. It does not contain the future issuer name, serial number, validity period, revocation endpoints, certificate-transparency logging, or the final certificate-authority signature. Treat it as a precise request to review, not as proof that a deployable certificate already exists.

How to Use This Tool:

Enter the main requested identity in Common Name (CN). The field accepts a DNS name, a leading-wildcard DNS name such as *.example.com, or a literal IPv4 or IPv6 address.
Review Subject Alternative Names before generating. The default field includes example.com,www.example.com; replace that with the real comma-separated DNS names and IP addresses the certificate should cover.
Keep Auto-add CN to SAN when SAN is empty on for a single-name request, or turn it off when you intentionally want no SAN entries. For modern TLS, an empty SAN list is rarely what you want.
Use the basic 2048 bits key size unless policy requires 3072 bits or 4096 bits. Larger RSA keys make generation and later use heavier without changing the request format.
Open Advanced for subject details, digest choice, private-key encryption, requested key usage, requested Extended Key Usage, challenge password, and automatic download. Leave organization, locality, email, usage, and EKU fields blank unless your issuer or internal policy needs them.
If you enable Encrypt private key, enter the same passphrase twice. The passphrase must be at least four characters, and the exported key still needs careful storage even when it is encrypted.
Click Generate CSR. If the browser reports that key generation is unavailable, reopen the page over HTTPS, localhost, or 127.0.0.1, because browser key generation requires a secure context.
After generation, compare the Request Summary, CSR PEM, Private Key, OpenSSL Command, OpenSSL Config, and JSON outputs with your issuance plan before copying, downloading, or submitting anything.

Interpreting Results:

A successful generation means the browser created a key pair, signed a PKCS #10 request, and prepared exportable text. It does not mean a certificate authority has approved the request, verified domain control, accepted the requested extensions, or promised a matching final certificate.

How to interpret CSR generator results
Visible result	What it means	What to check next
SAN 0	No SAN entries are being requested.	For TLS, regenerate with explicit SAN values unless your issuer has a special non-TLS workflow.
SPKI SHA-256	A SHA-256 fingerprint of the generated public key structure.	Compare it with renewal records or inventory entries when key continuity matters.
Digest SHA-256, SHA-384, or SHA-512	The hash family used in the CSR signature.	Do not read it as the final certificate signature choice, lifetime, or validation level.
PRIVATE KEY	The exported PKCS #8 private key is not passphrase protected.	Move it into secret storage immediately and avoid sharing it with the CSR.
ENCRYPTED PRIVATE KEY	The exported PKCS #8 private key is wrapped with passphrase-based encryption.	Keep the passphrase separately and test compatibility with the system that will import the key.
OpenSSL Config	A text configuration matching the selected subject, SAN, key usage, EKU, and digest choices.	Use it as a readable audit aid, especially when the summary table hides extension details.

The summary table is useful for the main identity, key size, digest, and public-key fingerprint. The OpenSSL and JSON outputs are better for reviewing every requested SAN, key-usage bit, EKU value, and challenge-password entry before a CSR leaves your workstation.

Technical Details:

PKCS #10 defines a certification request as a signed structure around three ideas: request information, a signature algorithm, and the signature value. The request information contains the subject distinguished name, the SubjectPublicKeyInfo value for the public key, and optional attributes. Extension requests and challenge passwords are attributes, not final certificate extensions.

The generated request uses an RSA key pair and a PKCS #1 v1.5 signature algorithm with the selected SHA-2 digest. The CSR is wrapped in PEM text labeled CERTIFICATE REQUEST. The private key is exported as PKCS #8 PEM, either PRIVATE KEY when left clear or ENCRYPTED PRIVATE KEY when passphrase protection is enabled.

Request Construction Core

PKCS 10 CSR structure and generated content
Structure	Generated content	Technical note
CertificationRequestInfo version	Version `0`.	This is the standard version value for PKCS #10 requests.
Subject distinguished name	CN plus optional C, ST, L, O, OU, and email fields.	Country is encoded as a printable two-letter value; most other subject text is encoded as UTF-8.
SubjectPublicKeyInfo	The generated RSA public key.	The SPKI SHA-256 value shown in results fingerprints this public-key structure.
Extension request attribute	SAN, key usage, and EKU only when at least one of those values is present.	SAN DNS names use the `dNSName` general-name type; IP addresses use the binary `iPAddress` type.
Challenge password attribute	A UTF-8 challenge-password value when supplied.	It is an old PKCS #9 attribute and should be used only when the target workflow expects it.
Outer signature	RSA signature over the request information using SHA-256, SHA-384, or SHA-512.	The signature proves possession of the generated private key at request time.

Subject Alternative Name handling is type-sensitive. DNS names, including a leading wildcard form such as *.example.com, are encoded as IA5String dNSName entries. IPv4 addresses become four-byte iPAddress entries, and IPv6 addresses become sixteen-byte iPAddress entries. This difference is why a literal IP address should not be treated as a DNS name in certificate review.

Validation and request boundaries
Input or option	Accepted shape	Boundary to remember
Common name and SAN DNS values	Hostname labels up to 63 characters, total hostname length up to 253 characters, optional leading wildcard.	A bare `*`, empty label, or label starting or ending with a hyphen is rejected.
IP SAN values	IPv4 octets from 0 to 255 or a basic IPv6 colon-separated form.	The result records IP SANs as IP entries, not DNS entries.
Country	Two letters.	The value is uppercased in outputs.
Digest	SHA-256, SHA-384, or SHA-512.	The digest applies to the CSR signature, not to final certificate validity or CA policy.
Key usage	`digitalSignature`, `keyEncipherment`, `dataEncipherment`, and `keyAgreement`.	When requested, key usage is encoded as a critical extension request.
Extended Key Usage	`serverAuth` and `clientAuth`.	Leave EKU empty unless the certificate purpose is known and the issuer accepts the request.
Encrypted private key	Matching passphrase fields with at least four characters.	The protected PKCS #8 output uses PBES2 with PBKDF2-SHA-256 and AES-256-CBC.

Text armor is only a wrapper around binary structures. The CERTIFICATE REQUEST, PRIVATE KEY, and ENCRYPTED PRIVATE KEY PEM labels help importing software choose the right decoder, but they do not say anything about issuer trust, domain validation, or whether the generated key is stored safely after download.

Privacy Notes:

Key generation, CSR assembly, fingerprint calculation, optional private-key encryption, copying, and downloads happen in the browser. The CSR-generation workflow does not need to send the private key or CSR to a server to produce the PEM output.

The page can mirror form values into the browser address while you edit. That is convenient for restoring or sharing ordinary settings, but it is a poor place for secrets. Challenge-password text and private-key passphrases can appear in browser history, copied links, screenshots, sync logs, or screen recordings if you type them into the page.

Use a trusted browser session, avoid production passphrases that could leak through the address bar, clear shared links before sending them, and move downloaded private keys into the secret store or server configuration path that will actually protect them. Clipboard contents and downloaded files remain sensitive even though the key was generated locally.

Worked Examples:

Replacing the sample names with one real host

For a single-host request for www.example.com, change Common Name (CN) to www.example.com and clear the sample SAN list. With automatic CN-to-SAN copying left on, the generated result should show SAN 1. Review the OpenSSL config to confirm one DNS SAN entry for www.example.com.

Preparing a multi-name certificate request

A service needs example.com, www.example.com, api.example.com, and 203.0.113.10. Put the main service name in CN, then enter all four values in the SAN field. The JSON and OpenSSL config outputs should separate the first three values as DNS entries and the address as an IP entry.

Requesting usage hints for a private PKI

An internal client-certificate workflow may need clientAuth and may not want serverAuth. Open Advanced, select only the EKU that matches the workflow, add key-usage bits only when the internal CA expects them, and regenerate. Treat the result as a request for those extensions, not a guarantee that the CA will issue them exactly as requested.

Fixing a generation failure

If generation does not start, check the secure-context warning, invalid field markers, and encrypted-key passphrase fields. The most common fixes are opening the page over HTTPS or localhost, replacing a malformed SAN value, entering a two-letter country code, or making the two passphrase fields match.

FAQ:

Does the page send my private key to a server?

No. The key pair, CSR, optional encryption, and exports are created in the browser. Be careful with the address bar, clipboard, downloads, and screenshots because those can still expose names, challenge-password text, or passphrases.

Why does the private-key PEM say PRIVATE KEY instead of RSA PRIVATE KEY?

The exported key uses PKCS #8 PEM. That format labels a clear private key as PRIVATE KEY and a passphrase-protected key as ENCRYPTED PRIVATE KEY, even though the generated key algorithm is RSA.

Can I rely on common name alone for a website certificate?

No for ordinary modern TLS. Put every DNS name and literal IP address that clients must trust into the SAN list. The common name can still be present, but it should not be the only place that names the service.

Are key usage and EKU selected by default?

No. The default request includes the sample SAN values but leaves key usage and Extended Key Usage unselected. Select those values only when your issuer or private PKI process expects CSR extension requests.

Will the issuer copy my requested extensions?

Not necessarily. A certificate authority can honor, adjust, ignore, or reject requested extensions according to its policy. Always inspect the issued certificate before deployment.

Can this generate ECDSA or Ed25519 CSRs?

No. The current generator creates RSA CSRs only, with 2048-bit, 3072-bit, or 4096-bit key sizes and SHA-2 request signatures.

What should I submit to the certificate authority?

Submit the CSR PEM, not the private key. Keep the private key on the server, device, or secret-management path that will use the issued certificate.

Glossary:

CSR: A certificate signing request that asks an issuer to create a certificate for a subject and public key.
PKCS #10: The standard syntax used for most certificate signing requests.
Subject Alternative Name: The X.509 extension that carries typed DNS names and IP addresses used for service identity matching.
SPKI: SubjectPublicKeyInfo, the public-key structure whose SHA-256 fingerprint appears in the result summary.
Key usage: An X.509 extension that constrains how the certified public key may be used.
Extended Key Usage: An X.509 extension that narrows certificate purpose, such as TLS server authentication or client authentication.
PKCS #8: A private-key container format used for both clear and encrypted private-key PEM output.
Challenge password: An optional PKCS #9 CSR attribute used by some older or private certificate workflows.

References:

RFC 2986: PKCS #10 Certification Request Syntax Specification Version 1.7, RFC Editor.
RFC 2985: PKCS #9 Selected Object Classes and Attribute Types Version 2.0, RFC Editor.
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC Editor.
RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, RFC Editor.
RFC 9525: Service Identity in TLS, RFC Editor.
NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths, NIST.
openssl-req, OpenSSL Documentation.
How to create a CSR using OpenSSL, Simplified Guide.