Skip to content
ADCS Migration Field Guide
Interactive implementation guide

Retire ADCS,
without breaking a single trust.

Chain a Radius365 issuing CA under the ADCS root your fleet already trusts, cut enrollment over, and let devices roll onto it as certificates renew — no new trust distribution, no outage.

Guided migrationSetup ~40 min + rollover window
Systems4 connected
Rollout modelChain first, cut over gradually
The cloud issuing CA chaining under the on-premises ADCS root that devices already trust
FIELD03ADCS / 2026
Built for a zero-trust-distribution migration
01 / TRUST MODEL

Certificate journey

Select a node to see its responsibility.

PLATE / A
ADCS root

Signs the subordinate's CSR once, keeps its CRL alive, then stays dormant as the trust anchor every device already has.

02 / PRE-FLIGHT

Before you touch the root

A safe ADCS migration starts with knowing exactly which root you're chaining under and who can sign against it.

Never revoke or retire the ADCS root while any certificate in the chain still depends on its CRL.
Migration readiness0/4
4 checks remaining
00 / 08
00Radius36510 min
Start with the trust you already have

Inventory the root and plan the chain.

STEP00
Outcome

A confirmed ADCS root, the account that can sign a Subordinate CA request, and a named subject for the new issuing CA.

Required roleRadius365 PKI administrator

Before you begin

Your ADCS root CA is reachable — Enterprise (with certsrv/RPC access) or a standalone/offline root.

An account allowed to submit and issue a Subordinate Certification Authority request on it.

Do this

  1. 01

    Identify the root: Enterprise CA (has the built-in SubCA template) or standalone/offline root (no templates, requests are issued manually in certsrv.msc).

  2. 02

    Decide the subject for the new issuing CA, e.g. CN=Contoso Cloud Issuing CA, O=Contoso, C=US.

  3. 03

    Decide what it will issue first — SSL for TLS/ACME or SCEP for Intune/MDM — the template picked in Radius365 later.

  4. 04

    Confirm every device that must trust the new CA already trusts the ADCS root (GPO, NTAuth, RADIUS/VPN configs).

CHECKPOINT

Verify before continuing

03 / DIAGNOSE

Troubleshoot by symptom

Start with the system that reported the failure. Chaining under ADCS removes the trust-distribution risk, not every other kind of PKI mistake.

ADCS

certreq: the requested certificate template is not supported

You targeted a standalone/offline root with -attrib "CertificateTemplate:SubCA". Standalone roots have no templates — submit without -attrib and issue the pending request in certsrv.msc.

ADCS

Request stays pending on an Enterprise CA

Your account lacks Enroll on the SubCA template, or the CA holds all requests — grant Enroll or issue it manually from Pending Requests.

Radius365

Portal: certificate's public key does not match this CA's key

The wrong file was pasted — often the root instead of the issued subordinate. Use the certificate produced for this CSR, converted with certutil -encode.

Radius365

Portal: not a CA certificate (basicConstraints missing)

The CSR was signed with a non-CA template. Re-sign with the SubCA template, or an inf that sets basicConstraints CA=true.

Device

revocation function was unable to check revocation

The root's CRL expired or its CDP is unreachable — republish the offline root's CRL. The subordinate's CRL/OCSP are hosted by Radius365 and refresh automatically.

Device

Smart-card / on-prem CBA logon fails though TLS works

Publish the subordinate to NTAuthCA (certutil -dspublish -f ... NTAuthCA) and allow time for AD replication.

FIELD NOTE / 09

The migration is finished when the root can go quiet.

You now have a safer path off ADCS: chain, sign, verify, cut over, roll the fleet, then retire NDES and old issuing CAs on your own schedule — with the root always available as a rollback anchor.

IMPLEMENTATION PATH
0%guide completed

Interfaces and commands change. Confirm certreq/certutil syntax against current Microsoft documentation before production use.