| Previous | Next |
| XENROLL_E_KEY_NOT_EXPORTABLE | XENROLL_E_RESPONSE_KA_HASH_NOT_FOUND |
XENROLL_E_CANNOT_ADD_ROOT_CERT
The important part of XENROLL_E_CANNOT_ADD_ROOT_CERT is its scope: root-store installation boundary. The enrollment component refuses to add the returned root CA certificate to the local trust store in the current context or policy. Keep the hexadecimal value 0x80095001 with the returning API, because higher-level software may translate it into a message that loses this distinction.
Where the status is selected
The enrollment response may include a root CA certificate, but adding a trust anchor is a separate privileged trust-store decision. Capture the store location, caller identity, enrollment flags, root thumbprint, and enterprise policy rather than treating issuance and trust installation as one operation.
Evidence that changes the diagnosis
- 1. Root certificate identity and whether it already exists in an applicable store
Identify user versus local-machine target store and the caller elevation/token. - 2. Current user versus local machine store and caller privileges
Check enterprise trust distribution, Group Policy, and whether the root is already present with a different encoding. - 3. Enterprise trust distribution policy and the CertEnroll method requesting installation
Validate the root out of band before any manual installation.
For root-store installation boundary, 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.
Preserve the evidence chain
CertEnroll holds state across key creation, request encoding, submission, response parsing, and installation. Keep those stages tied to the same client object and key. If the application silently creates a replacement key or reconstructs the request, a later success no longer tests the archival, export, usage, or trust-store condition that originally failed in a root-store installation boundary investigation.
- Provider and nonsecret key properties captured before request initialization in a root-store installation boundary investigation.
- In the path, original encoded request and response plus transaction or request identifiers.
- In the path, CertEnroll method sequence, template or extension choices, and the store targeted during installation.
A controlled way to reproduce it
Validate the returned chain without modifying trust, then test root installation in a controlled store under the intended administrative process., this separates a usable certificate response from an unauthorized trust-store mutation.
| Test | Interpretation |
|---|---|
| Same input, known-good path | For root-store installation boundary, success moves attention toward the selected provider, policy, device, context, or transaction state. |
| Known-good input, failing path | For root-store installation boundary, failure suggests that the environment or selected object is independently unable to perform the operation. |
| Original path after one isolated change | For root-store installation boundary, this comparison demonstrates whether the proposed correction addresses the original condition. |
Nearby results and misleading fixes
Issuing an end-entity certificate and establishing trust in a root are separate security decisions. Silently placing a root into a user store to avoid an error can create different trust behavior from the machine or enterprise policy expected by the application.
For root-store installation boundary, 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.
What counts as a real resolution
Enrollment should complete while trust anchors are installed only through the approved store and policy path, with the expected root present exactly where intended. Keep a regression case that uses nonsecret identifiers and expected outcomes, including one negative control that must continue to fail.
Technical references
These sources define the HRESULT and the relevant root-store installation boundary interface, protocol, or data format.
- Microsoft Open Specifications: HRESULT values.
- Microsoft: IX509CertificateRequestCmc.
- Microsoft: CNG Key Storage Providers.
- RFC 5280: Internet X.509 PKI profile.
Looking for a different code? Search another status or error code.