Hello,
I am verifying the official Gpg4win 5.1.1 installer before running it. I would appreciate guidance on completing its authentication without manually importing root certificates or weakening validation.
File
- Source: https://files.gpg4win.org/gpg4win-5.1.1.exe
- Size: 44,831,736 bytes
- SHA256, matching the published value:
ed19c0c89ec42fe32c52a7abd6e3da5f491752700546b9eed7ddf82fd303cddf - The installer has not been executed.
Results from a custom verifier
The verifier ran under Windows PowerShell 5.1 x64 with administrator privileges.
- The signing certificate matched the published g10 Code GmbH certificate reference.
- The code-signing certificate chain returned no errors under the implemented checks.
- The timestamp CMS signature and its message-imprint binding to the original signature passed the implemented cryptographic checks.
- Timestamp:
2026-09-23T12:40:18Z. - The timestamp chain returned aggregate status
0x01000060and policy error0x800B0109. - The TSA and intermediate each returned
0x01000040(revocation status unknown/offline). - GlobalSign Timestamping Root R45 returned
0x00000020(untrusted root).
Subsequent offline, read-only inspection
Exact SHA256 lookups did not find the following certificates in the existing Root, AuthRoot, CA, or Disallowed stores under either CurrentUser or LocalMachine:
- TSA — Globalsign R45 TSA for CodeSign 202510:
832ad72e523fdeac83fa4694bce7c6cc261764882866566588c8adca3a838551 - Intermediate — GlobalSign Offline R45 Timestamping CA 2025:
52373a21b95b5e6de12a2bcf0ffb7d6a633b4caad725f64f6236fbe989dbc29e - Root — GlobalSign Timestamping Root R45:
2bcbbfd66282c680491c8cd7735fdbbab7a8079b127bec60c535976834399af7
The TSA and intermediate certificates were present in the embedded timestamp token. The TSA had a critical EKU containing only time stamping. The SigningCertificateV2/ESSCertIDv2 SHA256 digest matched the embedded TSA certificate.
No correlated historical CAPI2 events were found in the narrow verification window. The log was disabled when inspected, and was not enabled or modified.
Important verifier limitations
This was a custom diagnostic implementation, not a completed standard Authenticode verification:
- Chain construction used the default CurrentUser chain engine.
- Automatic root updates were disabled for that chain-building call.
- Revocation checking excluded the root and used a cumulative retrieval timeout of five seconds.
- The timestamp generation time was supplied as the verification time, but
CERT_CHAIN_TIMESTAMP_TIMEwas not set. - Chain policy checking used
CERT_CHAIN_POLICY_BASE, notCERT_CHAIN_POLICY_AUTHENTICODE_TS. - Detailed per-element revocation diagnostics were not retained.
- The verifier stopped at the timestamp-chain failure before calling WinVerifyTrust on the installer.
- The later offline inspection only read certificate presence and token structure. It did not rebuild chains, revalidate signatures or revocation, or evaluate the ESS issuer/serial field.
Therefore, I am not claiming that the installer is corrupted, that a certificate is revoked, or that disabled automatic root updates are the proven cause. Full Authenticode authentication remains incomplete.
Question
What supported verification procedure do you recommend for this exact installer and timestamp chain? In particular, how should I distinguish the local root-trust issue from the inconclusive revocation results while correcting the verifier’s limitations, without manually trusting a downloaded root or disabling security checks?
Thank you.