{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

RSA{{ normalized.key_size || '—' }} bit SANs{{ computation.ok ? computation.values.san_count : '—' }} Key{{ encrypt_key ? 'Encrypted' : 'Unencrypted' }}
Example: example.com or *.example.com.
Enter a valid DNS name, wildcard DNS name, IPv4 address, or IPv6 address.
Separate DNS names or IP addresses with commas or new lines.
Remove or correct the invalid subject alternative name.
The private key never leaves this browser.
The neutral default requests no key usage. Choose a profile only when it fits the intended certificate.
Custom key usage:
Use a two-letter country code.
Enter a valid email address or leave it blank.
Use at least eight characters.
The passphrases must match.
{{ csr_pem }}
{{ private_key_pem }}

{{ chart_state === 'unavailable' ? 'The chart could not load or draw. Check your connection, then retry. The counts remain available as CSV.' : 'Loading chart…' }}

FieldValueMeaningCopy
{{ row.label }}{{ row.value }}{{ row.detail }}
{{ opensslConfig }}
Alternative DCV Checker Check alternative certificate DCV proofs across DNS and web paths, including CSR-derived values and per-host mismatch or transport evidence.
SSL Certificate Chain Checker Check a live TLS host or pasted PEM chain for broken issuer links, hostname and expiry problems, then build a root-aware install bundle.
Certificate Inventory Expiry Checker Review a certificate inventory CSV locally to rank renewal urgency and flag ownership, manual-process, invalid-date and public-lifetime risks.
Certificate Transparency Checker Check an exact TLS certificate fingerprint against public CT data and compare hostname coverage, issuer evidence and provider revocation flags.

A certificate signing request (CSR) is the handoff between a key owner and a certificate authority (CA). It contains a public key, a subject name, optional requested attributes and extensions, and a signature made with the matching private key. The request can be shared with an issuer; the private key must remain with the key owner.

That signature proves that the request was created by someone holding the corresponding private key. It does not prove control of a domain, permission to request a certificate, or acceptance by the CA. The issuer performs its own validation and decides which subject fields, extensions, validity dates, and policies appear in the final certificate.

TermMeaningDecision to make before issuance
Common nameThe primary subject identity in the requestDo not rely on it alone for normal TLS service identity.
Subject Alternative Name (SAN)A requested DNS name or IP address identityList every name or literal address clients will use.
Key usageRequested cryptographic operations for the keyChoose only the operations the certificate is intended to support.
Extended key usageRequested application purpose such as TLS server or client authenticationMatch the issuer’s profile and deployment role.

Service identity mistakes are expensive because a perfectly valid key pair can still name the wrong endpoint. Include the exact hostnames and IP addresses used by clients, check wildcard scope carefully, and inspect the finished CSR before submission. A wildcard such as *.example.com is not a substitute for every deeper name under that domain.

Key custody is the harder boundary. Losing the private key makes the request unusable for deployment; exposing it allows another party to impersonate the certificate holder after issuance. Generate and store the key in a trusted browser and move it promptly into the intended server or secret-management workflow.

How to Use This Tool:

Start with the identities the certificate must cover, then choose cryptographic and extension settings that match the issuer’s policy.

  1. Enter the primary DNS name, wildcard name, IPv4 address, or IPv6 address in Common name. Add every client-facing DNS name and IP address to Subject alternative names.
  2. Keep Include the common name as a SAN on unless the issuing workflow deliberately manages SANs another way. Duplicate names are removed.
  3. Choose an RSA size and signature digest. The 2048-bit, SHA-256 defaults provide the broad compatibility baseline; use larger keys or digests only when policy requires them.
  4. Open Advanced to request a TLS server, TLS client, dual-use, or custom key-usage profile. Add optional subject fields only when the CA or internal policy expects them.
  5. Choose whether to encrypt the exported PKCS#8 private key. An encrypted export requires matching passphrases of at least eight characters.
  6. Generate the CSR, inspect the SANs, public-key fingerprint, requested usages, and PEM boundaries, then submit only the CSR to the issuer.

Interpreting Results:

The CSR PEM is the shareable request. The private-key PEM is the secret that must stay with the deployment owner. A matching SubjectPublicKeyInfo (SPKI) SHA-256 fingerprint helps identify the generated public key, but it does not validate the requested names or predict what the issuer will approve.

  • Confirm that every required identity appears as a DNS or IP SAN.
  • Check the RSA size, signature digest, key usage, and extended key usage against the CA profile.
  • Use the request ledger or OpenSSL inspection to catch accidental subject fields before submission.
  • After issuance, inspect the certificate again. A CA may ignore, replace, or narrow requested extensions.

Technical Details:

PKCS #10 wraps a versioned request-information structure, a signature algorithm identifier, and a signature. The request-information structure contains the subject distinguished name, SubjectPublicKeyInfo, and an attribute set. Requested X.509 extensions are carried inside an extension-request attribute rather than becoming certificate extensions automatically.

Request Construction Core

StageExact artifactPurpose
1RSA key pairProduces a public key for the request and a private key for signing.
2CertificationRequestInfoCombines version 0, subject, public key, and optional attributes.
3DER-encoded request informationCreates the exact byte sequence covered by the signature.
4RSASSA-PKCS1-v1_5 signatureSigns the request information with SHA-256, SHA-384, or SHA-512.
5PKCS #10 request in PEMPackages the request information, algorithm identifier, and signature for handoff.

RSA keys use public exponent 65537 and one of three modulus sizes: 2048, 3072, or 4096 bits. The signature is PKCS #1 v1.5 with the selected SHA-2 digest. The generated request is DER encoded, then written between BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST PEM boundaries.

Identity and Extension Rules

DNS names are lowercased and must contain at least one dot. A wildcard is accepted only as the leading *. label. IPv4 octets must each be 0 to 255, and IPv6 input is expanded to eight hexadecimal groups for encoding. SAN entries are split on commas or new lines and deduplicated by identity type and value.

ProfileKey usage requestExtended key usage request
NoneNoneNone
TLS serverDigital signature, key enciphermentServer authentication
TLS clientDigital signatureClient authentication
TLS server and clientDigital signature, key enciphermentServer and client authentication
CustomSelected digital signature, key encipherment, data encipherment, and key agreement flagsSelected server and client authentication flags

Requested key usage is encoded as a critical extension. Requested SAN and extended key usage are not marked critical. The neutral profile requests no usage extensions. A CA can enforce a different profile regardless of the request.

Private-Key Export

An unencrypted key is exported as PKCS#8 PRIVATE KEY PEM. Passphrase protection uses PBES2 with PBKDF2-HMAC-SHA256, a 16-byte random salt, 100,000 iterations, AES-256-CBC, and a 16-byte random initialization vector; the result is an ENCRYPTED PRIVATE KEY PEM. Encryption protects the saved file, but the passphrase must be stored separately and cannot be recovered here.

Privacy and Key Safety:

Key generation, CSR assembly, signing, and private-key encryption happen in the current browser; the request fields and key material are not sent to a server for generation. A secure browser context with Web Crypto support is required.

  • Never upload or paste the private key into a CA portal, ticket, chat, or email.
  • Download the key once, move it to its protected destination, and remove stray copies.
  • Do not use the non-operational example preview as real request material.
  • Changing request or passphrase inputs invalidates the previously generated package; generate a new matched pair.

Worked Examples:

One service with DNS and IP identities

For api.example.net reached by both name and 203.0.113.10, enter the DNS name as the common name and list both values as SANs. The normalized request contains one DNS SAN and one IP SAN; the common-name option does not create a duplicate.

TLS server request with protected key export

Selecting the TLS server profile requests digital signature, key encipherment, and server authentication. Enabling encrypted export with matching passphrases produces an encrypted PKCS#8 key, but the CA still decides whether those requested usages appear in the certificate.

References: