Example data table
| Purpose | Common Name | SAN examples | Suggested key | Validity |
|---|---|---|---|---|
| Local development | localhost | DNS:localhost · IP:127.0.0.1 · IP:::1 | RSA 2048 or P-256 | 90 days |
| API testing | api.example.test | DNS:api.example.test | RSA 2048 | 90 days |
| Internal CA | Example Root CA | Usually none | RSA 4096 | 3650 days |
Formula used
Certificate validity ends after the selected number of days. SHA fingerprints hash encoded certificate bytes for comparison. Public key fingerprints hash the exported SubjectPublicKeyInfo data.
How to use this calculator
Choose a generation or decoding mode first. Enter the certificate identity fields you need. Add every hostname inside Subject Alternative Names. Select a modern key type and digest. Configure usages for your intended certificate purpose. Add a private key passphrase when required. Then generate the requested certificate or signing request.
Use the localhost preset for development servers. It adds common loopback names automatically. Copy generated PEM blocks when configuring servers. Download files when another application needs them. Keep every private key secret and protected. Never paste production private keys into untrusted websites. Decoder modes inspect existing certificates without generating replacements.
SSL/TLS certificate guide
TLS certificates connect public keys with named identities. Browsers inspect certificate chains during secure HTTPS connections. A private key proves control of that identity. The private key must remain confidential at all times.
A certificate signing request contains identity information. It also contains the matching public key. Certificate Authorities verify requests before issuing trusted certificates. Self-signed certificates instead sign themselves using local keys.
Subject Alternative Names identify valid hostnames and addresses. Modern clients normally check these names during connections. The Common Name remains useful for readable identity. However SAN coverage is essential for typical HTTPS certificates.
RSA remains widely compatible across many environments. ECDSA provides smaller keys with strong modern security. P-256 is a common ECDSA choice today. RSA 2048 remains a practical compatibility baseline.
Certificate validity defines the accepted lifetime window. Shorter periods can reduce exposure after key compromise. Public certificates often use automated renewal workflows. Internal certificates may use different operational policies.
Key Usage limits broad cryptographic certificate purposes. Extended Key Usage adds more specific application purposes. Server Authentication commonly appears on HTTPS server certificates. Client Authentication supports certificate based client identity checks.
Root CA certificates establish a local trust anchor. Intermediate CAs separate daily signing from root keys. Protect CA private keys with especially strong controls. Compromised CA keys can undermine every issued certificate.
Fingerprints are hashes used for exact certificate comparison. SHA-256 is the preferred fingerprint here. SHA-1 appears only for compatibility and reference. It should not guide modern signature security choices.
PEM stores Base64 data between readable header lines. DER stores the same structures in binary form. PKCS#12 can package certificates with private keys. Protect PKCS#12 files using strong unique passphrases.
Public browsers do not automatically trust self-signed certificates. They require a recognized trust chain instead. ACME services can automate trusted certificate issuance. Use self-signed certificates mainly for controlled development environments.
Server configuration examples
Apache
SSLEngine on SSLCertificateFile /path/to/certificate.pem SSLCertificateKeyFile /path/to/private-key.pem
Nginx
ssl_certificate /path/to/certificate.pem; ssl_certificate_key /path/to/private-key.pem;
Node.js
https.createServer({
cert: fs.readFileSync('certificate.pem'),
key: fs.readFileSync('private-key.pem')
}, app);