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.
Related
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 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).
I am supposed to fulfill a common-for-most-developers request to build/consume secure services using ssl/tls... via various communication protocols, not necessary wcf (web) services.
My problem is that I don't know much about certificates and I have been trying to get my background knowledge up to speed on the entire process.
The organization I am coordinating with issued 3 files for me to use:
AppName.cert.pem
AppName.csr
AppName.Key.pem
and also gave me a password for these.
The organization also gave me another certificate:
Organization.cert.pem
which is supposed to be used with their test tools.
The scenario is that the organization provided a test suite that runs on one vm, and the software I am building on another. I am supposed to import both of the certs into the vm with my software, and I think the organization's cert into the vm with the test software.
Problem is I don't know how, and the help links they provided are pointing to OpenSSL and some Java2SE tracing the secure requests/responses from either side....
Well, my code is written in C#, and both VM's use Windows Server 2008R2 x64 Standard/Enterprise. I am not sure how to import the certs, and configure them a) on a per application basis for a specific PORT and b) per domain basis?
Thanks,
Any help and guidance would be greatly appreciated!
Well, I downloaded the OpenSSL windows client and converted the AppName.cert.pem, AppName.csr AppName.Key.pem into a single consolidated AppName.PKCS12.
I later imported the result using the Cert Manager (MMC Snap In) in each WS2008R2 VM environment and it worked just fine.
It turns out that the Cert Manager also does understand what is a *.cert.pem file so I was able to import the Organization.cert.pem as well on both VM's.
Thanks
PS: Never read instructions about Windows config written by a Linux/Unix nut-job. This whole exercise of certificate management would've been easier if the person that wrote the test software manual (which I ported from Linux by the way...) didn't send me on a wild goose chase due to his lack of understanding of the capabilities of the Windows Server Environment... No need for OpenSSL.
<bleepzter/>
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.