Skip to content

Multi-CA Design

Designing a Multi-CA Infrastructure

In enterprise environments, a single Certificate Authority (CA) often becomes a single point of failure, scalability bottleneck, or risk for mismanagement. A multi-CA infrastructure mitigates these risks by segmenting responsibilities, enforcing granular access controls, and aligning certificate lifecycle policies with organizational needs. This section outlines best practices for structuring a multi-CA PKI, including segmentation strategies, access control mechanisms, and certificate lifetime management.

Segmentation and CA Hierarchy Design

A multi-CA architecture should segment CAs based on trust boundaries, use cases, or organizational units (OUs). Common segmentation strategies include:

  1. Root CA Segmentation
  2. Maintain a Root CA for critical internal services (e.g., internal APIs, internal DNS) with strict access controls.

  3. Example: A dedicated Root CA for internal PKI, never exposed to external networks.

  4. Intermediate CA Hierarchy

  5. Use Intermediate CAs to issue certificates for specific domains or services. For example:
    • Internal CA: Issues certificates for internal applications.
      External CA: Issues certificates for public-facing services (e.g., HTTPS, SaaS integrations).

  6. Example: A sub-CA for a specific department (e.g., finance-ca) to issue certificates for financial systems.

  7. Sub-CA for Delegation

  8. Delegate certificate issuance to sub-CAs for localized management. For instance, a sub-CA for a regional office can issue certificates for local resources without requiring access to the root CA.

Diagram:

graph TD
    RootCA --> IntermediateCA1
    RootCA --> IntermediateCA2
    IntermediateCA1 --> SubCA1
    IntermediateCA1 --> SubCA2
    IntermediateCA2 --> SubCA3
    SubCA1 --> {Certificates for internal apps}
    SubCA2 --> {Certificates for public APIs}
    SubCA3 --> {Certificates for regional systems}

Access Control and Policy Enforcement

A multi-CA infrastructure must enforce strict access control to prevent unauthorized certificate issuance or tampering. Key practices include:

  1. Role-Based Access Control (RBAC)

  2. Restrict CA administrators to specific segments. For example:

    • internal-ca-admin can only issue certificates for internal services.
    • external-ca-admin can only manage public-facing certificates.

  3. Certificate Policy Enforcement

  4. Define policies for each CA, such as:
    • Validity periods (e.g., 1 year for public-facing certs, 5 years for internal certs).
    • Allowed key usages (e.g., digitalSignature, keyAgreement).

  5. Use tools like Keycloak or HashiCorp Vault to enforce policy constraints during certificate issuance.

  6. Audit and Monitoring

  7. Log all CA operations (e.g., certificate issuance, revocation) and monitor for anomalies.
  8. Example: Use ELK Stack or Prometheus/Grafana to visualize CA activity.

Example Command:

# Enforce a 1-year validity period for certificates issued by the external CA
openssl req -new -key private.key -out request.csr -config <(cat <<EOF
[req]
req_extensions = req_ext
distinguished_name = req_distinguished_name

[req_distinguished_name]
commonName = example.com

[req_ext]
keyUsage = digitalSignature, keyAgreement
extendedKeyUsage = serverAuth, clientAuth
notBefore = 20240101000000Z
notAfter = 20250101000000Z
EOF
)

Certificate Lifetime and Revocation Policies

A multi-CA infrastructure must align certificate validity periods and revocation mechanisms with risk profiles. Best practices include:

  1. Validity Periods
  2. Shorter lifetimes for high-risk certificates (e.g., 3–6 months for public-facing certs).
  3. Longer lifetimes for internal certificates (e.g., 1–5 years).

  4. Example: Use OCSP stapling to reduce latency for revocation checks.

  5. Revocation Mechanisms

  6. Implement CRLs (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol) for real-time revocation.

  7. Example: Configure an OCSP responder for each CA:

    # Example OCSP responder configuration (Apache mod_ssl)
SSLUseStapling on
SSLStaplingFile /etc/ocsp/ocsp_response.der
SSLStaplingResponderTimeout 5
SSLStaplingReturnZeroOnNoCas on

  8. Automated Renewal and Revocation

  9. Use tools like Certbot or ACME clients to automate certificate renewal.
  10. Integrate with HashiCorp Vault for automatic revocation of compromised certificates.

Key takeaways

  • Segment CAs by trust boundaries (e.g., internal vs. external) to reduce attack surfaces.
  • Enforce RBAC and policy constraints to prevent unauthorized certificate issuance.
  • Align validity periods and revocation mechanisms with risk profiles and operational needs.
  • Automate renewal and monitoring to ensure compliance and reduce manual overhead.
  • Document and audit CA operations to maintain accountability and detect anomalies.