What happens when AD CS Web Enrollment is deployed on a separate server without the required delegation?

The Web Enrollment server may report that its target certificate authority is offline and fail to complete enrollment requests. Administrators can misread this as a CA outage, when the real issue is missing service delegation. Rebooting both servers after fixing the delegation helps ensure the role picks up the corrected configuration.

Why the Web Enrollment Server Looks Offline When Delegation Is Missing

When Web Enrollment is separated from the certificate authority, the enrollment site depends on service delegation so it can talk to the CA on behalf of the web role. If that delegation is missing, the site often cannot complete the backend call and surfaces the CA as unavailable, even though the CA itself may be healthy. The failure is therefore a configuration break in the trust path, not necessarily a CA outage.

That distinction matters because the visible symptom is misleading: operators may focus on the CA service, network reachability, or certificate templates, when the real break is that the web server lacks the right delegated access to reach the CA service correctly. In practice, the browser-facing symptom is a proxy for an authentication or delegation failure between two Windows roles.

After delegation is corrected, both servers commonly need to be restarted so the AD CS role services reload the updated configuration and security context. Without that refresh, the old state can remain cached and the enrollment path may continue to fail even after the underlying setting has been fixed.

What Actually Breaks in the Enrollment Path

The enrollment flow is not just a web request, it is a chained server interaction. The user reaches the Web Enrollment role, the web tier must then contact the CA-backed services, and that handoff depends on the server-side trust and delegation configuration being correct. If the web server cannot present the expected delegated identity or access path, the request cannot be completed end to end.

That is why the failure can look like a site problem rather than a certificate service problem. The visible page may still load, but the back-end submission path fails when the web server tries to act as the intermediary. In a split deployment, that intermediary role is the sensitive part of the design.

For administrators, the practical test is whether the failure disappears only after delegation is repaired and the roles are restarted. If yes, the root cause is almost always the server-to-server authorization path rather than certificate authority availability.

How to Diagnose It Without Chasing a False CA Outage

The quickest diagnosis is to separate user-facing symptoms from service reachability. If the CA is reachable, healthy, and issuing certificates for other paths, but Web Enrollment still reports the CA as offline, treat delegation as the first configuration to verify. In a split-role design, the failing component is usually the trust bridge, not the CA engine itself.

Administrators should also verify that the web server and CA are paired the way the deployment expects, especially after any role changes, cloning, or hardening work. A working enrollment path depends on the correct delegation model being in place before the web tier can submit requests successfully.

Once the delegation setting is corrected, restart both servers or at least the relevant AD CS services so the corrected state is actually loaded. That final refresh step is often the difference between a configuration change on paper and a working enrollment path in production.

Risk and Threat Considerations

Misconfigured delegation in AD CS is operationally risky because it can make a healthy CA appear broken, delay certificate issuance, and push administrators toward unnecessary troubleshooting or downtime. In environments that depend on timely certificate enrollment, that confusion can become a service availability problem as well as a governance problem.

Failure mechanism: The web enrollment server cannot complete its delegated backend request to the CA, so the enrollment workflow fails and reports the CA as offline even when the CA is running.

Impact: Certificate issuance is interrupted, troubleshooting effort is misdirected, and a simple delegation fix may be missed until the role services are restarted and the corrected configuration takes effect.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Delegated server-to-server access depends on correct authentication between the web role and CA.
	IA-5 — Authenticator Management	The enrollment path depends on correct handling of credentials or delegation material used by the web server.
Recommendation — Verify server-to-server authentication paths and reload the updated trust configuration after delegation changes. Validate the lifecycle of the authentication material and restart services after updating it.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	AD CS enrollment failures affect certificate-based trust and issuance workflows.
Recommendation — Confirm certificate issuance dependencies and recovery steps after trust-path changes.
CIS Controls v8	CIS-5 — Account Management	The issue arises from misconfigured service delegation and access relationships between roles.
Recommendation — Review service account and delegation relationships that govern cross-server access.

Practitioner Guidance

What to verify: Confirm the split-role design, the required delegation setting, and whether the CA is actually healthy from a direct administrative path before treating the issue as a CA outage. If the CA works outside Web Enrollment, the web-to-CA trust path is the most likely fault domain.

Common mistake: Restarting or rebuilding the CA first is usually the wrong move. Fix the delegation, then restart both servers so the Web Enrollment role and the backend services reload the updated state together.

Practitioner takeaway: Treat “CA offline” from Web Enrollment as a symptom, not a verdict, until you have ruled out a broken server-to-server delegation path.