When upgrading our solution from VS 2019 to VS 2022 and to .NET 4.8 on one of our machines the signing of a Word Add-In does not work any more. The machine was not in use for half a year so it could also be some other update stuff or so.
The csproj file has now <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
First I got another error that I could overcome which is described here
Then I got the error error MSB3482: An error occurred while signing: Only certificates using RSA encryption are valid for signing ClickOnce manifests.
By googling I found that the error (following some translation files and the error message identifier SecurityUtil.OnlyRSACertsAreAllowed) probably comes from here in line 675
But I don't know what to make of it. EDIT: This certificate also works on other machines so there has to be some environmental issue other than the certificate content.
The used certificate has not changed and looks normal to me.
Considering the comment of Crypt32 I can say that this is a self owned Root CA that is only for development purposes. The Add-In gets re-signed later on with a better certificate. The algorithm state
Anyhow the reason for the icon of the dialog showing a red X is probably because this Root CA is not fully trusted (see last screenshot). Of course I should not enable full trust with such a certificate. On the other machines this certificates is also not trusted so this should not be the problem here.
I also saw that the private key for the certificate was not imported into my certificate store. I then also imported the private key but there is still the same error during build.
The public key says RSA 1024 bit if that is what you ment
Crypt32. Maybe the number of bits is too low?
EDIT:
The short answer: I had only imported the public key parts of the certificates into the certificate store and thus could of course not sign the Add-In with the missing private key. The build error message could definitively be improved.
It looks like the import of the private keys to the certificates needed some time to kick in.
Related
I have some difficulties to understand the difference between code signing and PKI.
Is it possible to use a PKI (with a hierarchy of CA) to issue certificate used to sign code source, and then use the revocation to invalid some software (for instance an old version that should not be used) ? Or are X.509 certificate incompatible with code signing and i'm missing something ?
Thanks your very much.
The PKI is an infrastructure that allows you to issue certificates with which you sign your binaries (among other things). You don't sign the source code.
You can create a separate certificate for every software release you have, however, I didn't see anybody use it this way and for that purpose.
Usually you enroll a few certificates and use them to sign all releases until they expire.
Even if a certificate does expire, it won't prevent from the customer keep using your software.
I came across very little literature to use code signing certificates without a private key being exported. Hence, requesting some basic info regarding including the code signing certificate in the installshield 2013 to sign our setup.exe file.
So it goes like this...
We had a certificate from Symantec and/or Verisign that expired a few days ago. So we got a new certificate from them which is a SHA-256 cert. However, they won't release the private key. Hence we cannot generate a .pfx file which used to include in our installshield. They say that, here on who ever wants to do the code signing using installshield needs the dongle attached to the computer to get the private key verification done. I don't quite understand what they mean. However, it is clear that they want us to connect with the dongle for private key verification. So if I do not have the pfx file, how can I achieve code signing using installshield 2013? I also read on the Web that the support for SHA-256 certs was not available in 2013 and that one would have to migrate to 2015 or above to do something of that sort. So we have hit a roadblock with this thing and our automated build process is failing.
Hence, request you to provide me any pointers as to how can we get this thing done.
Thanks and Regards,
Bhushan.
InstallShield 2015 or so added support for signing using certificates from certificate stores. Before that, some people have intercepted the call to signtool, implementing their own calls to either the real signtool or the APIs it calls. This should give you the freedom to use your dongle-based private key, or anything else you need.
(On the downside, InstallShield 2015's and later implementation doesn't let you do this interception trick.)
Ok...So it goes like this...We have a rights issue. As per Symantec, only the person who is the owner of the certificate, can generate a private key on his machine with his admin privileges and that too using IE 11 browser. Now the issue is, the certificate request goes to a helpdesk portal, pending an approval and then forwarded to symantec after the necessary approval. Looks like the approver has to act as the owner, even though the requesting team has paid for the certificate. That is weird but true. So the person who receives all the certificates first hand has to download the certificate, export the certificate along with the private key into the .pfx file and then send us the .pfx! Meanwhile, is there any possibility that I run the export certificate wizard from the browser and the export .pfx option is disabled just because the user launched the browser with insufficient privileges? How may I confirm that this is a rights issue? Thanks.
Further to these, I simply have a very general question about signing. The thing is, even though I know what code signing is and some of the applications might absolutely need it, I do not see a substantial need for the windows based desktop applications. I may be wrong on this. However, all the literature I see points to the fact that the authority that is publishing should be trusted. Now we as a team are responsible for a suite of desktop applications that are being packaged using installshield and code signed by Symantec SHA 256 class certificates. We only sign the set.exe file and as a result it shows a typical trust prompt to the user who installs our software. Our users are a rather closely knit group of clients and are easily approachable. Also, I do not see a risk of our network being intercepted and hacked to tamper the content of setup. In such a situation, is having a certificate justified?
I have a few questions with respect to SignTool as well. I understand that the signing for our certificate is currently failing because we have not yet procured the private key for it. However, the timestamp verification is also failing for a self signed certificate that I have generated for testing purposes. So I need to understand what exactly is a timestamp doing in installshield when Signtool is invoked? Installshield is a good product; however the supporting documentation provided by Flexera is rather pathetic. Thanks.
I have published a basic unsigned windows form application using ClickOnce on Visual Studio. I took the .exe file and .exe.config file and moved it to a folder on my desktop. I signed the .exe file with a legitimate digiCert signing tool, and I created the application manifest and deployment manifest using MageUI and signed it with the same signing tool. I moved all the files to the FTP server that I want the users to download from. When I enter the URL in the browser everything works fine, but it prompts me to Install, and it says that the Publisher is Unknown. After I click install, the app runs as it should.
Also, I have already added my certificate to the Trusted Publisher store, and verified that the issuer of my certificate is in the Intermediate Certification Authority store, and their issuer is in the Root Certification Authority Store.
I have also opened the deployment and application manifest using notepad, and can see my signature on them, and I can see that my .exe file is signed by right clicking on it and selecting properties, then the signature tab.
I have followed the Steps outlined in this site: https://robindotnet.wordpress.com/2013/02/24/windows-8-and-clickonce-the-definitive-answer-2/
I used the : "#1: Signing the application executable post-publish." steps.
So my main question is why is it saying that the publisher is Unknown when I download and run the .application file?
Note: that the SmartScreen filter is not picking up my app as being unsafe
I have (sadly) the same problem.
Microsoft doesn't accept anymore the SHA-1 certificate since 1. january 2016:
Windows Enforcement of Autheticode:
Code Signing Certificates: Windows will no longer trust files with the Mark of the Web attribute that are signed with a SHA-1 code signing certificate and are timestamped after 1/1/2016. With the exception of issuing certificates to developers who intend to develop only applications for Windows Vista, Windows Server 2008, CAs may not issue new SHA-1 code signing certificates after January 1, 2016.
I tried to sign with a SHA256 hash and with a SHA2 timestamp certificate but this is not enough. What I can't understand is why an unsigned exe is threated as more secure as a signed SHA1 exe in smartscreen!
The other answer tells you what's going on, and here's what's working for me. I pivoted another's work for my CI pipeline, but the script can be used in any capacity:
https://github.com/erikest/SignClickOnce
I'm working on an Eclipse-based product and am currently facing an issue when installing plugins on it. Despite the certificates being issued by VeriSign (and the plugins being properly signed with the certificate on export), when installing the "Do you trust these certificates?" window still pops up.
Now, the question is, is this the expected behavior? I was hoping that once we used a trusted CA then we wouldn't have to deal with users facing this dialogue. And if not, any tips as to where I should look to start fixing the problem?
You can find images of the trust certificate window here and the details for the cert here
Short answer: Your certificate is missing an e-mail field in the subject.
When we moved to using a software vendor certificate from an individual developer certificate, we encountered the same problem. The only difference between our certificates is that the individual developer cert has an e-mail address in the subject (the field named "E") and the new software vendor cert does not. GlobalSign allows you to reissue certificates, so we reissued our software vendor certificate with a generic e-mail address in the subject field. That fixed the Eclipse problem and customers no longer see the "Do you trust these certificates?" window.
By the way, our certificate does not have an Organizational Unit defined, and that does not cause problems with Eclipse.
I work for a company that sells USB devices and provides drivers for them.
In Windows 7, you could install and use unsigned INF driver files for USB devices as long as they didn't add any code to the kernel. Our company uses generic drivers provided by Microsoft (usbser.sys and winusb.sys), so we never needed to sign our driver packages.
Based on a report from one of our customers and from another Stack Overflow question What changed in the driver signature requirements for Windows 8? and the Arduino forum, it sounds like the Windows 8 Consumer Preview has stricter signing requirements that require all third-party INF files to get signed. The error message people are getting when trying to install drivers that worked on Windows 7 is:
The third-party INF does not contain digital signature information.
What is the official word from Microsoft that confirms that the signatures will still be required in the final version of Windows 8? A sentence or two from MSDN.com would be sufficient, but I can't find anything.
I am considering buying a signing certificate, but before I pay $200 I want to be sure I will actually need it in the long term. It's possible that the new signing requirement is just in the consumer preview and not in the real version?
To answer my own question: Yes, the final version of Windows 8 does require all INF files to be signed, but you do not need to submit your drivers to the WHQL. I wrote about this requirement and much more in my article Practical Windows Code and Driver Signing.
Not only does it require signing of INF files, it also requires them to be signed by the WHQL certificate, not the same one that you use to embedded-sign .sys files and the like. Using my Code Signing certificate on the INF file didn't work at all. (Same problems as if left unsigned.)
EDIT:
This is what Microsoft wants you to think. They said that certain classes of drivers HAVE to be WHQL signed, otherwise they won't work, and that Authenticode signing works only for those who don't have a WHQL process.
It turns out you CAN Authenticode sign driver packages, except you have to take care and sign them like you would kernel code now, which means getting the correct cross certificate for your CA (from Cross-Certificates for Kernel Mode Code Signing, there are tons of them now, including StartCom, which I have (class 2, US$60 for two years, but they can't be timestamped). Supply this cross certificate (not the same as your CA's self-signed certificate, or their intermediary certificate. It's only available on that MSDN page) to SignTool via the /ac switch.
Then use SignTool verify with the /kp switch to see if you cross signed them properly. SignTool verification with without any switches REQUIRES that the .cat files are WHQL signed, while the /pa switch, which seemed to be OK before, is now too lax, and only applies to non-driver signing (like EXE files, ClickOnce, etc.).
If you don't want to acquire your own kernel-level signing certificate (which is easier now than before, frankly, before it was limited to VeriSign's super expensive, and GlobalSign US$200-a-year ones, I guess Microsoft saw that not many people wrote kernel-level exploits for x64 systems), you can make a self-signed root CA, have your driver installer install it into the LocalMachine's "Trusted Root Certification Authority" store (see certmgr.exe), and then install the .cat file which was signed by that. Of course, since this isn't a kernel-level code certificate, you MUST use only .sys files which already have an embedded kernel-level code certificate from someone else (which means, you can only modify .inf files in driver packages). Apparently, there's some loophole that allows self-signed certificates to sign .cat files (if you made your own CA, then signed a certificate with it, then signed your .cat files with that, it won't work like this).
For a suite that does this for every driver INF package it makes, see libwdi, and how their self-signed certificates on cat files allow installation on Windows 8.
EDIT2:
Removed CERTUM "open source" developer certificate mention, as it's not cross-certified by Microsoft (The one you get isn't the Certum TRUSTED NETWORK one, that Microsoft cross-certified).