CA rollout: introduce a new AD CS PKI safely

The new CA will serve Wi-Fi, VPN and internal services

An organization plans certificate-based device authentication and replacing manually distributed server certificates. Installing a Windows CA is quick. Less obvious are decisions lasting years: trust anchors, publication addresses, key custody and who intervenes when a certificate expires.

This article covers introducing a two-tier AD CS PKI. Hardening existing templates and CA permissions, or moving applications to LDAPS, are separate work packages. Sequence matters: prepare infrastructure, distribute trust, restrict issuance and expand after meaningful tests.

Start with specific consumers. Record each platform, certificate purpose, responsible team, trust store, renewal method and acceptable interruption. Without this inventory, a technically working CA carries unknown business risk.

The offline root and issuing CA have separate jobs

The target consists of a standalone root CA outside the domain and an enterprise issuing CA on a dedicated domain member server, never a domain controller. The offline root signs the subordinate CA certificate and its own revocation list. The issuing CA serves endpoints. Additional issuers need a capacity, availability or separation justification.

Public CA certificates and revocation lists reside on separate publication systems. The offline root needs no network connection. A documented media and approval process transfers signed files. Publication never includes private keys.

Acceptance requires three demonstrations: intended consumers accept the correct chain, unauthorized devices cannot obtain certificates, and operations can restore revocation lists and issuance after a failure. A successful installation wizard proves none of these.

Decide names, lifetimes and key custody before installation

Approve CA names and lasting publication addresses beforehand. A stable DNS alias separates publication dependencies from future web server replacements. Give root, issuing and end-entity certificate lifetimes a shared renewal calendar. New certificates cannot remain valid beyond the issuing CA's expiry.

Test cryptography and key providers against actual clients. Obsolete algorithms are no compatibility strategy; neither is a configuration that a critical appliance cannot support. Exceptions need a replacement plan. Integrate any planned HSM before installing the CA and test its recovery process.

Keep the reviewed CAPolicy.inf, installation record and approved settings in operational documentation. Start the issuing CA without unreviewed default templates, for example through the designated LoadDefaultTemplates=0 setting. Then publish only approved templates.

CDP and AIA must work before certificates are issued

The CRL Distribution Point (CDP) points to revocation lists. Authority Information Access (AIA) provides the issuer certificate for chain building in this design. Configure the root correctly before issuing the subordinate CA certificate, and the issuing CA before issuing end-entity certificates. Changing URLs later does not repair certificates already issued.

Separate publication writes from client reads. Only authorized processes may replace files. Clients need dependable retrieval without interactive authentication. HTTP can be appropriate for signed CA certificates and CRLs: signature validation protects integrity, while avoiding another TLS dependency during chain building. This does not permit unprotected write access.

Test retrieval from client networks, server segments, VPN and any relevant DMZ. Wi-Fi authentication must not require the client to connect successfully before reaching revocation information. Publication intervals, overlap and alert lead time must allow recovery and staff cover. The offline root also needs a fresh CRL on time; powered off does not mean maintenance-free.

Distribute trust deliberately and verify it separately

After independently checking its fingerprint, distribute the root certificate to intended trusted root stores. For Windows domain devices, use a dedicated, initially restricted GPO under Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. Place the issuing CA certificate in the intermediate store, not the trusted root store.

Java applications, appliances and other platforms may have their own trust stores. Importing into Windows proves nothing for them. Also establish which CA certificates AD publication already distributes. A limited enrollment pilot does not automatically limit trust to the same devices.

For subsequent AD certificate authentication, verify the additional publication and mapping requirements, particularly NTAuth. A successful TLS test does not establish these authentication prerequisites. Give those use cases their own approval.

Start auto-enrollment with a small device group

Include a few representative systems and initially one clear certificate purpose. Duplicate a suitable template, restrict EKUs and configure subject/SAN handling for the identity source. Give the pilot group the required Read, Enroll and Autoenroll permissions; both CA and application must support the configuration. A GPO alone grants no issuance permission.

Enable Certificate Services Client – Auto-Enrollment in a separate GPO in the appropriate computer or user context. Test initial enrollment, renewal and the application's actual certificate selection. A new certificate in a store does not necessarily replace an existing service binding.

Test authorization with a designated device outside the pilot group: issuance must be denied. Then add consumers in recorded waves. Add enrollment web services, NDES or OCSP only for confirmed requirements.

Include revocation and outages in pilot acceptance

These local inspections change neither trust nor CA configuration. Use exported public certificates and CRLs, not PFX files containing private keys:

certutil.exe -dump '.\pilot-server.cer'
certutil.exe -dump '.\issuing-ca.crl'

Compare issuer, validity, EKUs, names and embedded addresses with the design. For the CRL, pay particular attention to ThisUpdate and NextUpdate. This output proves neither reachability nor application behavior. Follow it with chain validation, Enterprise PKI (pkiview.msc) and tests using actual consumers.

Revoke a certificate issued exclusively for testing, publish the new CRL and verify rejection. Document cache lifetimes and behavior when revocation information is unavailable. Continued acceptance is an unresolved acceptance criterion. Clearing caches across production or disabling revocation checking is no repair.

Test a failed publication node and stopped issuance within the approved pilot window. Stopping a CA does not invalidate existing certificates; renewal and timely CRL publication remain necessary.

Demonstrate recovery before wider release

Recovery requires CA certificates and private keys, database and logs, registry configuration, CAPolicy.inf and the published template list. Template definitions and permissions reside in AD and need separate backup and reconstruction. HSM keys follow the tested vendor procedure.

Protect key material and access credentials separately. Restore in isolation, without creating a second active instance of the same CA in production. The exercise must also demonstrate a new signed CRL and the documented publication process. Possessing a backup file is insufficient.

To stop a rollout, halt further issuance and affected policies in a controlled manner. This does not remove issued certificates or existing trust. Revocation, application rollback and trust removal are separate decisions. During migration, keep the old PKI operational while accepted certificates and validation paths still depend on it.

Advantages of a controlled rollout

• Limited impact: A small pilot exposes incorrect trust stores, network paths and service bindings before many systems are affected.
• Protected trust anchor: Keeping the root offline reduces the root key's continuous attack exposure.
• Predictable operations: Renewal, revocation and recovery receive responsibilities that can be verified.
• Repeatable expansion: New consumers use approved processes instead of creating more manual key copies.

Disadvantages and limits of a two-tier PKI

• More operational work: Root ceremonies, revocation lists, backup testing and documentation need time and staff cover.
• Additional cost: Separate systems, protected administration and potential HSMs create continuing overhead.
• No automatic application security: Some consumers check revocation inadequately or select the wrong certificate.
• No cure for unsafe templates: An offline root cannot prevent improper issuance by a compromised issuing CA. Removing that CA requires effective revocation checking and a prepared replacement.

Common mistakes when handing over to operations

Removing the pilot GPO is often mistaken for complete rollback. Other problems include old CDP addresses still referenced by certificates, unowned Java trust stores and root CRL expiry discovered through authentication failures. Monitor served files and remaining validity, not merely the CA service. A reachable web server serving an expired CRL still represents an incident.

Project checklist for the CA rollout

• [ ] Inventory consumers, trust stores, renewal methods and owners.
• [ ] Approve root, issuing CA, key custody and recovery objectives.
• [ ] Verify names, lifetimes and CDP/AIA before first issuance.
• [ ] Test publication paths from all intended networks.
• [ ] Distribute root trust and intermediate certificates deliberately.
• [ ] Restrict templates and auto-enrollment to the pilot scope.
• [ ] Demonstrate successful and denied issuance, plus service bindings.
• [ ] Test renewal, revocation, cache behavior and publication failure.
• [ ] Document isolated recovery, including CRL generation.
• [ ] Define alert lead time, staff cover, rollout stops and any old-PKI retirement.