SSL Certificate Generator
🔒 Runs in your browser
Import workspace
Import existing CA
Save your workspace
This passphrase encrypts your workspace file (.acpki) — the only copy of your CA private key. You will need it to re-open the workspace. It is NOT the password for exported certificates or zip archives.
Encrypts the .acpki file, which holds your CA private key. Minimum 12 characters. There is no recovery if you lose it — store it safely.
| Name | Subject / CN | SANs | Expiry |
|---|
Renew an existing certificate
Paste or drop an old certificate to pre-fill this form with its subject and SANs, then Issue to re-sign it with your current CA.
Optional checks
Paste a private key to confirm it matches this certificate, or drop/paste your root CA to confirm the certificate chains to it.
Checks
Export
How to install these certificates
Only install a root CA you generated yourself, on a machine you control. Installing a root CA someone else gave you lets them intercept all your encrypted traffic — never run these trust commands on a certificate you did not create.
Trust the root CA
Windows: run certutil -addstore Root rootCA.crt from an elevated prompt, or
import through certlm.msc.
certutil -addstore Root rootCA.crt
macOS: run the security command below from Terminal, or import through
Keychain Access and set the certificate to "Always Trust".
security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain rootCA.pem
Linux: copy the certificate into the system trust anchors and refresh the CA bundle (or use
trust anchor on distributions that ship p11-kit).
sudo cp rootCA.pem /usr/local/share/ca-certificates/rootCA.crt
sudo update-ca-certificatesChrome and Edge read the operating-system trust store, so the steps above cover them too. Firefox keeps its own, separate certificate store — trusting the CA in Windows, macOS or Linux does not make Firefox trust it. Import it under Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import, and check "Trust this CA to identify websites".
Install the server certificate
nginx: point both directives at the exported files.
ssl_certificate <name>-fullchain.pem;
ssl_certificate_key <name>.key;Apache: use the certificate, key and chain files together.
SSLCertificateFile <name>.crt
SSLCertificateKeyFile <name>.key
SSLCertificateChainFile chain.pem
IIS: import the exported .pfx file directly through the IIS Manager
certificate store — it already bundles the certificate, chain and private key behind your
export password.
A note on production use
Certificates issued here are cryptographically real, but they are only privately trusted — nothing outside machines where you install the root CA will accept them, so they are not suitable for public internet-facing sites. There is no revocation mechanism, so keep leaf certificates short-lived and renew them, and remember the CA private key is only a file protected by your passphrase, not a hardware-backed key. This tool is the right fit for lab, development, staging and internal services you control end to end; for business-critical, org-wide or regulated systems, use a dedicated PKI platform with revocation and hardware-backed keys instead.
Frequently asked questions
Are the certificates and keys generated in my browser?
Yes. The RSA key pairs and every certificate are generated locally with the Web Crypto API and node-forge. No key, certificate or passphrase is ever sent to a server — this tool has no backend at all.
What is a SAN and why does it matter?
A Subject Alternative Name lists the exact hostnames and IP addresses a certificate is valid for. Modern browsers ignore the old Common Name and trust only the SAN, so a server cert must name every hostname it serves in its SAN list.
How do I make my devices trust these certificates?
Install the root CA certificate into the trust store of each machine or browser: the OS store on Windows, macOS and Linux (Chrome and Edge use it too), and Firefox keeps its own store. The install guide on this page has copy-paste commands.
How is my CA private key protected?
The workspace file is encrypted with AES-256-GCM using a key derived from your passphrase (PBKDF2-SHA-256, 210000 iterations), and each exported PKCS12 file encrypts its private key with the export password. There is no recovery if you lose the passphrase, so back up both the file and the passphrase.
Is this safe for production?
The certificates are cryptographically real and standards-compliant: once you install the root CA they work on any internal server, exactly like any private CA. But they are only privately trusted, so they are not for public internet-facing sites — use a public CA or Let’s Encrypt there. There is no revocation, so keep leaf validity short and renew; the CA key is a file protected only by your passphrase, not an HSM. Best fit is lab, dev, staging and internal services you control end to end. For business-critical, org-wide or regulated systems use a dedicated PKI (step-ca, HashiCorp Vault, Microsoft AD CS, EJBCA) with HSM-backed keys and revocation.