| Previous | Next |
| TRUST_E_SYSTEM_ERROR | TRUST_E_COUNTER_SIGNER |
TRUST_E_NO_SIGNER_CERT
TRUST_E_NO_SIGNER_CERT concerns CMS/Authenticode signer identification. The signed object names a signer, but Windows cannot locate or accept the certificate needed to validate that signer information.
Read the failure at the correct layer
CMS or Authenticode signer information identifies a certificate through issuer/serial or subject-key identifier and may also rely on embedded or external certificate collections. Preserve the signed data, signer identifier, included certificates, stores, and selection result.
Build an incident record
- 1. Signer identifier and every certificate embedded in or supplied to the message
Inspect SignerIdentifier in the CMS message and the embedded certificate set. - 2. Certificate stores and retrieval mechanisms consulted by the trust path
Check issuer/serial or subject-key-identifier matching and whether the certificate was omitted. - 3. Chain result, key usage, time validity, and signature algorithm for the candidate signer
Verify that the candidate signer certificate has the expected public key and signature usage.
For CMS/Authenticode signer identification, 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.
Correlate the failure with state changes
Trust verification is a pipeline, not one Boolean check. Align artifact acquisition, signature decoding, signer selection, countersignature or timestamp processing, chain construction, revocation retrieval, and final action policy. Preserve provider state before closing it so the generic top-level result can be connected to the stage that actually rejected the subject.
- Original signed artifact or catalog identity and the exact WinVerifyTrust action and flags.
- Signer, countersigner, timestamp, chain, revocation, and nested provider results.
- verification from a second tool configured to apply equivalent policy, not merely a signature-only check.
Use two comparison axes
Inspect the signer information independently and locate the exact certificate by its identifier. Then verify that certificate and signature separately before running the full trust action.
| Test | Interpretation |
|---|---|
| Same input, known-good path | For CMS/Authenticode signer identification, success moves attention toward the selected provider, policy, device, context, or transaction state. |
| Known-good input, failing path | For CMS/Authenticode signer identification, failure suggests that the environment or selected object is independently unable to perform the operation. |
| Original path after one isolated change | For CMS/Authenticode signer identification, this comparison demonstrates whether the proposed correction addresses the original condition. |
Do not collapse it into a neighboring code
A missing signer certificate is different from an untrusted chain: chain policy starts only after the signer certificate is identified. Adding an unrelated certificate with the same subject name can create ambiguous selection and does not satisfy issuer/serial or key-identifier matching.
For CMS/Authenticode signer identification, also retain the original numeric value; neighboring constants can encode materially different remediation paths even when an application presents all of them as an authentication, certificate, or security failure.
Verification after the change
Windows must select the intended signer certificate, validate the signature, and build the required policy chain for the original signed object.
Technical references
These sources define the HRESULT and the relevant CMS/Authenticode signer identification interface, protocol, or data format.
Looking for a different code? Search another status or error code.