pki

Routing agent for PKI and Certificate Lifecycle Management. Delegates to Let's Encrypt, Venafi, DigiCert, cert-manager, EJBCA, and smallstep specialists. Handles PKI design, CA hierarchy, X.509 concep

SKILL.md

GitHub

PKI & Certificate Lifecycle Management

This skill covers PKI and Certificate Management. It classifies requests, points to technology-specific sibling skills, and answers cross-cutting questions about certificate strategy, CA design, and lifecycle management.

How to Approach Tasks

When you receive a request:

  1. Classify the request:

    • Tool-specific — Read the matching sibling skill
    • CA hierarchy design — Answer here with references/concepts.md
    • Certificate strategy — Answer here (public vs. private CA, short-lived vs. long-lived)
    • ACME protocol — Load references/concepts.md
    • Compliance/regulatory — Answer here with CA requirements by framework
    • Migration — Identify source and target, read both sibling skills
  2. Load context — For foundational questions, read references/concepts.md

  3. Identify technology — See routing table below

Technology Routing Table

If the request involves... Delegate to
Let's Encrypt, ACME automation, certbot, acme.sh lets-encrypt
Venafi, TLS Protect, CodeSign Protect, CyberArk Machine Identity venafi
DigiCert, CertCentral, Trust Lifecycle Manager, DigiCert ONE digicert
cert-manager, Kubernetes certificates, Issuers, ClusterIssuers cert-manager
EJBCA, Keyfactor, enterprise CA, ACME/EST/SCEP/CMP protocols ejbca
smallstep, step-ca, step CLI, internal PKI, SSH certificates smallstep

Certificate Strategy

When to Use a Public CA

Use a publicly-trusted CA (Let's Encrypt, DigiCert, etc.) for:

  • Any certificate that must be trusted by browsers, mobile devices, or external clients
  • Customer-facing APIs and web applications
  • External integrations where you cannot control the trust store

When to Use a Private/Internal CA

Use a private CA (Vault PKI, EJBCA, smallstep, internal AD CS) for:

  • Internal service-to-service TLS
  • mTLS client certificates
  • Developer/staging environments
  • Short-lived certificates for CI/CD
  • SSH host certificates and user certificates

Short-Lived vs. Long-Lived Certificates

Dimension Long-Lived (1 year) Short-Lived (≤24h)
Revocation needed? Yes (CRL/OCSP required) No (expiry is revocation)
Automation required? Recommended Mandatory
Risk on key compromise High (valid until expiry) Low (expires soon anyway)
Operational complexity Lower (less frequent renewal) Higher (constant renewal)
Emerging industry direction Declining (Let's Encrypt moving to 6-day) Growing

The industry is moving toward short-lived certificates. Let's Encrypt launched 6-day certificates in March 2025 as an opt-in, with 45-day certificates as an opt-in from May 2026.

CA Hierarchy Design

Public-Facing Services

External Root CA (DigiCert, Let's Encrypt, etc.)
  └── Their Intermediate CA (managed by CA)
        └── Your TLS certificates (90 days, automated)

Use ACME for automation. No intermediate CA management needed.

Internal Services

Offline Root CA (self-generated, air-gapped)
  └── Online Intermediate CA (Vault PKI, EJBCA, step-ca)
        ├── TLS server certificates (24-72h for mTLS, 30-90d for internal TLS)
        ├── mTLS client certificates (short-lived)
        └── SSH host/user certificates (short-lived)

Keep the Root CA offline. If the online intermediate is compromised, revoke the intermediate cert from the root (offline), re-issue a new intermediate.

Enterprise / Regulated

Internal Root CA (HSM-backed, air-gapped)
  ├── Issuing CA for Infrastructure (Vault PKI / EJBCA / AD CS)
  │     ├── Server TLS
  │     └── mTLS client certs
  ├── Issuing CA for Code Signing (air-gapped)
  │     └── Code signing certificates
  └── Issuing CA for Email (S/MIME)
        └── User email certificates

Certificate Automation Approaches

ACME (Automated Certificate Management Environment)

ACME (RFC 8555) is the standard for automated certificate issuance and renewal. Supported by:

  • Let's Encrypt (free, public)
  • ZeroSSL (free, public)
  • Google Trust Services (free, public)
  • Vault PKI engine (internal)
  • EJBCA (internal)
  • step-ca (internal)
  • DigiCert, Sectigo (paid, ACME support)

ACME clients:

  • certbot — The reference implementation, widely supported
  • acme.sh — Bash-based, lightweight, broad DNS provider support
  • cert-manager — Kubernetes-native, integrates with ACME
  • Caddy — Built-in ACME, automatic HTTPS
  • Traefik — Built-in ACME
  • step CLI — CLI with built-in ACME client

cert-manager (Kubernetes)

The standard for certificate management in Kubernetes. Supports multiple issuers:

  • ACME (Let's Encrypt, ZeroSSL)
  • Vault PKI
  • Venafi
  • AWS Private CA
  • Self-signed
  • Custom CA

See cert-manager for complete guidance.

Venafi / DigiCert TLM (Enterprise CLM)

For large enterprises requiring:

  • Visibility across all certificates (discovery)
  • Policy enforcement (no weak keys, expiry limits)
  • Workflow approvals
  • Multi-CA support
  • Compliance reporting

Certificate Discovery and Inventory

Before automating, discover your existing certificate estate:

Methods:

  • CT log scanning: crt.sh, Censys, Shodan for internet-facing certs
  • Network scanning: Nmap/Masscan with TLS negotiation, Qualys SSL Labs
  • Active Directory: AD CS enrollment records
  • Venafi/DigiCert TLM: Continuous discovery agents

Why it matters: Organizations typically have 2-5x more certificates than they track. Undiscovered expiring certs cause outages.

Compliance Requirements

PCI-DSS

  • Minimum TLS 1.2 for cardholder data transmission
  • 2048-bit RSA or 256-bit EC minimum
  • Certificate expiry monitoring required
  • No expired or self-signed certs for external services

FIPS 140-3

  • RSA 2048/3072/4096 with SHA-2
  • ECDSA P-256/P-384/P-521
  • No MD5, SHA-1, or RSA-1024

CA/Browser Forum (Public CAs)

  • Maximum 398 days for publicly-trusted TLS certificates (enforced since 2020)
  • SAN required (CN deprecated for hostname)
  • CAA DNS records checked at issuance
  • CT log submission required
  • OCSP stapling recommended
  • Moving toward 90-day maximum (2024 ballot), and Apple/Google pushing shorter

US Federal / FedRAMP

  • FIPS 140-3 Level 1+ for software, Level 3 for HSM
  • Common Access Card (CAC) / PIV compliance for user certs
  • Certificate Policy (CP) and Certification Practice Statement (CPS) required
  • Federal PKI bridge cross-certification for some use cases

Reference Files

  • references/concepts.md — PKI fundamentals: X.509 certificate structure, certificate chains, CRL/OCSP, CT logs, ACME protocol detail, challenge types, rate limits. Load for foundational questions.