Add options to disable CRL checks and trust verification in extract and attach flows for offline/private PKI use in osslsigncode

[billnice250]

Use Case / Motivation

In some environments, such as air‑gapped systems or restricted networks, it is not possible for tools to perform online certificate validation (e.g., CRL or OCSP checks). When working with osslsigncode in these environments, the primary requirement is to attach or inspect Authenticode signatures without performing trust validation against external infrastructure.

Additionally, some workflows rely on private PKI or self‑signed roots that are intentionally not installed into the host operating system trust store. In these cases, signature inspection or attachment may still be needed, but trust verification will fail unless the private root is added to the system store, which may not be desirable or possible.

Current behavior makes it difficult to perform operations such as attaching or inspecting signatures in these scenarios without triggering validation failures related to:

• CRL/OCSP checks that cannot be performed in offline environments
• Trust verification failures when the signer chain is not present in the system trust store

This limits the usability of osslsigncode for offline analysis, controlled build environments, and private PKI workflows.

Proposed Change

Introduce options that allow users to disable certificate revocation checks and trust verification when attaching or inspecting signatures, specifically for workflows where validation is intentionally handled elsewhere.

Possible CLI flags could include options such as:

• --no-crl or --no-revocation-check
  Disable CRL/OCSP verification so signatures can be processed in offline or air‑gapped environments.

• --no-trust-verify
  Skip validation against the host system trust store and only parse the signature and certificate chain without enforcing trust.

These options would allow osslsigncode to:

• Attach existing signatures to binaries
• Extract or inspect signatures
• Work with signatures generated using private PKI or self‑signed roots

without requiring the certificates to be installed in the system trust store or requiring network connectivity for revocation checks.

Importantly, these flags would be explicit opt‑in, ensuring that default behavior remains secure and standards‑compliant.

Additional Notes (optional)

Example scenario:

• A build system operating in an air‑gapped environment
• Code signed using an internal CA
• Developers need to attach, inspect, or manipulate signatures using osslsigncode
• The internal CA is not installed in the host trust store and CRL endpoints are unreachable

In this scenario, the ability to disable revocation checks and trust verification would allow the tool to be used for signature handling without modifying the host system configuration.

Related concepts in other tools often include flags such as --no-check, --no-verify, or --offline modes that allow processing signatures without enforcing trust validation.