On certain sites the certificate chain can not be built up to the trusted root certificate because this trusted root cert is not known to Windows. But if we visit such site using IE or Chrome, Windows automatically downloads (verified) the trusted root somewhere and silently installs it to Trusted Certificate Authorities storage. After this we can build the certificate chain up to the newly installed root. If we manually remove newly downloaded trusted root certificate from Windows storage, the chain can't be built again.
I know about Authority Information Access extension. The problem is that the topmost available certificate in the chain (the child of missing trusted root) does NOT have such extension included. And even if it had, Windows would not automatically trust the downloaded certificate.
So there must be some other source of knowledge about trusted roots. The question is - how can we use that source ourselves. The topmost available certificate is available here if anyone is interested in inspecting it.
This link http://support.microsoft.com/kb/931125 explains how Windows updates root certificates silently in Vista and 7.
I also stumbled on this multiple times. It can be reproduced easily using windows sandbox. If you use curl or similar certificates can not be verified. Only if you call WinHttpOpen the root certificate (if trusted) will be added to the root certificate store.
See this post
Certificates contain an extension called "Authority Information Access" which contains the details of the issuing CA. An example of the certificate used for "https://gooogle.com" is shown below. The browser reads this value, downloads the certificate from the URL provided and repeats the process up the certificate chain.
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 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 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 am trying to add one of our root cert in the trusted store of the iOS. I am just curious if this is possible to do at the compile time? I have seen different versions of people creating p12, but genuinely I just want to add it to the trusted store, so the server can recognize during the SSL handshake that this is a trusted domain.
Thanks
no you cant add it as a trusted root - not at compile time or runtime either
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.