DigiCert CertCentral is an excellent portal for managing DigiCert-issued certificates. TigerTrust adds the layer above it — a CA-agnostic lifecycle platform that treats DigiCert as one issuer among many, plus discovery and reporting for the certs DigiCert never saw.
DigiCert is a top-tier public CA — most enterprises rightly keep them for EV, code signing, and high-assurance workloads. CertCentral is a good portal for those certificates, but not a full CLM.
DigiCert is a top-tier CA. CertCentral is its management portal, not a full CLM. Here is where the two overlap and where they don't.
| Capability | TigerTrust | DigiCert CertCentral |
|---|---|---|
DigiCert CA issuance & renewal DigiCert is authoritative for DigiCert-issued certs | ||
Multi-CA orchestration (non-DigiCert issuers) | ||
ACME protocol / Let's Encrypt | ||
Certificate discovery across the estate | ||
Kubernetes cert-manager integration | ||
SSH certificate lifecycle | ||
GraphQL API | ||
GitOps / Terraform workflows | ||
Public CA trust & compliance pedigree DigiCert operates its own public trust anchors; TigerTrust orchestrates trusted CAs but is not itself a WebTrust-audited public CA |
You do not have to leave DigiCert to gain a CLM. Most teams keep DigiCert as a preferred CA and add TigerTrust as the platform.
Add DigiCert as an issuer in TigerTrust using your existing CertCentral API key. Existing DigiCert inventory imports automatically.
Connect any other CAs in play — Sectigo, Entrust, private CAs, Let's Encrypt for lower-assurance workloads. Policy decides which cert type routes to which CA.
Point discovery at your clouds, Kubernetes clusters, and network ranges. Every certificate — DigiCert or not — appears in one inventory.
Enable ACME endpoints, cert-manager issuers, webhook renewals, and Terraform. DigiCert keeps issuing; TigerTrust keeps deploying and reporting.
No — and most teams don't. DigiCert stays as a preferred CA for EV, code signing, and high-assurance workloads. TigerTrust sits above it as the CLM plane, adding multi-CA orchestration, discovery, and reporting.
Yes. Policy in TigerTrust routes each certificate request to the appropriate CA based on hostname, environment, tags, or approver. This is one of the most common patterns customers adopt on switch-day.
TigerTrust uses the CertCentral API to enroll, retrieve, and revoke DigiCert-issued certificates. Your DigiCert contract, sub-account structure, and validation model stay intact.
Both are managed in TigerTrust as first-class citizens. CertCentral is scoped to X.509, so if you want a single platform for SSH and code signing alongside your TLS certificates, that consolidation is part of the switch.
Platform pricing is separate from what you spend on certificates. You can keep spending at DigiCert for the certs that need it, and route commodity TLS to free issuers where policy allows. Ask us for a side-by-side against your current DigiCert contract.
“We did not want to leave DigiCert for the certs that matter. We wanted a CLM around them — plus Let's Encrypt for commodity workloads and Vault for internal service mesh.”
DigiCert remains a first-class issuer — alongside every other CA teams need in a real multi-issuer estate.
The other mainstream public CA whose portal customers often outgrow the same way.
The third of the commercial-CA trio — customers evaluate all three portals against a real CLM.
The CA-agnostic CLM product that sits above DigiCert and every other issuer you use.
The buyer journey for teams unifying multi-CA estates onto a single policy plane.