| Previous | Next |
| CERTSRV_E_INVALID_REQUESTID | CERTSRV_E_PENDING_CLIENT_RESPONSE |
CERTSRV_E_REQUEST_PRECERTIFICATE_MISMATCH
CERTSRV_E_REQUEST_PRECERTIFICATE_MISMATCH concerns certificate-transparency precertificate continuity. The final certificate request does not match the precertificate state previously created for the issuance transaction.
Start with the returning API
The returned status belongs to a stateful CA transaction rather than a standalone certificate parse in a certificate-transparency precertificate continuity investigation. 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.
Diagnostic evidence matrix
- 1. CA configuration and original request ID with disposition history
Preserve both the precertificate and final request inputs, including extensions and public key. - 2. Encoded request, attributes, precertificate or server challenge, and client response
Check whether policy modules or request-processing code changed SANs, extensions, validity, or key data between stages. - 3. Timestamps and identity linking every follow-up operation to the same CA database row
Restart the transaction only after identifying the mutation; otherwise repeated precertificates may be logged unnecessarily.
These observations are deliberately nonsecret: identifiers, lengths, provider names, policy selections, and state transitions usually support comparison without recording private keys, passwords, PINs, or plaintext.
Build a timeline before changing state
CA decisions depend on directory and transaction state at a particular moment. 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 in this condition investigation.
- 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.
- Directory evidence showing the template and requester attributes as visible to the CA at evaluation time.
Minimal test sequence
Run one clean test transaction and record each state transition from submission through response in this condition investigation. Compare where the failing transaction diverges, rather than copying attributes between unrelated request IDs.
- Use one known-good control that changes only the suspected part of this path.
- Record where behavior first diverges in this path instead of judging only by the final application message.
Scope of this HRESULT
The mismatch concerns continuity between two issuance stages, not ordinary chain validation of the resulting certificate. Deleting or resubmitting the request before exporting its CA database information loses the linkage needed to diagnose mismatch or lock state.
Closure criteria
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.
Technical references
These sources define the HRESULT and the relevant interface, protocol, or data format.
Looking for a different code? Search another status or error code.