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).
Related
We are using Applet previously to get Key Store Certificates installed in client's machine. Now as chrome stops NPAPI, Applet is not working now, so finding some solution using Javascript / jQuery.
I am trying to get the total Certificate List for installs in KeyStore, but I can't find any solutions. Does any one know how to get the full Certificate List using JavaScript or jQuery?
You cannot do that with JavaScript running in the client.
See the following entry of the WebCrypto mailing list:
On Wed, Jun 24, 2015 at 1:50 PM, Jeffrey Walton
wrote:
I see the WebCrypto API will allow discovery of keys
(http://www.w3.org/TR/WebCryptoAPI/):
In addition to operations such as signature generation
and verification, hashing and verification, and encryption
and decryption, the API provides interfaces for key
generation, key derivation, key import and export, and
key discovery.
Certificates have public keys, and they are not as sensitive as private
keys.
Will the WebCrypto API allow discovery/enumeration of certificates?
Examples of what I would like to discover or enumerate (in addition to
the private keys):
Trusted roots
Client certs
Trusted Roots are in the platform's trust store. Client certs may be
in the trust store.
Thanks in advance,
Jeff
There are no plans from Chrome to implement such, on the hopefully obvious and significant privacy grounds.
Client certs contain PII. Trusted certs contain PII and
fingerprinting.
In modern, sandboxed operating systems, such as iOS and Android,
applications cannot enumerate either, as those platform providers
reached the same conclusion.
So no. Never.1
1 For some really long value of never
Get clone of below link https://github.com/scketches/ffPrintCert
install the jpm
npm install jpm --global
Create build for mozilla
jpm xpi
Upload extension in mozilla locally and check
Fire below url in mozilla
about:debugging
Load .xpi file from locally and check.
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 work at a company who does 3rd party iOS development for various enterprises. I've been tasked with researching a better way to build and deploy code to these enterprises. Based on the Apple TOS, they cannot use an application signed with our Enterprise certificate (they're not "in house"). The code needs to be signed with their (our clients) Enterprise certificate. Here are a few possible solutions I've seen -
1) Send the code to the client, and have the client build it. This is a no-go.
2) Create a library with the application code and send the .so file, and the headers, to the client for building. We're currently doing it this way but are looking at making this easier on the client/us.
3) Have the client send us their certificate, mobileprovision, and .p12 file and then we build the application using their certificate. This could work but could become a management nightmare.
We've come up with an idea that is kind of a mix of these ideas. The idea involves building a customer portal where the client can upload their files (cert, p12, provision) to our Mac server and the Mac will automagically build their application, properly signed. The problem I'm having, however, is I can't seem to find out how to automate the installation of certificates and provisions.
So with that said, does anyone know of a way to install a CodeSign certificate (with a .p12 file) and a mobile provision file from the command line? Once installed is there also a way to remove the items from the command line?
Any help, ideas, and/or input would be greatly appreciated. Thanks!
You should be able to manage those resources in the keychain using the security (http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/security.1.html) command. The script I'm using to control command line builds might be a useful reference: https://gist.github.com/949831
Admittedly I've only ever had a maximum 2 external clients plus my own stuff at one time, so it was mostly only the same nightmare that it usually is by default, but how bad would it be if you had to manually do everything EXCEPT the provisioning profiles? In my experience once the client certs got added I never really messed with them again even with new projects (from the same clients.)
You could handle the provisioning profiles by simply copying the files into ~/Library/MobileDevice/Provisioning Profiles, and deleting them when no longer needed. It sounds like you are already set up to automate that process.
If you're currently installing the provisioning profiles by "dropping them onto xcode" I'd suggest you do it by copying into the folder anyway, because then the file names are preserved and so you actually can tell what you have installed by simply looking at the folder.