Getting StartedUnderstanding PKICertificate AuthoritiesIssuing CertificatesCertificate LifecycleOCSPACME ProtocolAPI AccessMCP IntegrationWorkspaces

Certificate Authorities

A Certificate Authority (CA) is the root of trust for all certificates you issue. Certman supports both root CAs and intermediate CAs, allowing you to build CA hierarchies for different environments or security requirements.

Root vs Intermediate CAs

Certman supports two types of Certificate Authorities:

  • Root CA — A self-signed CA that serves as the trust anchor. Install the root certificate on devices that need to trust your certificates.
  • Intermediate CA — A CA signed by a parent CA (root or another intermediate). Allows you to delegate certificate issuance while keeping the root key more secure.

CA Hierarchy

You can build CA hierarchies up to 3 levels deep:

Root CA (depth 0)
├── Intermediate CA 1 (depth 1)
│   └── Intermediate CA 1a (depth 2)
└── Intermediate CA 2 (depth 1)

Path Length Constraint controls how many levels of sub-CAs an intermediate can issue:

  • Unlimited — Can issue sub-CAs without restriction (recommended for root CAs)
  • 0 — Can only issue end-entity certificates, not sub-CAs (recommended for leaf intermediate CAs)
  • 1 or 2 — Can issue that many levels of sub-CAs

Creating a CA

When creating a CA, you provide:

  • CA Type — Root (self-signed) or Intermediate (signed by parent)
  • Parent CA — For intermediate CAs, select which CA will sign it
  • Common Name — A descriptive name (e.g., "Home Lab Root CA")
  • Organization — Your organization or project name
  • Organizational Unit — Department or division (e.g., "IT Department")
  • Algorithm — RSA-2048, RSA-4096, ECDSA-P256, or ECDSA-P384
  • Validity — How long the CA certificate is valid (intermediate cannot exceed parent)
  • Path Length — How many levels of sub-CAs this CA can issue
  • Passphrase (optional) — Protect the CA with a passphrase for zero-trust operation

Passphrase Protection (Zero-Trust Mode)

For high-security environments, you can protect your CA with a passphrase. When enabled:

  • Certman cannot issue or revoke certificates without you providing the passphrase
  • The passphrase is never stored on the server — only you know it
  • OCSP and CRL continue to work automatically (via delegated signing certificates)
  • If you forget your passphrase, the CA cannot issue new certificates

Passphrase protection is ideal for production CAs where you want to ensure that certificate issuance always requires explicit human authorization.

Private Key Storage

CA private keys are stored in standard PKCS#8 encrypted PEM format. This is the same format used by OpenSSL and most certificate tools, making it easy to export and use with other software if needed.

CA Lifecycle: Revoke → Delete

All CAs follow a consistent two-step lifecycle for decommissioning:

  1. Revoke — Marks the CA as revoked and prevents new certificate issuance
  2. Delete — Permanently removes the CA (only available after revocation)

Revoking CAs

When a CA is revoked:

  • Intermediate CAs are added to the parent CA's CRL and OCSP will report them as revoked
  • Root CAs are marked as inactive (no parent CRL exists)
  • No new certificates can be issued from the revoked CA
  • Existing certificates issued by the CA should be considered untrusted
  • CRL returns 410 Gone — clients should not trust a revoked CA's assertions
  • OCSP returns unauthorized — same reason, the CA is no longer operational

Passphrase requirements:

  • Revoking a passphrase-protected root CA requires the CA's passphrase
  • Revoking an intermediate CA with a passphrase-protected parent requires the parent's passphrase

Deleting CAs

Only root CAs can be directly deleted. Intermediate CAs are cascade deleted when their parent root CA is deleted. This ensures that revoked intermediate CAs remain in the parent's CRL until the entire hierarchy is removed.

A root CA can be deleted if:

  • The root CA is revoked
  • All child CAs (if any) are revoked
  • All certificates in the hierarchy are revoked

When you delete a root CA, all child CAs and their certificates are cascade deleted. This two-step process provides a safety buffer, reducing accidental deletions while allowing users to fully clean up and reclaim their CA limit (important for Free plan users).

Certificate Chains

When using intermediate CAs, clients need the full certificate chain to verify trust. You can download the full chain in PEM format from the CA detail page, or use the API to retrieve it programmatically.

Installing Your Root CA

After creating a CA, download the root certificate and install it on devices that need to trust your certificates:

  • macOS — Add to Keychain Access and set to "Always Trust"
  • Windows — Import into "Trusted Root Certification Authorities" store
  • Linux — Copy to /usr/local/share/ca-certificates/ and run update-ca-certificates
  • Browsers — Most use the OS trust store; Firefox has its own certificate manager