About CertKit

Why this exists

Converting a PFX, decoding a CSR or checking whether a key matches a certificate are small, routine jobs — the kind that should take seconds. Yet almost every free tool online asks you to paste or upload the exact files you are trying to protect. CertKit takes the other position: the tools are static pages, all processing happens in your browser, and the claims are verifiable with DevTools.

Principles

• Local by default. No upload, no server, no storage.
• Honest limits. v1 is RSA-first; EC/Ed25519 objects are reported as unsupported rather than mishandled, and the PEM → PFX writer documents its SHA-1 MAC and unencrypted certificate bags instead of hiding them.
• No business model aimed at your data. No ads, no tracking, no accounts. A single affiliate slot exists in the configuration for a possible future certificate-provider partner; it is unused in v1 and labeled as such.
• Tested, not vibes. Every claim on this site has a fixture and a test behind it, run against OpenSSL ground truth where possible.

How it is built

Static pages (Astro), zero backend, and one vendored crypto/ASN.1 library — node-forge 1.4.0 — served from this domain. No CDNs, no third-party scripts, no fonts fetched from anywhere. The test suite runs the same code in Node and in a real headless browser, with PKCS#12, PEM, DER and JWK fixtures generated by OpenSSL and checked back against it.

What’s next

EC/Ed25519 support, batch mode and offline/desktop packaging are on theroadmap. The direction is deliberately conservative: every new capability ships only when it is proven and documented as honestly as the current ones.

Project location: Kolkata, India. Built and maintained as an independent, privacy-first utility.