| Previous | Next |
| CERTSRV_E_REQUEST_PRECERTIFICATE_MISMATCH | XENROLL_E_KEY_NOT_EXPORTABLE |
CERTSRV_E_PENDING_CLIENT_RESPONSE
CERTSRV_E_PENDING_CLIENT_RESPONSE identifies a failure in locked interactive enrollment transaction. The CA has placed the request in a state that cannot be edited until the expected client response completes the protocol exchange. Diagnose locked interactive enrollment transaction at the first component that returned the value, not the last user-interface layer that displayed it; later cleanup and fallback attempts can produce different secondary errors.
What the code establishes
This status belongs to a stateful CA transaction rather than a standalone certificate parse in a locked interactive enrollment transaction investigation. For CERTSRV_E_PENDING_CLIENT_RESPONSE, preserve the original request ID, disposition, request attributes, precertificate or challenge material, client response, and CA database record. A resubmission creates a new transaction and cannot explain the old one when CERTSRV_E_PENDING_CLIENT_RESPONSE is returned.
Facts to preserve before changing state
- CA configuration and original request ID with disposition history
Identify the request row, disposition, pending response type, and client correlation data.
For CERTSRV_E_PENDING_CLIENT_RESPONSE, links the status to the exact template or CA transaction. - Encoded request, attributes, precertificate or server challenge, and client response
Check whether the client abandoned a multi-step enrollment or key-attestation flow.
Preserves directory, request, and policy data evaluated by the CA when CERTSRV_E_PENDING_CLIENT_RESPONSE is returned. - Timestamps and identity linking every follow-up operation to the same CA database row
Resume or cancel through the supported protocol rather than editing the database directly.
In the CERTSRV_E_PENDING_CLIENT_RESPONSE path, avoids treating a new enrollment as proof that the original request was fixed.
Correlate the failure with state changes
CA decisions depend on directory and transaction state at a particular moment in a locked interactive enrollment transaction investigation. For CERTSRV_E_PENDING_CLIENT_RESPONSE, correlate template modification and publication, Active Directory replication, request submission, request ID assignment, policy-module evaluation, disposition changes, and any client continuation. This is especially important when a retry reaches a different domain controller or creates a new CA database row when CERTSRV_E_PENDING_CLIENT_RESPONSE is returned.
- For CERTSRV_E_PENDING_CLIENT_RESPONSE, exported request and relevant attributes, template OID/version, CA configuration, and original request ID.
- CA operational events and request disposition history from the same transaction when CERTSRV_E_PENDING_CLIENT_RESPONSE is returned.
- In the CERTSRV_E_PENDING_CLIENT_RESPONSE path, directory evidence showing the template and requester attributes as visible to the CA at evaluation time.
Isolation procedure
Run one clean test transaction and record each state transition from submission through response in a locked interactive enrollment transaction investigation. For CERTSRV_E_PENDING_CLIENT_RESPONSE, compare where the failing transaction diverges, rather than copying attributes between unrelated request IDs.
| Test | Interpretation |
|---|---|
| Same input, known-good path | For locked interactive enrollment transaction, success moves attention toward the selected provider, policy, device, context, or transaction state. |
| Known-good input, failing path | For locked interactive enrollment transaction, failure suggests that the environment or selected object is independently unable to perform the operation. |
| Original path after one isolated change | For locked interactive enrollment transaction, this comparison demonstrates whether the proposed correction addresses the original condition. |
Common wrong turns
A request that is merely pending approval is not necessarily locked for the same client-response reason. Deleting or resubmitting the request before exporting its CA database information loses the linkage needed to diagnose mismatch or lock state when CERTSRV_E_PENDING_CLIENT_RESPONSE is returned.
For locked interactive enrollment transaction, keep the original request and response pair; regenerating a key or submitting a new request may succeed while bypassing the policy or transaction state that produced this HRESULT.
Proving the intended path works
For CERTSRV_E_PENDING_CLIENT_RESPONSE, the same transaction must advance through its documented next state using matching request and response material; a newly issued certificate from a new request is not proof. For CERTSRV_E_PENDING_CLIENT_RESPONSE, keep a regression case that uses nonsecret identifiers and expected outcomes, including one negative control that must continue to fail.
Technical references
For CERTSRV_E_PENDING_CLIENT_RESPONSE, these sources define the HRESULT and the relevant locked interactive enrollment transaction interface, protocol, or data format.
- Microsoft Open Specifications: HRESULT values.
- Microsoft Open Specifications: Windows Client Certificate Enrollment.
- Microsoft: Certificate templates overview.
- Microsoft: certreq command.
Looking for a different code? Search another status or error code.