I85PREP
⌘ K
AZ-802 Windows Server Hybrid Administrator study materials
AZ-802 Windows Server Hybrid Administrator study resources

Certificate Renewal Across a Two-Region PKI

AZ-802 Windows Server Hybrid Administrator · Put your knowledge to work in context.

All case studies

Certificate Renewal Across a Two-Region PKI

Contoso has two datacenters: DC1 in Chicago and DC2 in Dallas, connected by a 40 ms link. The root CA is offline in DC1. Two issuing CAs run Windows Server: CA1 in DC1 and CA2 in DC2. Both were installed with default settings and publish CRLs to a DFS-R replicated share. Certificate templates are published on the root and are replicated to both CAs by a scheduled task that runs nightly at 02:00.

On Monday, an administrator adds a new template for VPN server authentication with a 180-day validity and 2-hour CRL publication interval. By Wednesday, enrollment to the new template succeeds against CA1 but fails against CA2 with error 0x80094800. Meanwhile, field laptops in Dallas report that VPN authentication intermittently fails for about 10 minutes after each CRL update, then recovers. No firewall changes were made recently.

1. Diagnose the enrollment failure on CA2 and state the remediation, including how to prevent recurrence.

Read the worked answer

Diagnosis. Error 0x80094800 is the template-not-supported / template-not-found class of failure. The new template was published on the root CA, but CA2 does not yet have it. The scheduled replication task runs nightly, so CA2's view of the template list is stale. CA1 succeeds because it is the CA where the template was published and its cache refreshed immediately.

Remediation.

  1. On CA2, open the Certification Authority console, right-click Certificate Templates, choose New > Certificate Template to Issue, and select the new VPN template. This is the step that actually makes a template issuable on a given CA; publishing on the root alone is not sufficient.
  2. If the template does not appear in that list, force replication of the Configuration partition (the template objects live under CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration) with repadmin /syncall /AdeP and re-check.
  3. Restart the CA service on CA2 if the template list appears stale after replication.

Prevention. The nightly scheduled task is the real defect. Template publication should be treated as a configuration change that requires an explicit post-change replication check on every issuing CA, not a background job. Add a validation step to the change procedure: after publishing a template, confirm it is issuable on each CA, and alert on enrollment failures by template name so a regional CA drift is caught within minutes rather than at the next enrollment attempt.

2. Explain the intermittent VPN failures in Dallas and give two changes that address the root cause.

Read the worked answer

Diagnosis. The symptom pattern - failures for roughly 10 minutes right after each CRL update, then automatic recovery - points to CRL retrieval, not to certificate validity or VPN policy. Clients validate the chain by fetching the CRL named in the certificate's CDP extension. If the CDP points to an HTTP location that is only reachable from the corporate network, Dallas clients connecting from outside cannot fetch it. They fail while the cached CRL is expired or being refreshed and succeed once a cached copy is available again from a reachable path.

The 2-hour CRL interval is aggressive and multiplies the exposure window: every two hours a fresh CRL appears, cached copies go stale, and clients that cannot reach the distribution point fail until they obtain the new one through some working path. The 40 ms link is not the issue; reachability of the CDP is.

Changes.

  1. Publish the CRL to an externally reachable HTTPS location (or an Azure Storage static website / CDN endpoint) and add that URL to the CDP extension of the templates and the CA configuration. Keep the internal DFS-R path as an additional entry, ordered after the public one for external clients. Ensure the CRL is uploaded on each publish cycle.
  2. Republish the CRL after the change and validate from an off-network client. Use certutil -URL <cert> on a test machine outside the corporate network to confirm every CDP entry resolves. Also reconsider the 2-hour interval: it is only appropriate if publication to the public endpoint is automated and monitored. A longer interval with delta CRLs reduces the number of windows in which a client can be caught without a valid cached CRL.

A secondary check is that the DFS-R share is not itself the CDP - DFS-R is a replication mechanism, not a client-facing distribution point, and clients should never be pointed at a replicated UNC path they cannot reach.