| Field | Value | Copy |
|---|---|---|
| {{ r.k }} | {{ r.v }} | |
| No data. | ||
A certificate signing request, or CSR, is the package you send to a certificate authority when you want a certificate bound to a freshly generated public key and a defined subject identity. It carries the public key, the subject fields you entered, and a signature proving that the request was created by the matching private key. This generator builds that bundle in the browser and keeps the key material local to the page session.
The tool is designed for the common TLS workflow: choose a common name, add subject alternative names when the certificate must cover more than one hostname or IP, pick an RSA key size and digest, and then export the CSR and private key as PEM text. It also computes an SPKI SHA-256 fingerprint, can encrypt the private key before export, and produces an OpenSSL configuration template that mirrors the entered values.
That makes it useful when you are preparing a server certificate request, replacing a certificate with a wider SAN set, generating a lab request without leaving the browser, or creating a clean handoff bundle for an operations ticket. The page is especially handy when you want the request, the private key, the summary table, and the OpenSSL equivalent all derived from the same inputs instead of assembled manually in several tools.
A valid CSR is still not the same thing as an issued certificate. The request proves possession of the private key that signed it, but it does not by itself prove control of the domain or IP, and it does not guarantee that a certificate authority will honor every requested extension. The page therefore works best as a request-construction and export aid, not as a substitute for CA validation policy.
Security expectations are equally important. The bundle stays local, but it depends on a secure browser context and on you handling the exported private key responsibly. If the key is generated on an untrusted machine or the PEM files are stored carelessly, the fact that the CSR is formally correct will not protect the deployment.
Start with the Common Name (CN) only when the certificate will be used for a single host and you already know the exact identifier you need. The validator accepts ordinary hostnames, leftmost-label wildcards such as *.example.com, IPv4 literals, and IPv6 literals. For most modern TLS deployments, however, the more important field is the SAN list because clients increasingly rely on SAN entries rather than the CN for hostname matching.
If the certificate needs to cover more than one name, treat the SAN list as the authoritative set. The package parses comma-separated DNS and IP entries, validates them one by one, and can auto-add the CN into SAN when the SAN list is empty. That behavior is useful for simple single-name requests, but it does not hide the difference between a one-name certificate and a certificate that explicitly covers several alternate names.
The organization fields are optional for the bundle, but they change the request contents in meaningful ways. Country, state or province, locality, organization, organizational unit, and email are all added to the distinguished name only when supplied. That is a good fit for private PKI and some internal approval flows. For many public DV workflows, however, only the names and key material may matter operationally.
Key Size and Digest are the main cryptographic choices exposed in the UI. The page supports RSA 2048, 3072, and 4096 bit generation, plus SHA-256, SHA-384, and SHA-512 for the CSR signature. Larger keys give you more cryptographic margin at the cost of more CPU and bigger artifacts. In routine server work, 2048 or 3072 bits with SHA-256 remains the most practical baseline.
The private-key encryption switch deserves deliberate use. Leaving it off gives you an unencrypted PKCS #8 key that is easy to deploy but sensitive at rest. Turning it on wraps the exported key with passphrase-based encryption and adds a second passphrase check in the UI. That is safer for storage and transport, but it also means the passphrase has to be preserved accurately for the key to remain usable later.
| Need | Best place to look | Why it helps |
|---|---|---|
| Quick sanity check before submission | Info tab | Lists the subject fields, SAN set, key size, digest, and SPKI hash in one review table. |
| Copy or save the actual request | CSR tab | Exposes the PEM-encoded certificate request block for copy or download. |
| Keep the matching private key | Private Key tab | Shows the generated PKCS #8 key in plain or encrypted PEM form. |
| Mirror the same setup in shell tooling | OpenSSL tab | Provides the command and configuration text derived from the same inputs. |
The page requires a secure browser context because the key generation path depends on Web Crypto. When that condition is met, the bundle generates an RSA key pair with RSASSA-PKCS1-v1_5, exports the public key as SPKI, exports the private key as PKCS #8, hashes the SPKI with SHA-256 for the displayed fingerprint, and then signs the CertificationRequestInfo structure with the selected digest. If the page is not loaded in a secure context, generation is blocked rather than silently downgraded.
The CSR body is assembled directly in code with ASN.1 helpers. The distinguished name can include C, ST, L, O, OU, email address, and common name, each only when present. Optional attributes are then wrapped into the request, including an extensionRequest attribute for SAN, Key Usage, and Extended Key Usage, and a challengePassword attribute when the user supplies one.
SAN handling is careful about type. DNS names are encoded as dNSName values, while literal IPv4 and IPv6 entries are encoded as IP address octet strings. Key Usage becomes a critical extension when present, and Extended Key Usage currently supports the usual serverAuth and clientAuth values. Those are request hints. A certificate authority or internal issuer can ignore them, replace them, or reject them depending on policy.
Private-key encryption uses PBES2 with PBKDF2-HMAC-SHA-256 and AES-256-CBC. The code generates a random salt and IV, uses 100000 PBKDF2 iterations, derives the AES key from the entered passphrase, encrypts the PKCS #8 bytes, and then wraps the result as an ENCRYPTED PRIVATE KEY PEM block. If encryption is disabled, the page exports an ordinary unencrypted PKCS #8 PRIVATE KEY block instead.
| Artifact | What the package generates | What it does not guarantee |
|---|---|---|
| CSR PEM | A PKCS #10 certificate request signed by the matching private key. | Certificate issuance or domain control approval. |
| Private key PEM | A fresh RSA private key in PKCS #8 form, plain or encrypted. | Safe long-term storage or deployment discipline. |
| SPKI SHA-256 | A hash of the exported public-key structure. | Hostname coverage, trust chain validity, or certificate status. |
| OpenSSL config | A text template that mirrors the entered subject and extension values. | Exact parity with every CA workflow or local OpenSSL default. |
The output surface is broad. The info table can be copied or exported as CSV or DOCX. CSR PEM and private-key PEM can each be copied or downloaded directly. The JSON tab preserves the inputs plus the generated PEM blocks and fingerprint, while the OpenSSL tab can copy the equivalent command line and download a configuration file. No network requests are made by the generator itself, and there is no tool-specific server helper in the bundle.
The operational limits are important. RSA is the only key family generated here, wildcard validation is limited to the leftmost label, and the page treats SAN auto-add as a convenience only when the SAN list is otherwise empty. If your issuance flow needs elliptic-curve keys, CA-specific extensions, or policy OIDs beyond the shipped set, you still need another tool or a manual step.
The first interpretation check is name coverage, not cryptographic size. If the SAN list does not reflect every hostname or IP the certificate must cover, the CSR may be perfectly formed and still be operationally wrong. That is why the summary table and SAN count badge matter more than the presence of a fingerprint or a successful generation message.
The SPKI SHA-256 value is a convenient public-key identifier, especially when you later need to compare a CSR, key, or certificate by public-key material. It should not be mistaken for a certificate-trust result. Two objects can share the same SPKI hash and still differ in subject names, issuer, validity period, or revocation state.
Requested KU and EKU values are best treated as hints to the issuer. Public CAs and many internal PKI systems impose their own extension policy regardless of what the CSR asks for. If the final certificate needs a particular extension profile, the CSR is only one part of that process.
Private-key encryption should also be interpreted carefully. An encrypted PKCS #8 block is safer for storage than a plain one, but it shifts operational risk toward passphrase handling. Losing the passphrase can be just as fatal to deployment as losing the key itself.
An operator needs a certificate only for example.com. The page can generate a fresh RSA key, auto-populate SAN from the CN when the SAN field is empty, and export the CSR and key together as a compact request bundle.
A service answers on example.com, www.example.com, and an IP literal for testing. Entering all three as SAN values makes the intended coverage explicit instead of relying on one CN plus assumptions.
A team wants the request prepared on one machine and enrolled later from another process. Generating the CSR locally, encrypting the PKCS #8 key, and exporting the OpenSSL config keeps the request details consistent across both steps.
No. It proves only that the request was signed by the matching private key. Domain or IP control still has to be validated by the issuing authority.
That is risky for modern TLS use. The SAN list is the safer place to express every intended hostname or IP.
No. Generation and export happen in the browser, and the bundle does not ship a network request path for CSR creation.
Because Web Crypto key generation requires a secure context, except for localhost-style development exceptions.
Yes. Requested SAN, KU, and EKU values are part of the CSR, but issuance policy still belongs to the CA or internal PKI.