Client-Side Crypto Tools for CSR, Hash and Password Work: A KaliLinux.net Lab Guide

Every security course repeats the same rule: never let your private key leave your control. Yet plenty of people still paste certificate requests, passwords and secrets into random web tools. The good news is that modern browsers can do real cryptography locally, so a well-built web tool can be as safe as a command-line one. The trick is knowing which tools work that way and how to verify the claim yourself.

This guide uses Indomaret.org , a free collection of 294 tools with no sign-up, as a worked example, and cross-checks everything with standard Kali Linux tooling.

Server-side vs client-side: where the secret lives

A server-side CSR generator receives your domain details, creates a key pair on its own machine and sends both back. Even if the operator is honest, your private key was generated and held — however briefly — on hardware you do not control. Logs, backups or a compromised server can expose it.

A client-side generator does the same job inside your browser tab. The key pair is created by the Web Crypto API (crypto.subtle.generateKey), the CSR is assembled and signed locally, and nothing is transmitted. The CSR and private key generator on Indomaret.org works this way: it builds a PKCS#10 request with Web Crypto and its output is tested against openssl req -verify.

Verify the claim with DevTools

“Runs in your browser” is a claim, not a guarantee. Test it:

1. Open the tool page and press F12, then go to the Network tab.
2. Clear the request list.
3. Enter test data and run the tool.
4. Inspect every new request. You should see no POST or fetch carrying your input. At most, the page loads its own JavaScript or WebAssembly files.

For extra assurance, disconnect from the network after the page has loaded and run the tool again. A genuinely client-side tool keeps working.

Verify the output with openssl

Never trust an artifact you have not checked. For a CSR saved as request.csr:

openssl req -in request.csr -noout -verify -text | head -20

verify OK confirms the request is correctly signed by the matching private key. To confirm a key and CSR belong together, compare their public key moduli:

openssl req -in request.csr -noout -pubkey | sha256sum
openssl pkey -in private.key -pubout | sha256sum

Identical hashes mean they match. For string hashes, compare the web output with printf '%s' 'text' | sha256sum — note printf instead of echo to avoid a trailing newline changing the result.

When a server is unavoidable

Some checks cannot run client-side because browsers cannot open raw sockets to arbitrary hosts. Certificate checks, DNS lookups and port tests need a server to make the connection. That is fine, because the data involved is public. What matters is how the service behaves: the SSL checker on Indomaret.org states that it uses its server to contact the address you enter and stores nothing, and the site’s network tools refuse private and local addresses to prevent server-side request forgery.

Lab exercise

Try this in your Kali lab to build the habit:

1. Generate a CSR in a client-side web tool for a test domain you own.
2. Generate a second CSR with openssl in Kali.
3. Verify both with openssl req -verify and compare their subject fields.
4. Watch DevTools during step 1 and document that no request carried the key.
5. Delete the test keys when you are done.

Convenience and security are not opposites. A browser tool built on Web Crypto, verified with DevTools and cross-checked in Kali, is a perfectly defensible part of a security workflow.