Select protocols, patterns, and integrations
Trust Architecture Playbook: Automation pillar
There’s rarely one right way to automate a certificate lifecycle. For many platforms and services, Trust Lifecycle Manager supports multiple viable patterns, and choosing the right one is critical. The wrong pattern for a use case can produce brittle automation: renewals that succeed but fail during installation, or deployments that work in test and fail under production conditions.
Where to start
Start with the target platform: what does it natively support? This requires an understanding of what enrollment protocols are supported, how it manages storage and binding of the certificate, what the network topology allows or restricts, how credentials are handled for automation, and the operational constraints around restarts, reloads, and clustered or active-active/active-passive configurations. For example:
A pattern that works for a standalone Linux web server is likely wrong for an F5 BIG-IP managing traffic across an active-active pair.
A pattern that works cleanly in a cloud-native environment with a programmable management plane may have no viable equivalent on a legacy appliance that supports only SCEP.
Pattern coverage
The reality of enterprise infrastructure is that it’s heterogeneous by design, by acquisition history, by organizational boundaries, and by which team owns which platform. An automation program that assumes only one-or-two patterns will work across the entire certificate estate will fail, perhaps not immediately, but progressively, as exceptions accumulate and workarounds pile up. The goal is not a universal approach, but rather to match each platform and service archetype to the most deterministic pattern available for that specific context and use case, and to govern the resulting portfolio of patterns consistently under a unified policy framework.
Trust Lifecycle Manager supports all major enrollment protocols (ACME, SCEP, EST, CMPv2, REST API), as well as agent and sensor-based (agentless) enrollments with purpose-built integrations for the platforms most often found in enterprise automation programs, including F5, NetScaler, Azure Key Vault, AWS, GCP, HashiCorp Vault, Microsoft ADCS, and Kubernetes via cert-manager. This breadth exists because no single protocol or pattern is universally correct across the enterprise certificate estate.
Supported enrollment methods
Method | Description | Best fit | Watch-outs |
|---|---|---|---|
Automated Certificate Management Environment. Standards-based, widely supported, strong fit for modern platforms and cloud-native workloads. | Ingress controllers, reverse proxies, ACME-native platforms, Kubernetes via cert-manager. | Challenge flow and credential scope must be tightly governed. Post-deploy validation required. | |
Simple Certificate Enrollment Protocol. Widely supported in device and UEM/MDM ecosystems. | Network devices, UEM/MDM platforms, legacy enterprise infrastructure. | Central profile governance must constrain distributed issuance (for example, enrollment codes). | |
Enrollment over Secure Transport. TLS-based, more secure than SCEP, increasingly supported. | Modern network appliances and infrastructure with REST-capable management planes. | Same issuance concerns as SCEP but EST supports TLS bootstrap trust; verify platform support before committing. | |
Certificate Management Protocol. Common in telecom and regulated infrastructure. | Telecom, critical infrastructure, regulated environments with existing CMP tooling. | Complex; reserve for ecosystems already standardized on CMP. | |
Direct API integration for platforms with programmable management interfaces. | CI/CD pipelines, IaC workflows, platform engineering teams. | Requires disciplined secret handling, approval gates, and pipeline observability. | |
Lightweight agent installed on the host manages issuance, installation, and renewal locally. | Windows and Linux server hosts needing local keystore management. | Requires host installation, local prerequisites, and controlled restart behavior. | |
Standalone sensor deployed to Windows, Linux, or Docker. | Load balancers, Cloud providers, Vaults. | Sensor must have network reachability to all target platforms. Connector-specific prerequisites and credentials must be maintained. | |
Request certificates through Trust Lifecycle Manager for automated distribution to target endpoints, with support for custom post-scripts. | Cloud providers, vaults, custom applications. | Requires DigiCert agents or sensors with network reachability to all target systems. | |
Ansible, Puppet, Chef, Terraform, etc. | CI/CD pipelines, IaC, Cloud workloads, DevSecOps | Private keys must never enter pipeline state. Partial runs leave services in indeterminate certificate state. Post-deploy TLS validation must be explicit. |
Deep platform integrations
Trust Lifecycle Manager provides purpose-built integrations for the most encountered platforms found in enterprise automation programs. These integrations go beyond generic protocols or API calls, they handle platform-specific configurations, credential formats, binding models, and reload behaviors natively.
Load balancers and ADCs: F5 BIG-IP, Citrix NetScaler / ADC: Native certificate and key delivery with listener binding and traffic group awareness.
Cloud platforms: Azure Key Vault, AWS Certificate Manager and CloudFront, Google Cloud Certificate Manager: Direct integration with cloud-native certificate storage and service binding.
HashiCorp Vault: Issuance and renewal through Vault PKI secrets engine with Trust Lifecycle Manager governing the profile and policy layer.
Microsoft ADCS: Integration with on-premises Active Directory Certificate Services for private-trust issuance within the Trust Lifecycle Manager governance framework.
Kubernetes: cert-manager integration using ACME, with SPIFFE/SPIRE-compatible profiles for workload identity.
Terraform and infrastructure-as-code: Provider-level integration for certificate provisioning within IaC deployment workflows.
Hinweis
For a complete list of supported integrations, see Integration guides.
Service archetypes
Archetype | Typical deployment | Validation method | Recommended pattern |
|---|---|---|---|
Windows / IIS or Linux web server | Local keystore or OS/application store on the server host. | TLS handshake, service health check, reload verification. | DigiCert agent for local issuance, installation, and renewal. |
Load balancer / ADC / appliance | Device-managed certificate store with listener bindings. | Listener presentation on all active nodes and VIPs. | Sensor-based connector or platform-native integration (F5, NetScaler). |
Cloud vault / cloud-managed endpoint | Certificate stored in a managed cloud service; consumed by dependent services. | Vault objects update plus dependent service refresh validation. | Admin web request or connector-based automation (Azure Key Vault, AWS, GCP). |
ACME consumer / cluster edge | Ingress, reverse proxy, or standards-based client rotates certificate. | Live endpoint presentation plus workload health checks. | ACME profile with approved client and platform runbook. |
CI/CD or IaC-driven provisioning | Pipeline or provider plugin creates and binds certificates during deployment. | Pipeline validation plus post-deploy endpoint checks. | REST API or Terraform / DevOps integration pattern. |
Device / UEM / protocol-native | Device or MDM ecosystem using native enrollment protocol. | Enrollment confirmation plus device health check where available. | SCEP, EST, or CMPv2 profile with central profile governance. |
Pattern selection logic
Use the following decision sequence when selecting a pattern for a new automation candidate.
 |