Moving from Active Directory Certificate Services (AD CS) to Skyrsoft CertOps doesn’t need a flag day. Stand up a fresh hierarchy, run it alongside AD CS, move services across in stages, and roll trust forward as you go.
How it works
Set expectations before starting. Two things need real planning; the rest is largely mechanical.
| Reality | |
|---|---|
| Your existing CA key / issuer chain | Not imported. CertOps creates its own root and issuing CA; it does not continue signing from an existing CA’s private key. You roll trust forward instead. |
| Non-domain-joined devices & Macs | The quick win. Enrol them through the agent, on Windows and macOS alike. |
| Existing NDES/SCEP clients | Repointable. CertOps exposes an NDES-compatible SCEP URL (Pro). |
| GPO autoenrollment for domain-joined Windows | Moves to the agent. Migrate those hosts in batches over a transition window. |
| Platform | Unchanged. Both AD CS and CertOps are Windows-hosted. |
Standing up a parallel hierarchy
Install CertOps and create a root CA and an issuing CA — a new hierarchy, since CertOps does not import an AD CS root or intermediate key. Publish the new root certificate to the machines that should trust internally-issued certificates, using whatever configuration management, MDM or GPO you already run. AD CS keeps running throughout.
Starting with Macs and non-domain devices
Install the agent on non-domain-joined devices and Macs and enrol them against CertOps. The private key is generated on each host and never leaves it; on macOS the certificate lands in the System keychain.
Repointing SCEP clients
Existing NDES/SCEP clients can be repointed at a CertOps SCEP endpoint, which offers an NDES-compatible URL alias — the main protocol-level interoperability with the AD CS world. This is a Pro feature.
Transitioning domain-joined Windows
Migrate domain-joined populations to the agent in batches while both issuers run, keeping AD CS authoritative for anything not yet migrated.
Decommissioning AD CS
Once nothing enrols against it and no dependent service points at it, retire the AD CS role. Keep the old root published for validation until the long-lived certificates it signed have aged out.
Comparing first
The side-by-side comparison sets out what CertOps adds over AD CS, feature by feature. This page covers the how.
Limits
The existing CA’s key and issuer chain are never imported. CertOps always creates a fresh root and issuing CA of its own; there is no path that continues signing from an existing AD CS private key, so every migration involves rolling trust forward to a new hierarchy rather than carrying the old one across.
Domain-joined hosts move to the agent in batches. Group Policy autoenrollment isn’t carried across, so plan a transition window: there is no single switch that converts an autoenrolling OU in one step.
If the migration plan also touches automated rotation of privileged Windows accounts, that’s a separate problem this doesn’t solve. AdminSDHolder and SDProp re-stamp protected-group members’ ACLs periodically, which constrains how a delegated account can hold rights over time — worth reading up on before assuming any tool’s automated rotation of those accounts will behave the way a non-privileged account’s rotation does.