Page MenuHome GnuPG

Gpg4win windows publisher signature not always correctly displayed in UAC dialogue
Closed, ResolvedPublic


The publisher of the package is not displayed correctly during an install (on some windows installations and browsers). So the user account control (UAC) dialog, when a user wants to install gpg4win just shows that the creator of the package is unknown.

The problem only occurs on some windows installations and with some browsers after opening the Gpg4win 3 installer after downloading it.

Reproduced with Webbrowsers Firefox and Iridium (a chromium build) on

  • Windows 7 DE, 64 bit
  • Windows 10 HOME, 64 bit


  • After inspection of the security details of the file (e.g. via the explorer, file properties) the problem goes away for this installation. (<- Workaround)
  • Using the webbrowser Internet Explorer it works right away.

Event Timeline

I suspect CRL / Root certificate fetching because it works after you once manually investigated the certificate chain through -> Properties -> Digital Signatures.

I also doubt that this is a real world problem because we have not seen complaints from the community about this. I've checked our installer with the Windows App Cert Kit and while it complains about some errors regarding failed injections of load DLL's I suspect these to be setup errors in my VM. On Stackoverflow I found threads that also said that they had to set up a clean new System to get Windows App Cert Kit to verify correctly.

Initially I suspected SmartScreen which builds Reputation after installed Software counts. But AFAIK Intevation's certificate has high reputation even though it's not EV because of all the Gpg4win installations.

Maybe an EV Certificate would help but I doubt it because it should not have any effect on Windows 7.

Note that the script used to sign the beta's is exactly the same that was used for Gpg4win-2.3.3 and Gpg4win-2.3.4

@aheinecke thanks for your findings.

My hope also is that it is a small issue, however I've wanted this task to keep an eye on the situation.
(As long as I encounter machines where the display does not work, others may as well.)

One change we had was the switch to a sha256 certificate at one point.
Before I don't remember reports about the issue (but my memory could be wrong).

werner added a subscriber: werner.

I would suggest to close this report even that I have the same problem with the g10 Code cert on Vista - but it used to work when I bought that cert.

We recieved another mail by a customer about this issue today:


I found the code sign certificate chain of “gpg4win-3.0.2.exe” is

When I first execute the installer on a new windows system (win10 x64 ),
Windows show me “verified publisher: unknown” .

After I download and open “GlobalSign CodeSigning CA - G2 Intermediate
Certificates”, windows show me all fine.

If you are encountering the problem, please

  1. Check that you have updated your Windows operation system to the latest version and you've got all security updates. (As some necessary certificates may have come later with an update.)
  2. Does the behaviour change if you "investigate the certificate chain" through -> Properties -> Digital Signatures?

So I can reproduce the problem on a Windows 7 virtual machine with all important updates up to the 5th of February, 2018.

It happens when I use the old Firefox (41.0.2) right after starting up the box, download Gpg4win and then open it directly via Firefox's menu. Using IE to download the same file, there is an explicit status line saying that a security check is made and then the UAC is displaying the signature information.

My hypothesis is that either

  • Firefox misses to call some function necessary to trigger the security check when opening the file.
  • (or less likely) it takes a few minutes until some revocation information has been loaded in the background

Observation: When downloading a new version of Firefox, there is another dialog before the UAC comes and the following UAC is fine then. Question: Why does Gpg4win3.exe directly goes to the UAC and firefox.exe triggers a different dialog?

The latest Firefox 58.0.2 also has the problem so has Iridium 2017.11 (a build of Chromium 62.0.3202.94 for windows).

Conclusion: There is something that Firefox and Chromium do different than IE and there is a difference in how Gpg4win installer
is handled compared to the Firefody and Iridium installers. I've noticed that the UAC dialog for the Iridium installer comes after their setup application has already started. So overall this seems to be something that could be solved by changing the Gpg4win installer.

Another observation: Just opening the file from the explorer is not enough, but once I was on the details of the digital signature, opening works. So for whatever reasons Firefox and Chromium do not trigger the security check.

Workaround: Trigger the security check

If the there is an unknown publisher shown in your user access control (UAC) dialog, open the directory in the explorer, right-click for the properties of the file and then check the details of the digital signature. Next time you open it, the publisher will be shown.

Here is the firefox warning

. For Gpg4win there is no such warning.

bernhard renamed this task from Gpg4win windows publisher signature not always correctly displayed in UAT dialogue to Gpg4win windows publisher signature not always correctly displayed in UAC dialogue.Feb 19 2018, 10:12 AM
bernhard raised the priority of this task from Low to Normal.
bernhard updated the task description. (Show Details)
bernhard updated the task description. (Show Details)

On saturday I could observe the problem with a fresh Windows 10 Home edition.

bernhard closed this task as Resolved.EditedSep 17 2020, 1:50 PM
bernhard claimed this task.

Last report more than two years ago.

And we've added a hint to our documentation to use the workaround.
"Microsoft will normally display the code signature in an user account control dialog when you try to execute the downloaded file; alternatively you can take a look in the file properties with the explorer."

The idea is that a properly updated Windows will work fine. Some of the reproduction was happening on Windows in virtual machines, which may not have been properly updated.

So good enough. :)