| Previous | Next |
| DIGSIG_E_DECODE | DIGSIG_E_CRYPTO |
DIGSIG_E_EXTENSIBILITY
DIGSIG_E_EXTENSIBILITY identifies a failure in ASN.1 extension versus attribute model. The digital-signature data places information in an Extensions collection where the implementation expects Attributes, or the reverse. Diagnose ASN.1 extension versus attribute model 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
The implementation has encountered a semantic mismatch between ASN.1 Extensions and Attributes collections when DIGSIG_E_EXTENSIBILITY is returned. In the DIGSIG_E_EXTENSIBILITY path, they may both contain OID/value pairs, but their syntax, placement, signing semantics, and protocol meaning are not interchangeable.
Facts to preserve before changing state
- Field path and OID placed in the wrong collection
Map each OID to the ASN.1 field defined by the relevant profile.
Locates the failure in representation, object placement, or cryptographic execution when DIGSIG_E_EXTENSIBILITY is returned. - Schema or API object used to build the request or signed data
Inspect whether a conversion layer flattened certificate extensions and CMS signed attributes into one generic collection.
Keeps ASN.1 syntax separate from certificate-chain policy when DIGSIG_E_EXTENSIBILITY is returned. - Whether the value is intended to be covered as a signed attribute, certificate extension, or another container
Regenerate the object from the correct schema rather than renaming the field.
Produces a minimal signed-data case that another implementation can inspect when DIGSIG_E_EXTENSIBILITY is returned.
Build a timeline before changing state
For DIGSIG_E_EXTENSIBILITY, record the transition from application objects to ASN.1 bytes and then to cryptographic execution. In the DIGSIG_E_EXTENSIBILITY path, the first failing stage determines whether to inspect field placement, encoder input, decoder bytes, algorithm parameters, or private-key access. A final “signature invalid” message cannot recover that boundary after intermediate statuses are discarded in an ASN.1 extension versus attribute model investigation.
- In the DIGSIG_E_EXTENSIBILITY path, minimal object model and encoded bytes with the first optional field that changes the result.
- Digest and signature algorithms, key provider, and lower-level provider status where applicable when DIGSIG_E_EXTENSIBILITY is returned.
- Independent ASN.1 and signature observations using the exact original bytes when DIGSIG_E_EXTENSIBILITY is returned.
Isolation procedure
In the DIGSIG_E_EXTENSIBILITY path, build minimal objects containing the OID once in the schema-correct collection and once in the failing collection. Compare encoded field paths rather than only decoded display text in an ASN.1 extension versus attribute model investigation.
- Preserve the original input, identity, provider or protocol selection, and first return value for
DIGSIG_E_EXTENSIBILITY. - Use one known-good control that changes only the suspected part of the ASN.1 extension versus attribute model path.
- For
DIGSIG_E_EXTENSIBILITY, reverse the comparison with known-good input on the failing layer where that can be done safely. - Record where behavior first diverges in the ASN.1 extension versus attribute model path instead of judging only by the final application message.
Common wrong turns
Extensions and Attributes can both contain OID/value pairs, but they occupy different signed structures and are not interchangeable. In the DIGSIG_E_EXTENSIBILITY path, copying raw DER from an extension into an attribute wrapper, or vice versa, can preserve the inner value while leaving the outer ASN.1 type wrong.
For ASN.1 extension versus attribute model, keep representation, cryptographic execution, and trust evaluation separate. In this path, a byte sequence can decode correctly and still fail signature policy, while no chain repair can make malformed ASN.1 decode.
Proving the intended path works
For DIGSIG_E_EXTENSIBILITY, every OID/value pair must appear in the collection defined by the protocol and be included in the correct signature scope. For DIGSIG_E_EXTENSIBILITY, keep a regression case that uses nonsecret identifiers and expected outcomes, including one negative control that must continue to fail.
Technical references
For DIGSIG_E_EXTENSIBILITY, these sources define the HRESULT and the relevant ASN.1 extension versus attribute model interface, protocol, or data format.
- Microsoft Open Specifications: HRESULT values.
- ITU-T X.690: BER, CER and DER.
- RFC 5652: Cryptographic Message Syntax.
- Microsoft: Wintrust API.
Looking for a different code? Search another status or error code.