5

I have a valid unexpired code signing certificate (standard, not EV) that I have used to sign a click once app (.net 4.5) successfully and publish to a web server for download. When downloading this app, it shows the publisher name correctly. The problem is, after installing the code signing certificate on any other app, it shows the publisher name as "Unknown publisher" when downloading. There isn't any difference in how I'm installing the certificate and all apps get published to the same web server. When I open the .exe or manifest file when logged into the web server, it shows the publisher name correctly. Checking the "Digital Signatures" file properties shows that they are signed with the correct code signing certificate with sha256. Below are the steps I have used:

  1. Installed code signing certificate to click once app via the Signing tab and it is enabled (Visual Studio 2017 Pro).
  2. Code signing algorithm is sha256RSA with valid timestamp server (http://timestamp.comodoca.com/?td=sha256).
  3. Click once app assembly is not signed.
  4. Code signing certificate has been installed on dev machine (Windows 10 Pro 1809).
  5. Code signing certificate has been installed on web server in "Trusted Root Certification Authorities" and "Intermediate Certification Authorities" (Windows 2012 R2 using IIS 8) for the "Computer account".

On a side note, I exported the code signing certificate from Internet Explorer with SHA1 and installed it to the web server afterwards. There is a known issue that when the certificate has been exported to SHA256 and trying to import it to the web server, that the password for the file will always say incorrect. This happened to me, so I just imported the SHA1 version to the web server. Not sure if that would create any issues, but it is working for the one clickonce app ok.

Update: I noticed something peculiar if I go to the publish deployment URL and click the "Install" button. After the setup.exe has been downloaded for the clickonce apps with "Unknown publishers", I am presented with a more dire smart screen filter saying the file is not signed, but shows the correct publisher information below it. Checking the "digital signatures" property for the exe shows that it is signed properly.

Jakal
  • 62
  • 2
  • 13
  • 1
    Can you share the executable? Are you saying you signed your app with a SHA-1 certificate? Those are deprecated. You might be in a situation where something signed before the deprecation date is still accepted as long as it's not expired, but something signed after the deprecation date is not accepted. – kichik Jun 26 '20 at 20:29
  • If you can't share the file, can you run `signtool verify /all old.exe new.exe` and post the result of that? – kichik Jun 27 '20 at 02:15
  • Thank you kichik for your responses. I ran a verify command on the setup.exe for all the apps, and each one showed a "SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." message. I have the certificate installed on the web server and my local machine in the "Trusted Root Certification Authorities" store. – Jakal Jun 27 '20 at 14:41
  • Do you have the root certificate in the trusted store? Who exactly created your certificates? – kichik Jun 27 '20 at 17:20
  • I show the certificate installed on my local computer and web server in the "Trusted Root Certification Authorities" store. I was the one who created the certificate by using the documented process of downloading the certificate via Internet Explorer. It was issued by Sectigo RSA Code Signing CA and looking through all of the certificate properties, it shows that it is valid. Not even sure what to try next. – Jakal Jun 27 '20 at 17:58
  • Ok, I tried the signtool verify with some different inputs and got some interesting results. I used "signtool verify /pa /v "C:/setup.exe" and it lists the certificate chain as verified. It lists the timestamp chain as well. The hash of the file is SHA256 but everything else in the chain is SHA1 hash, which I think is ok, since I think that is used to match the file and not used for security purposes? – Jakal Jun 27 '20 at 18:40
  • SHA-1 is not ok. It's deprecated. I really can't help you much further unless you show the full results of those tools, the certificate itself, or the executable. – kichik Jun 27 '20 at 19:13
  • I updated the main post to show the output from signtool. The thumbprints are all sha1 which should be fine. The root certificate signature is sha1. The intermediate certificates are sha384 signatures and sha256 for the "My Software, LLC" certificate. The intermediate Time stamping certificates had a sha384 signature as well. It seems the time stamping certificate chain is starting with the "AAA Certificate Services" root certificate (same as authenticode certificate) which has a sha1 signature, but timestamp server is set to sha256. Not sure if that is an issue. – Jakal Jun 27 '20 at 20:51
  • The code signing certificate is a .pfx file in case that matters. All of the executables show that the signature is sha256. – Jakal Jun 27 '20 at 21:33
  • Did you modify the output in some way? Your AAA root certificate has a different hash from the [real one](https://censys.io/certificates/d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4) by one character. As for your issue, it seems like Microsoft backtracked on their SHA-1 deprecation for authenticode. Maybe try running signtool on a clean computer where you didn't touch the certificate store and see what it says. – kichik Jun 27 '20 at 21:58
  • Yes, I wasn't sure if it was ok to post the hash, so I slightly modified them. In any case, I figured out the problem!! I'll post it below since there is a character limit to these comments. – Jakal Jun 27 '20 at 22:11
  • **I FIGURED IT OUT** Within Visual Studio, click the "Publish" tab, then click "Options...", then Manifests. Uncheck the "Use application manifest for trust information". THATS IT. In my other applications that didn't have the issue, the Publisher Name field in the Publish Options > Description tab matched exactly. For the apps that had an unknown publisher, the Publisher Name field did not exactly match what was listed in the manifest. – Jakal Jun 27 '20 at 22:14
  • Thank you so much kichik for helping me with his issue. I had given up on this, but your help with troubleshooting this was instrumental. I don't see where I can give you the bounty amount that is still in a grace period of being awarded. – Jakal Jun 27 '20 at 22:17

2 Answers2

1

My issue was caused by the publisher name not matching who my code signing certificate was issued to while having the "Use application manifest for trust information" option enabled within Visual Studio. Unchecking that option, or correcting the publisher name resolved the issue. This is further explained below:

Check whether your application manifest is being used for trust information (i.e. publisher name). If it is, make sure the Publisher name in the Description section matches who the certificate was issued to EXACTLY. If it does not match, you'll get an "unknown publisher" issue. This setting is located in Visual Studio in the "Publish" Tab. Click the "Options..." button, followed by the "Manifests" list item.

enter image description here

I would try unchecking the "Use application manifest for trust information" and see if that resolves the issue. If you do need the "Use application manifest" option checked, click the "Description" tab and make sure the "Publisher name" value matches the value of the name the code signing certificate is issued to EXACTLY.

Make sure publisher name matches who the code signing certificate was issued to

Jakal
  • 62
  • 2
  • 13
  • I am also experiencing the same problem. Unfortunately double checking Publisher name to match certificate and unchecking the above mentioned checkbox did not work for me. Running signtool verify /pa /v setup.exe showed the chain. But publisher is still unknown. Any ideas? – Igor Kondrasovas Jan 20 '21 at 21:34
1

I had the same issue - valid EV cert - publisher unknown at download - but install went smooth with no Windows Smart screen.

Changed the build tools from VS2017 to VS2019 seems to have fixed it -> happy.

Hans Karlsen
  • 2,275
  • 1
  • 15
  • 15