Local · Client-Side · Nothing Leaves This Tab

DevCerts

One tool for the certs and keypairs a project actually needs end to end — from your first commit to a live, HTTPS-served API. Everything is generated in your browser; private keys never touch a server.

1SSH — repo access
→
2GPG — commit/release signing
→
3Code signing — app build
→
4TLS/SSL — hosting
→
5JWT — service-to-service auth

Used for: authenticating to GitHub/GitLab/servers over SSH — pushing to a repo, deploying to a box, connecting to CI runners. Works on Windows (via OpenSSH client, built into Win10+, or PuTTY), macOS, and Linux identically. Both algorithms below export the real openssh-key-v1 private key format — the same thing ssh-keygen produces, not a plain PEM wrapper.

RSA
Ed25519
Identity
Keypair ready
Fingerprint
Linux/macOS: chmod 600 the private key file, drop both in ~/.ssh/, add the public key to GitHub → Settings → SSH Keys.
Windows: put both in %USERPROFILE%\.ssh\; OpenSSH client (Win10+) reads this format natively. For PuTTY, run it through puttygen → "Load" → "Save private key" to get a .ppk.

Used for: signing git commits/tags (verified badge on GitHub), signing release tarballs, signing Debian/RPM packages. Cross-platform — GPG has native builds for Windows (Gpg4win), macOS (GPG Suite), and Linux (usually preinstalled).

Identity
Keypair ready
Key ID
↓ private-key.asc ↓ public-key.asc
Import: gpg --import private-key.asc (same command on Win/macOS/Linux once GPG is installed). For git: git config user.signingkey <keyid> then git config commit.gpgsign true.

Used for: Windows Authenticode / AppX / MSIX signing (electron-builder, MSIX Packaging Tool), and Java jar signing. Self-signed certs satisfy build tooling and stores that re-sign on ingestion (e.g. Partner Center) but are not trusted for direct/sideload distribution without importing the public cert on the target machine. macOS app signing and iOS require an Apple Developer cert instead — Apple's own CA, not self-signable.

Identity
Key & validity
PFX password
Certificate issued
Subject
Serial
Valid
↓ cert.pfx ↓ cert.pfx.base64.txt
CI: base64 file's contents → repo secret CSC_LINK; the password you entered → CSC_KEY_PASSWORD.

Used for: HTTPS on your dev box, an internal service, or as a CSR to send to a real CA (Let's Encrypt, DigiCert) for a publicly-trusted cert. Same PEM cert/key pair works on nginx, Apache, Caddy, Node/Express, IIS — the web server doesn't care what OS generated it.

Self-signed (local/dev)
CSR (for a real CA)
Identity
Key & validity
Certificate issued

Used for: RS256/ES256 JWT signing between your backend and API consumers, or verifying tokens from an auth provider. No CA, no PKI — just a keypair you control. Works with jsonwebtoken (Node), PyJWT, jose, and most JWT libraries out of the box.

Key
Keypair ready
↓ private.pem (PKCS#8) ↓ public.pem (SPKI)
Node (jsonwebtoken): jwt.sign(payload, privatePem, {algorithm:'RS256'}). Keep private.pem on the signing service only; public.pem is safe to distribute to verifiers.
Reminder: anything generated here is self-issued. It's exactly right for local dev, internal tooling, CI build signing, and pipeline plumbing — but a browser, phone, or OS will not trust it by default for public-facing traffic. For a publicly trusted TLS cert, use the CSR mode and send it to a real CA; for public app distribution, a store's re-signing (Partner Center, etc.) or a purchased cert is still what makes it trusted end-user side.