During installation of Eclipse (using Eclipse Installer) I get asked "Do you trust these certificates?", listing two certificates for Bouncy Castle (one signed by Sun, one by Oracle) and one certificate for Eclipse (signed by Sun). How can I validate these certificates?
I understand that this are code signing certificates for JCE (Java Cryptography Extension), i.e. certificates signed by Oracle for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. I also know that Bouncy Castle is in common use for providing algorithms related to encryption.
Two questions:
All certificates are signed by the same two CAs, but I cannot find a (public) list of "official" CA certificate fingerprints. How can I validate these?
JCE Code Signing CA, issued by and to Sun Microsystems Inc, valid to 2020-04-25, fingerprint 57:37:D1:E1:16:2F:F6:FE:26:B9:87:88:D2:86:DA:66:7F:98:54:3C
JCE Code Signing CA, issued by and to Oracle Corporation, valid to 2030-12-31, fingerprint F4:B9:C6:4A:52:AD:22:3C:E4:BF:BA:52:52:87:9C:9F:71:1D:4B:33
Why are those CAs not trusted by default, i.e. included in some trust store supplied with the JDK/JRE? The CAs are operated by Oracle (at least the CA certificates say so 😉), the JRE I'm using is provided by Oracle (openjdk 11.0.2), I see no reason the CAs should not be trusted (given they are indeed legit).
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'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).
this is mostly a deployement than a programming question.
If I were to buy an SSL certificate from a CA, would I be able to use it to sign other applications (such as symbian, android, iphone ones)?
You need to get two different certificates. One to secure a server (https) and one to sign code. You can compare code signing certificates here
Server certificates (those that you'd use to enable HTTPS on a web server) are rarely enabled for code signing. I haven't looked at every CA in the world, and there probably are exceptions, but the more "legit" a CA is, the less likely they are to issue one certificate for both applications. In the end, I wouldn't expect to use the same certificate for both.
There is a better chance that a single code-signing certificate is accepted by most platforms. The developer documentation of each platform should list what CA certificates are built-in as trusted roots. In addition, most platforms will allow a user to view and modify the list.
You need to buy a certificate that is specifically authorized for code singing. In other words, the certificate must have the Extended Key Usage (EKU) for Code signing. Object ID (OID) for code signing can be found here
Most commercial CA's should be able to tell you which of their certificates have this.