I'm currently looking at how my company signs our files. Currently we use an EV
certificate to sign almost every file in our installer, including the installer. I'm new to this code signing stuff so I may get somethings wrong.
Unfortunately signing with an EV cert makes our CI system more complicated and has introduced the occasional failure. The dependencies on the EV cert is a bottleneck may prevent our system from scaling. We still want to sign all our files, the question is do we need to sign all the files with an EV cert?
Is it a bad idea EV and OV certificates, for example use an OV certificate on the installed files, but EV for the installer and Iso?
What about certificate rollover, will that be a problem if we start signing with an OV cert?
Any other problems that may occur when switching from an EV to an OV cert for the installed files?
Most of what I've found compares the two types but doesn't talk about when one should be used over another, when an EV really should be used over an OV, or if it's ok to use an OV cert.
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 gather that most developers (except perhaps for larger companies) use self-signed certificates to sign their apk. Since this is required for app installation, the ability to sign your app is available to anyone. Fairly simple to use keytool and jarsigner from Java SDK. However these self-signed certs and associated private keys do NOT guarantee any degree of security unless you can somehow match that certificate with someone you actually trust. There is no ability to revocate these self-signed certificates (no CRL) and there is no "issuer" (since the certs are almost always self-signed) who "vouches" in some way for the identity of the certificate/key holder who signs the code.
So does Andriod platform have or plan to have any ability to prevent installation of apps SIGNED WITH A PARTICULAR SIGNATURE? or to enable settings only allowing installation of apps signed by a cert/key issued by a list of trusted CA (certificate-authorities/issuers) ?
However, there is some security available: In settings/Security you can prevent installation of anything (even signed and manually copied to your SIM) unless it comes from the Play Store, the default setting. Also you might be able to install a User certificate and ONLY allow apps signed by that cert to install (even if from the Play Store?).
I dont think the purpose of these certificates is to ensure an identity as a normal certificate signed by a CA would. As it seems to me the purpose of the certificates is just to have an extra security factor to ensure that the person that published the app for the first time is the one that publishes updates.
Without this someone that hacks your google account would be able to publish malicious updates to you entire user base.
So I would say its basically a two-factor authentication for publishing.
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).