Certificate Authority Generator Online
Generate complete PKI certificate chains for testing - Root CA, Intermediate CA, and Server Certificates
Output will appear here
Enter a hostname and click "Generate CA Authority" to create your certificate chain
Certificates for:
Support This Free Tool
Every coffee helps keep the servers running. Every book sale funds the next tool I'm dreaming up. You're not just supporting a site — you're helping me build what developers actually need.
Understanding Public Key Infrastructure (PKI)
What is PKI?
Public Key Infrastructure (PKI) is a comprehensive framework that manages digital certificates and public-key encryption. It provides the foundation for secure communication, authentication, and data integrity across the internet. PKI enables organizations to:
Encrypt Data
Protect sensitive information in transitAuthenticate Identity
Verify users, servers, and devicesDigital Signatures
Ensure data integrity and non-repudiationCore PKI Components
The trusted entity that issues and manages digital certificates. CAs verify the identity of certificate requesters before issuing certificates.
- Root CA: Top of trust hierarchy, self-signed
- Intermediate CA: Issues end-entity certificates
- Issuing CA: Day-to-day certificate operations
Acts as an intermediary between users and the CA. The RA verifies the identity of entities requesting certificates.
- Validates identity documents
- Approves or rejects certificate requests
- Handles certificate revocation requests
An electronic document that binds a public key to an identity. Contains:
- Subject name (who the cert belongs to)
- Public key
- Issuer name (CA that signed it)
- Validity period (not before/not after)
- Serial number and extensions
Mechanisms to invalidate certificates before expiration:
- CRL: Certificate Revocation List - periodic list of revoked certs
- OCSP: Online Certificate Status Protocol - real-time status check
- OCSP Stapling: Server provides OCSP response with cert
Certificate Trust Hierarchy
PKI uses a hierarchical trust model where trust flows from the Root CA down to end-entity certificates:
Self-signed | Offline | 20+ years validity
Signed by Root | Online | 10-15 years validity
How Certificate Validation Works
When a client (browser) connects to a server over HTTPS, this validation process occurs:
Server Sends Certificate
Server presents its certificate and the intermediate CA certificate chain
Chain Building
Client builds a chain from server cert up to a trusted Root CA in its trust store
Validation Checks
Verify signatures, validity dates, hostname match, and revocation status
Secure Connection
If all checks pass, TLS handshake completes and encrypted session begins
Certificate Validation Checks
| Check | What It Verifies |
|---|---|
| Signature | Certificate was signed by the claimed issuer |
| Validity Period | Current date is within notBefore and notAfter |
| Chain of Trust | Chain leads to a trusted Root CA |
| Hostname | Certificate CN or SAN matches requested domain |
| Revocation | Certificate has not been revoked (CRL/OCSP) |
| Key Usage | Certificate is authorized for its intended use |
Common Certificate Errors
Root CA not in browser's trust store
Certificate expired or not yet valid
Certificate doesn't match the domain
Certificate has been revoked by the CA
Types of SSL/TLS Certificates
Basic validation - only proves domain ownership
- Issued in minutes
- Lowest cost (often free)
- Good for: blogs, personal sites
- Example: Let's Encrypt
Verifies organization identity and domain ownership
- Issued in 1-3 days
- Moderate cost
- Good for: business websites
- Shows org name in cert details
Strictest validation - thorough business verification
- Issued in 1-2 weeks
- Highest cost
- Good for: e-commerce, banking
- Highest trust level
PKI Best Practices - DO
- Keep Root CA offline in an air-gapped system
- Use strong key sizes (RSA 2048+ or ECC P-256+)
- Implement certificate monitoring and alerting
- Automate certificate renewal (ACME protocol)
- Use Certificate Transparency logs
- Implement HSTS and certificate pinning where appropriate
PKI Pitfalls - DON'T
- Use self-signed certs in production
- Share private keys between servers
- Disable certificate validation in code
- Use weak algorithms (MD5, SHA-1, RSA 1024)
- Ignore certificate expiration warnings
- Store private keys in version control
Certificate File Extensions Reference
| Extension | Format | Description |
|---|---|---|
.pem |
Base64 (ASCII) | Privacy-Enhanced Mail format. Base64 encoded with BEGIN/END markers. Most common format. |
.crt, .cer |
Base64 or DER | Certificate files. Can be either PEM or DER encoded. |
.der |
Binary | Distinguished Encoding Rules format. Binary encoded certificates. |
.key |
Base64 (ASCII) | Private key files in PEM format. |
.p12, .pfx |
Binary | PKCS#12 format. Contains certificate and private key, password protected. |
.p7b, .p7c |
Base64 or Binary | PKCS#7 format. Contains certificates and chain, no private keys. |
Useful OpenSSL Commands
View Certificate Details
openssl x509 -in certificate.crt -text -nooutVerify Certificate Chain
openssl verify -CAfile root-ca.crt -untrusted intermediate-ca.crt server.crtConvert PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.derCreate PKCS#12 Bundle
openssl pkcs12 -export -out bundle.p12 \
-inkey server.key -in server.crt \
-certfile intermediate-ca.crtCheck Private Key Matches Certificate
openssl x509 -noout -modulus -in server.crt | md5
openssl rsa -noout -modulus -in server.key | md5