| Previous | Next |
| TRUST_E_NO_SIGNER_CERT | TRUST_E_CERT_SIGNATURE |
TRUST_E_COUNTER_SIGNER
TRUST_E_COUNTER_SIGNER identifies a failure in timestamp or countersignature validation. A countersignature attached to the primary signer failed parsing, signature verification, certificate selection, or policy evaluation. Diagnose timestamp or countersignature validation 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.
Start with the returning API
A countersignature or timestamp is a signature over signer information, not a second signature over the original file in the same form when TRUST_E_COUNTER_SIGNER is returned. In the TRUST_E_COUNTER_SIGNER path, capture the countersigner identifier, signed attributes, message-imprint or signing-time data, certificate set, and policy time used for verification.
Diagnostic evidence matrix
- Primary signer information and exact countersignature attribute bytes
Enumerate each countersigner and timestamp token rather than reporting only the primary signer.
Identifies the trust action, subject representation, and signer state when TRUST_E_COUNTER_SIGNER is returned. - Countersigner certificate, algorithm, signing time or timestamp token, and chain result
Check message-imprint binding, signing time, TSA certificate EKU, chain, and algorithm support.
Separates signature decoding, certificate selection, and final policy when TRUST_E_COUNTER_SIGNER is returned. - Whether parsing, signature verification, certificate selection, or policy evaluation failed
Verify the primary signature separately to determine whether only timestamp semantics are affected.
Prevents success under a different trust action from masking the original failure when TRUST_E_COUNTER_SIGNER is returned.
What to include in an escalation package
For TRUST_E_COUNTER_SIGNER, 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. In the TRUST_E_COUNTER_SIGNER path, 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 when TRUST_E_COUNTER_SIGNER is returned.
- In the TRUST_E_COUNTER_SIGNER path, signer, countersigner, timestamp, chain, revocation, and nested provider results.
- For TRUST_E_COUNTER_SIGNER, verification from a second tool configured to apply equivalent policy, not merely a signature-only check.
Minimal test sequence
Verify the primary signature without the countersignature policy, then decode and verify the countersignature independently in this condition investigation. For TRUST_E_COUNTER_SIGNER, this identifies whether the original signer is valid and the failure is limited to timestamp evidence.
- Preserve the original input, identity, provider or protocol selection, and first return value for
TRUST_E_COUNTER_SIGNER. - Use one known-good control that changes only the suspected part of this path.
- Reverse the comparison with known-good input on the failing layer where that can be done safely.
- Record where behavior first diverges in this path instead of judging only by the final application message.
Boundaries of this HRESULT
A valid primary signature can coexist with a bad countersignature, but the effective trusted signing time may then be unavailable. Removing an invalid countersignature can change long-term validity semantics; it is not equivalent to repairing the timestamp or countersigner chain in this condition investigation.
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.
Closure criteria
Both primary signature and countersignature must validate under the intended time and certificate policy, with the countersignature bound to the correct signer information in this condition investigation. 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 relevant interface, protocol, or data format.
- Microsoft Open Specifications: HRESULT values.
- Microsoft: WinVerifyTrustEx.
- Microsoft: WINTRUST_DATA.
- RFC 5652: Cryptographic Message Syntax.
Looking for a different code? Search another status or error code.