8. Private PKI

Run your own Certificate Authority for internal names, IPs, and mTLS.

Public Certificate Authorities can only issue for publicly resolvable domain names that you prove control over. Private PKI lets you create Certificate Authorities inside CertKit and issue certificates that public CAs cannot: internal hostnames, IP addresses, client-authentication (mTLS) certificates, and lifetimes far beyond public CA limits.

Certificates issued from a private CA flow through the same path as your public certificates — the same renewal engine, the same agent deployments, the same Keystore support, and the same alerting. The only thing that changes is who signs them.

When to use a private CA

  • Internal hostnames — db01.corp.local, single-label names, and internal DNS zones that no public CA will issue for.
  • IP address SANs — certificates for services addressed by IP, including RFC 1918 addresses.
  • Mutual TLS (mTLS) — client-authentication certificates for service-to-service and device authentication.
  • Longer lifetimes — up to 825 days, while public certificate lifetimes continue to shrink.
  • No external dependency — issuance does not touch DNS validation, ACME rate limits, or a third-party CA.

Hierarchy

When you create a CA, you choose one of three hierarchy modes:

Mode Structure When to use it
Root + Issuing CA CertKit creates a root CA and one issuing CA beneath it. Certificates are signed by the issuing CA. The default. The issuing CA can be rotated without touching the trust store on any device, because devices trust the root.
Bring your own root CertKit operates a subordinate CA chained to your existing enterprise root. Your devices already trust your root, so no trust rollout is needed at all. See Bring Your Own Root.
Root only A single root CA signs certificates directly. Simpler, but replacing the CA later means updating the trust store on every device.

Creating a CA

Private CAs are managed under Settings → Private Certificate Authorities. Creating one requires:

  • Name — embedded in the CA’s subject and shown as the issuer of every certificate it signs. Choose something you are comfortable displaying to anyone who inspects a certificate.
  • Key algorithm — EC384 is the default and recommended choice for CA keys. EC256, RSA2048, and RSA4096 are also available; choose RSA4096 if you need maximum compatibility with legacy clients.
  • Name constraints (optional) — restrict the DNS namespace and IP ranges the CA is permitted to issue for. See Name Constraints.

Accounts can create up to 5 private CAs.

Certificate profiles

CertKit issues certificates with standards-conformant X.509 profiles:

  Root CA Issuing CA Issued certificate
Validity 10 years 5 years 90, 365 (default), 730, or 825 days
Basic constraints CA, critical CA, path length 0, critical End entity, critical
Key usage Certificate and CRL signing Certificate and CRL signing Digital signature (+ key encipherment for RSA)

Two rules apply to every issued certificate:

  • The 825-day cap is intentional. Apple platforms reject TLS server certificates valid longer than 825 days, even when they chain to a privately installed root.
  • A certificate never outlives its CA. Lifetimes are clamped to the issuing CA’s own expiry.

Issuing certificates

Select a private CA as the Issuer when adding a certificate. Because the certificate is signed by your own CA, there is no domain validation step — no DNS challenge, no CNAME, no waiting. This is inherent to the private trust model: the CA is only trusted where you install it, so proof of domain control serves no purpose.

Private issuance unlocks options the public path cannot offer:

  • SANs may be internal names, single-label hostnames, wildcards, and IP addresses.
  • Lifetime is selectable per certificate, up to the CA’s cap.
  • Key usage — Server Authentication (default), Client Authentication (mTLS), or both.

Renewal works exactly as it does for public certificates: CertKit reissues ahead of expiry and agents pick up the new certificate on their next sync. Deployment options — agents, manual download, and the S3-compatible API — are identical.

Working with the Keystore

Private PKI works fine with the Keystore. When a Collection uses a keystore, private keys for private-CA certificates are generated on your keystore host, and CertKit signs a certificate from the resulting CSR. CertKit takes only the public key from the CSR — the subject, SANs, key usage, and lifetime always come from the certificate definition you configured, which is standard CA practice.

Issuing CA rotation

In the root + issuing hierarchy, the issuing CA is replaced automatically when it has less than roughly two and a half years remaining — the maximum certificate lifetime plus a safety margin — so no certificate is ever cut short by its CA expiring. You can also rotate on demand from the CA’s details page.

Rotation is invisible to your infrastructure: devices trust the root, which does not change, and the previous issuing CA continues to serve its revocation list until the last certificate it signed has expired.

Key custody

CA private keys are generated server-side and stored encrypted with AES-256-GCM, the same protection applied to certificate private keys and ACME account keys. Note that in the root + issuing hierarchy both keys are held by CertKit — the two-tier structure exists for rotation ergonomics, not key isolation. If your security policy requires that the root key never reside with CertKit, use Bring Your Own Root: CertKit holds only a subordinate key, and your root stays wherever it lives today.

Managed accounts

Private CAs are account-scoped. When an MSP manages a client through Managed Accounts, CAs are created in the client’s account — a parent’s CAs are never visible to, or usable by, its clients.

In this section