Start by checking the delegation settings on the server object that hosts Web Enrollment in Active Directory. The role can fail when it is installed separately from the certificate authority and lacks the service delegation it needs. Configure constrained delegation for the specific CA services, then restart both servers so the enrollment role can authenticate and function correctly.
Why the Web Enrollment Role Shows the CA as Offline
When AD CS Web Enrollment is installed on a separate server, it still depends on the certificate authority for backend enrollment actions. If the Web Enrollment server cannot delegate the user’s request to the CA, the CA can appear offline even when it is running. The practical issue is usually not the CA itself, but broken server-to-server authentication and delegation.
The first thing to check is whether the Web Enrollment host is allowed to delegate to the CA services it needs. In this pattern, the enrollment role is acting as a middle tier, so its service account or computer object must be able to present the request onward instead of stopping at the front-end server.
What to Check on the Web Enrollment Server Object
Open the Active Directory computer object for the server that hosts Web Enrollment and review its delegation configuration. The role commonly fails when constrained delegation is missing, mis-scoped, or not set for the specific CA service endpoints the enrollment flow uses. That means the server may be healthy on its own, but unable to authenticate on behalf of the requestor.
Configure constrained delegation for the certificate authority services required by the enrollment path, rather than using a broad or implicit trust setting. The goal is to let Web Enrollment forward requests only to the CA services it actually needs, which preserves the trust boundary while restoring function.
Why a Restart Is Part of the Fix
After updating delegation, restart both the Web Enrollment server and the certificate authority server so the new service tickets and authentication state are rebuilt cleanly. Without a restart, the old security context can persist and make the change look ineffective even when the directory settings are correct.
In practice, this is a state-refresh problem as much as a configuration problem. If the delegation is fixed but the servers keep old sessions or cached authentication material, the enrollment role may continue to report the CA as offline until both sides reinitialize.
Risk and Threat Considerations
Misconfigured delegation on a separated Web Enrollment deployment can create both availability failure and trust exposure. The immediate risk is a broken enrollment path, but the deeper concern is that administrators may widen delegation too far to restore service, which increases the blast radius if the Web Enrollment host is compromised.
Failure mechanism: The front-end enrollment server cannot present the request to the CA because its delegated authentication path is absent or too narrowly defined for the CA service it must reach.
Impact: Certificate enrollment fails or appears unavailable, operators may overcorrect with excessive trust, and the separated role can become a larger security dependency than intended.
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 — Service Identification and Authentication | Web Enrollment depends on server-to-server authentication to the CA. |
| AC-6 — Least Privilege | Constrained delegation should limit the enrollment server to only required CA services. | |
| Recommendation — Enforce authenticated service-to-service access for the enrollment path. Restrict delegation to the minimum CA services needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Delegation settings are an access-control decision governing which server can act for another. |
| A.8.9 — Configuration management | The issue is often a misconfigured AD CS role deployment across separate servers. | |
| Recommendation — Review and restrict the server delegation policy for the enrollment role. Validate and document the Web Enrollment and CA configuration after changes. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The fix requires correct delegated access between the enrollment host and CA. |
| Recommendation — Tighten and verify delegated access between the enrollment server and CA. | ||
Practitioner Guidance
What to verify: Confirm that the Web Enrollment computer account has constrained delegation set for the exact CA service classes used by the enrollment flow, and verify that the CA can answer once the service tickets are refreshed.
Decision rule: If Web Enrollment and the CA are split across servers, treat an “offline” CA message as a delegation and authentication issue first, not as a CA health issue, until the directory settings prove otherwise.
Practitioner takeaway: Separate-server AD CS enrollment failures usually come from broken middle-tier delegation, so fix the trust path before chasing the CA itself.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of AD CS abuse when a certificate authority can be tricked into trusting attacker-supplied data?
- How should security teams use decoy certificate templates to detect AD CS abuse early?
- What should teams do first when PetitPotam-style NTLM relay is a concern in AD CS environments?
- What should security teams do first when a certificate authority is distrusted after a compromise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
