Why does AD CS Web Enrollment need delegated access to the certificate authority in a split-server setup?

Web Enrollment depends on the server being allowed to act on behalf of users when it talks to the certificate authority. Without the correct delegation, the role cannot reach the CA services it needs and may incorrectly show the CA as offline. The issue is not the CA itself, but the identity and service permissions between the two servers.

Why Web Enrollment can reach the CA in a split-server design

In a split-server AD CS deployment, Web Enrollment is not just a web form in front of the certificate authority. It is a middle tier that has to make authenticated, authorized requests to the CA on behalf of the user or enrollment session. The delegation requirement exists because the web role must carry identity and permission across the server boundary, not because the CA itself is unavailable.

That distinction matters operationally. If the web server cannot present the right delegated identity or service permission, it may be able to render the portal but fail when it tries to query templates, submit a request, or retrieve CA status. The result can look like a CA outage even when the CA service is healthy.

The practical model is similar to other on-behalf-of flows in enterprise identity: one component initiates the request, but another component must be trusted to act with enough authority to complete the transaction. In AD CS, that trust relationship has to be configured deliberately, especially when the web tier and the CA are separated for security or segmentation reasons. For the certificate lifecycle side of the problem, see Machine Identity, PKI and Certificate Lifecycle Guide.

What breaks when delegation is missing or scoped too tightly

Without the right delegation, the web server can lose the ability to act as the user or as the required service context when talking to the CA. In practice that means failed enrollment, failed template lookups, failed policy checks, or a misleading “offline” CA display caused by an authorization failure rather than a real availability issue.

This is why the issue is usually diagnosed as an identity and service-permission problem, not a certificate authority problem. The split-server model introduces an extra trust boundary, so the web tier must be trusted just enough to complete CA interactions, but no more. That balance is the core design constraint.

When administrators harden AD and certificate services together, they should treat delegation as part of the trust path rather than an incidental configuration detail. NHIMG’s Active Directory and Entra ID Hardening Guide covers delegation and certificate services in the broader access-control context.

Why the split-server pattern exists at all

The split-server layout is often used to reduce exposure of the CA tier while still allowing users to enroll through a web front end. That design can improve segmentation, but it also creates an identity relay problem: the front end has to bridge user intent to backend CA operations without becoming overprivileged or losing traceability.

In that sense, the architecture trades one risk for another. You reduce direct user-to-CA exposure, but you introduce a dependency on correct delegation, service identity, and backend authorization. If those are wrong, the user experience fails in a way that can be mistaken for infrastructure failure.

For readers mapping this to broader identity patterns, Human vs Non-Human Identity is useful because it explains how delegated access and service actors behave when one system is acting for another. The underlying control question is the same: which identity is allowed to speak for whom, and under what conditions?

Risk and Threat Considerations

Delegation in a split-server enrollment flow creates a trust bridge between the web tier and the CA. If that bridge is too broad, attackers who compromise the front end may inherit access paths to certificate services; if it is too narrow or misconfigured, legitimate requests fail and operators may misread the problem as an outage.

Failure mechanism: The web enrollment server cannot present the delegated identity or service permission required to complete CA interactions, so backend requests fail even though the CA service itself is reachable.

Impact: Certificate requests, template queries, and status lookups can break, which delays issuance and can mislead operations teams into chasing the wrong fault domain. In a worse case, overly broad delegation expands blast radius if the web tier is compromised.

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 OWASP ASVS 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	The web tier and CA authenticate as services across a trust boundary.
	AC-6 — Least Privilege	Delegation should grant only the backend authority needed for enrollment actions.
Recommendation — Use IA-9 to authenticate the web enrollment service before it acts on CA resources. Restrict delegated CA access to the minimum permissions required for enrollment.
ISO/IEC 27001:2022	A.5.15 — Access control	Split-server enrollment depends on controlled access between application and CA tiers.
	A.8.5 — Secure authentication	The web enrollment flow depends on trustworthy authentication across the server boundary.
Recommendation — Define and enforce access rules for the web tier’s CA interactions. Use secure authentication for the web server’s access to CA services.
OWASP ASVS	V8 — Authorization	The issue is whether the web layer is authorized to perform backend certificate actions.
Recommendation — Verify that backend certificate actions are authorized only for the intended web flow.

Practitioner Guidance

What to verify: Confirm the exact delegation model used between the web server and the CA, then test the full enrollment path with a real user and a real template. If the portal loads but CA-bound actions fail, treat it as an authorization or delegation defect before investigating CA health.

Common mistake: Teams often validate only that the CA service is online and reachable, then assume enrollment issues must be certificate or IIS problems. In a split-server design, the more important question is whether the web tier can act with the required authority across the boundary.

Practitioner takeaway: The split-server design works only when the web tier has precisely enough delegated authority to complete CA operations, no more and no less. If that trust path is wrong, the symptom is usually broken enrollment, not a broken CA.