Step-CA → Sectigo Certificate Manager

Step-CA ↔ Sectigo Certificate Manager: integration to migration path.

Step-CA deploys alongside Sectigo Certificate Manager first, taking only the internal estate — workload mTLS, mesh identities, SSH-CA, device and CI — while Sectigo keeps signing every publicly-trusted cert. Then internal workloads flip to Step-CA in waves against a dual-trust environment, so certs age out at their TTL with no flag day and no forced re-credentialing.

The honest boundary, stated up front: anything browser-, OS- or vendor-trust-anchored — public TLS, publicly-trusted code signing, public-web S/MIME — is a structural floor a private CA cannot cross. It stays on Sectigo permanently. This is a partial migration by design.

The idea

Two trust hierarchies, distributed together.

The topology that makes this zero-downtime is dual-trust distribution: Step-CA owns the internal CA estate with an HSM-sealed offline root signing online intermediates, and trust-manager Bundles teach every internal consumer to trust both the existing Sectigo roots and the new Step-CA root before a single internal cert is served from Step-CA. cert-manager then routes by the SAN suffix — internal names to the Step-CA ACME issuer, public names to Sectigo ACME with EAB. The two hierarchies coexist permanently; only the internal half migrates, and dual-trust means each wave needs no restart.

The phases

Six steps. Each one reversible.

0

Inventory & boundary declaration

Every cert in the estate is tagged public-trust-required (stays on Sectigo) or private-trust-acceptable (a candidate for Step-CA), captured with its SANs, EKU, key algorithm, validity, issuer, consumer system and renewal mechanism. Read-only.

Users see: No user impact.

Rollback: N/A

1

Stand up Step-CA, nothing trusts it

Step-CA goes live with an offline HSM-sealed root signing online intermediates, behind a load balancer, with ACME, JWK, OIDC, K8sSA and SCEP provisioners configured. A canary namespace can issue and validate, but no production workload trusts the new root yet.

Users see: None — Sectigo still issues every cert.

Rollback: Tear it down — nothing trusts the new root.

2

Distribute the root (trust added, not replaced)

Every internal consumer — Linux trust store, Java cacerts, mesh sidecars, MDM-managed laptops — is taught to trust BOTH the existing roots and the new Step-CA root via trust-manager Bundles and config management. No Step-CA cert is served yet; adding a root never breaks existing trust.

Users see: None — trust is added, not swapped.

Rollback: Revert the config-management commit; trust-manager re-syncs. Under 15 minutes.

3

Migrate internal workloads in waves

Private-trust-acceptable workloads flip to Step-CA in low-to-high blast-radius waves — mesh, then Envoy and cert-manager issuers, then SSH, then MDM SCEP, then CI. Because every consumer already trusts both roots, certs age out at their TTL with no restart and no re-credentialing.

Users see: None — workloads trust both roots throughout; SSH users do a one-time client install.

Rollback: Per workload: flip the issuer back to Sectigo. Under 15 minutes — dual-trust means no restart.

4

Tighten the boundary; Sectigo public stays

With the internal estate on Step-CA, we lock public DNS zones to Sectigo with CAA records and deny public issuance on internal-only zones, then enforce issuer-by-SAN at admission. Sectigo keeps owning public TLS, code signing, S/MIME and document signing.

Users see: None.

Rollback: Remove the CAA records; revert the admission policy. Under 15 minutes.

5

Optional Sectigo seat reduction

Once the internal mesh, dev and CI volume no longer flows to Sectigo, we mark internal-only Departments inactive, archive their Certificate Profiles, and renegotiate the Sectigo contract on the now-lower public-trust volume. Public TLS, code signing, S/MIME and document signing seats remain.

Users see: None.

Rollback: Reactivate the Departments and Profiles in minutes; the commercial term, once re-signed, rolls back only by contract amendment.

Feature parity

What moves, what stays on Sectigo.

CapabilityStep-CASectigo Certificate ManagerParity
ACME issuance ACME provisioner (http-01 / dns-01 / tls-alpn-01, EAB optional) SCM ACME endpoint with EAB (account→Org/Dept binding) At parity
SCEP (MDM) scep provisioner (PSK) for Intune / Jamf SCM SCEP via Device Certificate Profile At parity
Private CA Offline HSM-sealed root → online intermediates SCM private CA option alongside public hierarchy At parity
Publicly-trusted root None — private chain only Sectigo/Comodo publicly-trusted hierarchy SaaS only
Code signing Signing EKU possible, no OS-pinned trust or custody Sectigo Code Signing (OV/EV) + Code Sign Protect-style custody SaaS only
Certificate inventory / discovery step certificate inspect + Prometheus on self only SCM Auto-Discovery agent at fleet scale (F5/IIS/Java/ACM) SaaS only
CT-log monitoring Must NOT submit; run own crt.sh / Cert Spotter watch Sectigo submits public issuance to qualified CT logs SaaS only
HSM support pkcs11 / yubihsm / tpmkms / cloud KMS (AWS/Azure/GCP) Vendor-operated FIPS HSM root + intermediates At parity
Short-lived certs claims.maxTLSCertDuration hours to days; ACME ARI SCM minimum typically days to years; ARI support varies Partial
SSH certs OIDC provisioner SSH-CA (principals, TTL 1h or less) No SSH-CA product OSS only
K8s workload identity K8sSA provisioner (ServiceAccount JWT, zero secrets) None — always API key / EAB / DCOM OSS only
RBAC Provisioner config commit access + OIDC group claims MRAO/RAO + Org/Department multi-tenant hierarchy Partial
Workflow approvals No built-in approval UI (PR / change-control on ca.json) MRAO approval gates for OV/EV/Code Signing per Profile SaaS only
MS-CA autoenrollment No DCOM/WCCE proxy SCM MS-CA Gateway (DCOM proxy for AD fleets) SaaS only
Deployment & HA Self-hosted HA (3+ instances, replicated provisioner state) Vendor-operated SaaS Partial
Cost model Compute + ops + optional HSM amortisation Per-cert / per-Department licensing At parity
Compliance (WebTrust / SOC 2 / FIPS) FIPS iff HSM validated; CP/CPS + evidence are yours Vendor WebTrust attestation as procurement artifact SaaS only

What we're honest about

The caveats most vendors leave out.

The publicly-trusted root cannot migrate — ever

Browser and OS chains only verify against vendor roots embedded years ago through WebTrust and multi-year inclusion programmes at Mozilla, Apple, Microsoft and Chrome. Step-CA cannot become publicly trusted at any price. Sectigo keeps the entire public estate — external TLS, partner-pinned endpoints — permanently. Do not try to move it.

Public code signing and external S/MIME stay on Sectigo

CA/Browser Forum rules mandate FIPS 140-2 L2+ HSM custody for code signing, and Authenticode, Apple Developer ID and kernel-mode chains anchor to OS-pinned roots — Step-CA-signed binaries fail SmartScreen and Gatekeeper. External S/MIME only validates in Outlook, Gmail and Apple Mail from a publicly-trusted issuer. Both stay on Sectigo; Step-CA can do internal-only S/MIME at most.

A mis-routed internal name leaks into CT logs forever

If a wave mis-configures the issuer and a publicly-trusted cert is minted for an internal hostname, that name lands in append-only, crt.sh-searchable CT logs permanently. We gate against it with CAA-deny records on internal zones, Kyverno admission policy, and a Cert Spotter watch on every registered domain — and treat any internal-name CT hit as a P0 disclosure event.

You own uptime, approvals and Discovery scale

Once Step-CA issues the internal estate, it being down means internal issuance is down — so we run it HA with cached-cert grace and a tested DR runbook. Step-CA has no MRAO/RAO approval UI, no MS-CA DCOM proxy for AD autoenrollment, and no fleet-scale Auto-Discovery — those stay Sectigo deliverables. We flag every dependency before Phase 1.

Why this beats a flag day

Reversible in minutes, retired only after a long soak.

No phase forces a global trust-store update or an outage. Each wave rolls back in under 15 minutes because dual-trust means flipping the issuer back to Sectigo needs no restart — and a workload class only counts as migrated after at least 30 consecutive days of dual-issued traffic at target share with handshake error rate at or below baseline. Sectigo is never retired: only optional internal Department seats reduce after the soak, while public TLS, code signing, S/MIME and document signing stay on it indefinitely.

See how much of the internal estate migrates cleanly.

A call with a senior PKI engineer. We tag your certs as public or internal, size your HSM, trust-store and CAA work honestly, and tell you exactly how much you can move to Step-CA — and how much must stay on Sectigo forever.

Map my migration →