Step-CA / Smallstep → DigiCert ONE
Step-CA ↔ DigiCert ONE: integration to migration path.
Step-CA deploys alongside DigiCert ONE first, issuing only the internal estate — mTLS, mesh, SSH, device and Kubernetes workload identity — while DigiCert keeps signing every cert a browser or partner sees. Then Step-CA takes over the internal estate in cohorts, one blast radius at a time, with no flag day and no forced re-credentialing.
The honest boundary, stated up front: publicly-trusted TLS and publicly-trusted code signing are a regulatory floor a private CA cannot cross. They stay on DigiCert ONE permanently. This is a partial migration by design.
The idea
Split along the publicly-trusted boundary.
The topology that makes this zero-downtime is a hard split-trust along the publicly-trusted line: Step-CA stands up HA with an HSM-backed offline root and online intermediate, and issues every cert whose relying party is internal, while DigiCert ONE CertCentral keeps issuing every cert whose relying party is an unmodified browser, mobile OS or third party. cert-manager routes by the SAN — internal-suffix names go to the Step-CA issuer, everything else to DigiCert — so no application code knows which CA signed. The two hierarchies coexist permanently; only the internal half migrates.
The phases
Five steps. Each one reversible.
Baseline & inventory
We classify every cert as PUBLIC (stays on DigiCert), INTERNAL (target for Step-CA), or AMBIGUOUS (resolved before anything moves). Each carries its SANs, EKU set, validity, enrollment protocol, consumer fleet and key custody. Read-only.
Stand up Step-CA, no traffic
Step-CA goes live HA — at least two intermediate-signing nodes, shared PostgreSQL, audit to SIEM — with an offline root sealed on an air-gapped HSM. Its root is pushed to a canary fleet via MDM, GPO or Ansible. No production workload trusts it yet.
New internal certs from Step-CA
Every net-new internal workload, mesh namespace and SSH bastion stands up on Step-CA from day one. Existing DigiCert internal certs are untouched; CI pipelines that hit DigiCert ACME for internal names get repointed one PR at a time.
Migrate existing internal certs
Existing internal certs reissue from Step-CA cohort by cohort in increasing blast-radius order — K8s workloads, then mesh, then MDM devices, then SSH, then legacy load balancers. ACME ARI drives early renewal so fleets roll over with no operator action. DigiCert ACME stays live as the rollback target throughout.
Scoped DigiCert retirement (internal only)
Once zero DigiCert-issued internal-SAN certs remain, we retire the internal-only DigiCert ACME issuer and Automation Profile, update the CP/CPS for the new boundary, and renegotiate the contract to drop internal seats. Public TLS, code signing, S/MIME and eIDAS stay on DigiCert ONE.
Feature parity
What moves, what stays on DigiCert ONE.
| Capability | Step-CA / Smallstep | DigiCert ONE | Parity |
|---|---|---|---|
| ACME issuance | Step-CA ACME provisioner (HTTP-01 / DNS-01 / tls-alpn-01, optional EAB) | TLM Automation Profile + ACME (EAB required) | At parity |
| SCEP (MDM) | Step-CA SCEP provisioner (PSK) for Intune / Jamf | DigiCert ONE TLM SCEP via Automation Profile | At parity |
| Private CA | Step-CA offline root + online intermediate | DigiCert ONE TLM Managed PKI / private dedicated ICA SKU | At parity |
| Publicly-trusted root | None — private chain only | CertCentral issues from browser/OS-trusted roots under WebTrust | SaaS only |
| Code signing | Signing EKU possible but not OS-pinned or HSM-custody | DigiCert Software Trust Manager (Authenticode, Apple Dev ID, kernel) | SaaS only |
| Certificate inventory / discovery | Step-CA inventories itself only | DigiCert Discovery (agentless + agented scan of LBs, cloud, Java/IIS/K8s) | SaaS only |
| CT-log monitoring | Must NOT submit; you run your own watch (crt.sh / Cert Spotter / Censys) | DigiCert CT submission (Argon/Nessie/Sabre/Yeti/Oak) + vendor monitoring | SaaS only |
| HSM support | PKCS#11 (YubiHSM 2 / CloudHSM / Azure Managed HSM / GCP KMS-HSM) | DigiCert-operated HSM root custody under WebTrust | At parity |
| Short-lived certs | claims.maxTLSCertDuration 24h to 7d, revocation-free; ACME ARI | TLM low validity cap, but per-cert price penalises high churn | Partial |
| cert-manager integration | Native step-issuer external Issuer | cert-manager digicert-issuer (ACME + EAB) | At parity |
| K8s workload identity | K8sSA provisioner (ServiceAccount JWT, no shared secret) | No native equivalent | OSS only |
| SSH certs | Built-in SSH CA mode (OIDC user certs, SSHPOP renewal) | Not in the SSH-CA category | OSS only |
| Cloud instance bootstrap | AWS/Azure/GCP IID provisioners (first-boot identity) | Not offered (needs pre-provisioned EAB / out-of-band cred) | OSS only |
| Deployment & HA | Self-hosted HA (2+ intermediate nodes, shared Postgres, HSM) | Vendor-operated SaaS | Partial |
| Cost model | Compute + ops only | Per-cert / per-seat licensing | At parity |
| Compliance (WebTrust / FIPS / SOC 2) | FIPS iff HSM validated; CP/CPS + attestation are yours | Vendor WebTrust / SOC 2 / FedRAMP inherited as evidence | SaaS only |
What we're honest about
The caveats most vendors leave out.
Publicly-trusted TLS cannot move — ever
Step-CA is a private CA. No configuration makes its chain valid in unmodified Chrome, Safari or any mobile OS — browser-root inclusion is gated on multi-year WebTrust and Mozilla/Chrome/Apple/Microsoft root-programme policy. Every external TLS endpoint, B2B partner cert and mobile-default-trust certificate stays on DigiCert ONE permanently. This is a regulatory floor, not a feature gap.
Publicly-trusted code signing stays on DigiCert
Authenticode, Apple Developer ID and kernel-mode chains anchor to OS-pinned roots, and CA/Browser Forum rules have mandated FIPS 140-2 L2+ HSM custody since 2023. Step-CA-signed binaries fail SmartScreen and Gatekeeper. We disable the codeSigning EKU on every Step-CA provisioner and route all signing through DigiCert Software Trust Manager.
You now own uptime and compliance scope
Once internal certs run on Step-CA, the CA being down means internal mTLS issuance is down — there is no managed-service backstop, and short-lived certs amplify the blast radius. We run it HA across nodes and zones with a tested DR runbook. Step-CA also enters your SOC 2 / ISO 27001 scope: CP/CPS, ceremony evidence and HSM custody become your audit responsibility.
Discovery, CT monitoring and DCOM autoenrollment stay SaaS
DigiCert Discovery scans LBs, cloud and Java keystores across your whole estate; DigiCert submits and monitors CT logs; the Autoenrollment Server replaces on-prem MS-CA invisibly to AD-joined fleets. Step-CA inventories only itself, must never be CT-submitted, and has no DCOM proxy. We tell you which of these you depend on before Phase 1.
Why this beats a flag day
Reversible in minutes, retired only after a long soak.
No phase forces an outage. Each cohort cutover rolls back in under 15 minutes for cert-manager workloads because the DigiCert ACME Automation Profile is left configured, not deleted — and an internal cert class only counts as migrated after at least 30 consecutive days at full Step-CA issuance with mTLS handshake success at or above baseline. DigiCert ONE is never cancelled outright: only the internal seats retire after the soak, while public TLS, code signing, S/MIME and eIDAS stay on it indefinitely.
See how much of the internal estate migrates cleanly.
A call with a senior PKI engineer. We classify your certs as public or internal, size your HSM and trust-store distribution honestly, and tell you exactly how much you can move to Step-CA — and how much must stay on DigiCert ONE forever.
Map my migration →