How To Use the CSR Generator: Create an SSL Certificate Request Without Losing the Private Key
A simple step-by-step guide to generating a CSR and private key with SANs, RSA/ECDSA choices, downloads, fingerprints, and safe certificate-ordering habits.
In This Article
Start With the Domain You Actually Need To Secure
Open the CSR Generator and begin with the Common Name field. For a normal website, enter the main domain such as example.com. For a wildcard certificate, enter a name like *.example.com. Do not paste https://, a path, a query string, or a full URL. A CSR is about the identity of the host, not a page address.
ToolsMint removes common URL clutter because people often copy the address from the browser bar. We still show warnings instead of silently pretending everything is perfect, because certificate mistakes are painful later. If the Common Name is wrong, you cannot edit the CSR after the fact. You generate a new request.
The safest habit is to write the domain exactly as you plan to order the certificate, then pause and check spelling. A single missing letter can produce a certificate request that your certificate authority rejects or issues for the wrong name.
Add SANs Before You Generate
Next, add Subject Alternative Names in the SAN box, one per line. Include the www version, API subdomains, app subdomains, staging names, or IPv4 addresses if your certificate order supports them. If the main domain should also be valid, keep "Include common name in SAN list" turned on.
This is one reason the ToolsMint CSR Generator is not just a tiny form with a Generate button. Modern browsers care about SANs. The Common Name alone is not enough for real-world SSL/TLS work. That is why the tool puts SAN handling near the top instead of hiding it in an advanced drawer.
Use plain hostnames such as www.example.com and api.example.com. If you paste https://api.example.com/login, ToolsMint warns you because paths and protocols do not belong in a CSR SAN entry.
Choose the Key Preset Without Overthinking It
For most websites, RSA 2048 is the compatibility choice. It works almost everywhere and is accepted by common certificate workflows. If your organization prefers stronger RSA keys, choose RSA 3072 or RSA 4096. If your stack is modern and your certificate authority supports it, ECDSA P-256 or P-384 can be efficient for TLS.
The tool labels the presets in human language because "algorithm choice" can get unnecessarily scary. We built it so a normal website owner can choose a safe default, while a developer or sysadmin still has modern ECDSA options.
If you are unsure, use RSA 2048 unless your hosting provider, certificate authority, or internal policy says otherwise. The best key is the one your server, CDN, certificate authority, and renewal process can all handle reliably.
Generate, Then Save Both Outputs Immediately
Click Generate CSR. The CSR appears in the first output box. The matching private key appears in the private-key box. Copy or download both files before leaving the page.
This moment matters. The CSR can be shared with your certificate authority. The private key must stay secret. The certificate you receive later only works with the private key generated with this CSR. If you lose the key, you usually need to generate a new CSR and reissue the certificate.
ToolsMint runs this flow in the browser so the private key is generated locally. That is the biggest reason to use this tool over random CSR pages that process everything on a server. For something as sensitive as a private key, local generation is the cleaner default.
Use the OpenSSL Preview as a Learning Bridge
After generation, ToolsMint also shows an OpenSSL equivalent command. You do not need it if you are using the browser output, but it teaches what the tool is doing and helps teams move the same settings to a server-side workflow.
If your hosting provider asks you to generate the CSR on the server, use the OpenSSL preview as a starting point and adjust it for that environment. If your provider lets you paste a CSR, use the ToolsMint CSR output and keep the private key in a secure vault.
The fingerprint summary is there for verification habits. It gives you a stable way to record what was generated, without uploading the key or relying only on filenames like final-final-cert.key.