Certificate Signing Request (CSR) Generator

Introduction:

A certificate signing request, or CSR, is the signed application created before a certificate authority issues an X.509 certificate. It binds a subject name to a public key and can also ask for extras such as Subject Alternative Name (SAN) entries, key-usage hints, extended key usage values, or a challenge password.

That request matters because certificate mistakes often begin before issuance. A common name can look right while the SAN set is incomplete, a wildcard can be broader than intended, or the requested certificate purpose can be mismatched from the start. A CSR also cannot promise what the final certificate will contain. It shows what the requester asked for and proves possession of the matching private key at the moment the request was signed.

For modern TLS, the requested service identities usually belong in SAN rather than in common name alone. DNS names and IP addresses are typed differently there, and certificate consumers match those typed SAN entries when deciding whether a certificate fits a host.

A CSR is also narrower than many people expect. It does not contain the future issuer name, the validity period, revocation information, or the final CA signature. Those appear later if the request is accepted and turned into a certificate.

Technical Details:

PKCS #10 defines a CSR as three top-level pieces: the certification request information, the signature algorithm identifier, and the signature itself. The request-information block carries the subject distinguished name, the SubjectPublicKeyInfo (SPKI) structure that holds the public key, and a set of attributes. That layout matters because most practical review questions map directly to it. One set of fields describes who or what the certificate should identify, another fixes the public key that will be bound to that identity, and the attribute set carries optional requests about extensions.

Those attributes often matter more than the subject text alone. The PKCS #9 extensionRequest attribute is the standard place to ask for X.509 extensions such as SAN, key usage, and Extended Key Usage (EKU). PKCS #9 also defines challengePassword, an optional single-value attribute that older or private workflows may still use even though many web-PKI orders do not depend on it.

Identity rules have changed over time, but the current direction is clear. For TLS service identity, typed SAN entries are the authoritative identifiers. A dNSName SAN entry is used for DNS hostnames, and an iPAddress SAN entry is used for literal IP addresses. The common name is no longer the right place to rely on for host matching in modern TLS clients.

Requested usage hints also have to make sense together. RFC 5280 treats key usage and EKU as independent constraints that must both allow the intended certificate purpose. For TLS server authentication, serverAuth in EKU is typically paired with key-usage bits that support signatures and, in many RSA deployments, key encipherment. A CSR can ask for those values, but the issuer still decides which extensions, criticality, and exact semantics appear in the final certificate.

Key length and signature choices affect both policy fit and operating cost. NIST treats digital-signature key sizes below the 112-bit security-strength floor as unacceptable for new signature generation, which is why current general-purpose RSA CSR workflows begin at 2048 bits. Larger RSA sizes can add computational cost and larger request material without changing the basic CSR structure.

Text armor matters too. RFC 7468 standardizes the PEM labels used to wrap the DER structures, including CERTIFICATE REQUEST for the CSR and ENCRYPTED PRIVATE KEY for encrypted PKCS #8 key output. Those labels tell downstream software what object is being imported, but they still describe only a request and its key material, not a finished certificate.

Everyday Use & Decision Guide:

Begin with the exact identity set you intend to certify. For one host, enter the fully qualified domain name or literal IP in Common Name (CN) and leave Auto-add CN to SAN enabled only if the SAN field would otherwise stay empty. For anything broader, type the full comma-separated SAN list yourself so the request matches the real deployment instead of a simplified placeholder.

Open Advanced before generating if the request is not meant to be a typical RSA TLS server profile. The current defaults request digitalSignature, keyEncipherment, and serverAuth; clientAuth is off. That fits many ordinary server-certificate requests, but it is not neutral. If you are preparing a client certificate, a private-PKI certificate with different rules, or a request that should carry no EKU hint at all, change those checkboxes first.

• Leave Organization (O), Org Unit (OU), and the rest of the subject fields blank unless your CA or internal policy expects them. Many domain-validation workflows do not need a full distinguished name.
• Use 3072 bits or 4096 bits only when policy or risk appetite calls for it. They make generation slower and the artifacts heavier without changing what a CSR fundamentally is.
• Turn on Encrypt private key only when you already have a safe place for the passphrase and the exported key file. A passphrase-protected key is still a secret, not a casual download.
• Read CSR Summary for the quick fingerprint and subject check, then open OpenSSL or JSON to confirm SAN, key usage, EKU, and challenge-password requests because the summary table does not list every requested extension.

Once the request is generated, the page can copy or download the CSR and private key, export the summary as CSV or DOCX, save the structured JSON payload, and download a generated openssl.cnf. Before you submit the request anywhere, compare the SPKI SHA-256 fingerprint and the SAN count with your real issuance plan.

Step-by-Step Guide:

1. Enter the primary identity in Common Name (CN). The field accepts a hostname, a wildcard such as *.example.com, or a literal IPv4 or IPv6 address.
2. Fill Subject Alt Names with every DNS name or IP address the certificate must cover. If you leave it empty and keep Auto-add CN to SAN enabled, the page will request a single SAN entry copied from the common name.
3. Add optional subject details only when they are genuinely needed. Country (C) must be a two-letter code, Email must parse as an email address, and blank organizational fields are acceptable when policy does not require them.
4. Open Advanced and set the digest, key size, encryption choice, requested key-usage bits, requested EKU values, optional challenge password, and Auto-download files. If you enable private-key encryption, the passphrase must be at least four characters and both passphrase fields must match.
5. Click Generate CSR. If the page reports that Web Crypto is unavailable or you are on HTTP, reopen the page over HTTPS or localhost and try again because browser key generation requires a secure context.
6. Review CSR Summary for the subject fields, key size, digest, SAN count, and SPKI SHA-256. Open OpenSSL or JSON to verify the requested SAN, KU, EKU, and challenge-password details before sending the CSR to any issuer or automation flow.
7. Copy or download the CSR and private key only after the request matches your intended certificate scope. If another system needs a text template rather than the generated CSR, download the generated openssl.cnf or copy the one-line OpenSSL command.

Interpreting Results:

The success alert means the request and key were generated, not that an issuer will necessarily approve or mirror the request. The important checks are identity coverage, requested certificate purpose, public-key continuity, and whether the exported private key is protected the way you intended.

Do not stop at a familiar common name or a neat PEM block. A request can still ask for the wrong SAN set, the wrong EKU, or an unprotected private key. The fastest correction is to read the generated openssl.cnf or JSON output and compare those values with the real host list and certificate purpose.

Worked Examples:

Single-host web request

A request for www.example.com is created with Common Name (CN) set to that hostname, an empty SAN field, Auto-add CN to SAN left on, 2048 bits, and the default server-oriented usage hints. The quick check is simple: SANs 1 should appear, SPKI SHA-256 should be populated, and the OpenSSL tab should show one DNS SAN line for www.example.com.

One request for several names and an IP address

A deployment needs www.example.com, example.com, api.example.com, and 203.0.113.10. Putting only www.example.com in the common name is not enough. The fix is to type the full comma-separated SAN list, then use the OpenSSL or JSON output to confirm that DNS names and the IP address were encoded as separate requested SAN entries before the CSR is sent anywhere.

Generation fails before the request appears

A request never reaches the success state because the page is opened over ordinary HTTP or because the two passphrase fields do not match. The corrective path is to reopen the page over HTTPS or localhost, then either turn off Encrypt private key or enter a matching passphrase of at least four characters. After that, generate again and recheck the PEM label so you know whether the private key was exported clear or encrypted.

FAQ:

Responsible Use Note:

Browser-side generation avoids sending the private key to a CSR-generation API, which is a real security benefit. That benefit has an important limit here: the page's shared-state behavior mirrors form inputs into the URL while you edit them. Subject details may be routine, but challenge-password text and typed passphrases are still secrets that should not linger in browser history or shared links.

Use the page on a device you trust, avoid reusing production passphrases carelessly, clear the address bar and history state after use, and move the downloaded private key into proper secret storage immediately. Clipboard copies, downloaded files, and visible tabs remain sensitive even when generation stayed local.

Glossary:

CSR

A certificate signing request that asks an issuer to create a certificate for a named subject and public key.

SAN

Subject Alternative Name, the X.509 extension that carries typed DNS names or IP addresses for certificate identity matching.

SPKI

SubjectPublicKeyInfo, the standard structure that holds a certificate or CSR public key together with its algorithm identifier.

EKU

Extended Key Usage, an X.509 extension that limits certificate use to named application purposes such as TLS server or client authentication.

PKCS #8

A standard private-key container format used for both clear PRIVATE KEY and encrypted ENCRYPTED PRIVATE KEY PEM output.

Challenge password

An optional PKCS #9 CSR attribute that some older or private workflows still use, even though many public TLS orders do not rely on it.

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 Certificate Revocation List (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.