We had to update our certificate for our ecommerce website recently and ever since we've noticed weird behavior in Firefox and other browsers. About half the computers in the office, as well as my home computer complain that the certificate chain is not complete (Very odd it's not universal). I can view the chain in the Firefox certificate viewer and see that it doesn't have a chain.
Meanwhile Chrome's chain looks fine. This leads me to believe that there isn't an issue with our install of the certificate, as there's a chain there to be read, but Firefox can't seem to see it.
I should note that it seems to have the same issue in Chrome on Android.
So is this our problem or Firefox's?
This is typically the case when the server does not send all necessary intermediate certificates. Chrome on Desktop will go and fetch them. Firefox will use any intermediate certificates cached from previous connections to other sites but will not fetch missing certificates, thus some Firefox instances might work while others not. Chrome on Android will also not fetch missing certificates.
The issue needs to be fixed on the server side. If you check the server at SSLLabs you will probably see a note regarding "chain issues". Add the necessary certificates (they are listed at the report) until you don't see this note any longer and then it should work with the other browsers too.
Related
history.go(-1) has no effect in iFrame from different domain, but works in chrome on another machine.
Given a start page with an iFrame from a different domain.
And a FirstIFramedPage.html with a link to SecondIFramedPage in the different domain.
When I click on a back button with onClick="window.history.go(-1)" it has no effect.
However, it does have the desired affect (to navigate the frame back to FirstIFramedPage.html) in every other browser I've tested AND on another machine with the same version of Chrome.
chrome: Version 66.0.3359.181 (Official Build) (64-bit)
I have a fully working example here: https://github.com/jimlesch/ChromeIFrameHistoryFail
the readme.txt has instructions on how to reproduce this issue.
What I've tried:
running in incognito mode.
disabling extensions.
using an iframe from the same domain (works as expected, but not possible in my scenario)
Uninstalling and reinstalling Chrome.
Installing Chrome Beta to see if it behaved differently (still fails for me on 5)
Looking at chrome://tracing (could not make heads or tails of it)
I am looking for help on how to further isolate this issue, since I cannot reproduce it on another windows 10 machine with the same version of chrome. Thanks for any help you could provide.
It would appear this is a chrome bug introduced in field trials of "Site isolation". These field trials get applied to 10% of the stable build (and 90% in beta builds).
I was able to revert to expected behavior by choosing to "opt out" in "Site isolation trial opt-out". This setting is available under: chrome://flags/#enable-site-per-process.
Also see this duplicate bug for a richer discussion: bugs.chromium.org/p/chromium/issues/detail?id=845923
I'm experiencing a weird problem with an EV ssl certificate issued by Comodo.
Basically, the green bar notifying the user that the connection is encrypted with an EV certificate shows up just fine in IE, FF and Chromium version 44 but Chromium 43 shows no green bar (only the green lock). I'm not aware of this problem on other chromium versions, didn't bother testing yet.
Chromium git logs revealed no information possibly related to a fix for this issue nor google search which makes me think it may be a local problem with my server configuration. This is weird though, with all the online SSL testers giving me an A+ grade and all the other browsers working (even chromium itself 44+).
Of course, we have a lot of visitors using Chromium 43.0.XXX browsers.
Has anybody experienced this problem? Can anybody give me a hint at least on how to trace it down to its origins?
Maybe find a repository with all the chromium binaries somewhere and start testing one by one, locating the releases where the issue appeared/disappeared and dig the source code changes? Does such a repo even exist? Because I really don't want to start building all the releases one by one.
NOTE: if i follow the instructions from this ticket, filehippo will redirect me to some google download page from where my only option is to get the current stable, either I don't know how to use filehippo or that thing is broken.
NOTE: if I test with whatever browserstack says it's version 43, the green bar shows up. Assuming I trust browserstack, it may be that the green bar problem has been fixed in some later revs on 43.
Maybe find a repository with all the chromium binaries somewhere and
start testing one by one, locating the releases where the issue
appeared/disappeared and dig the source code changes? Does such a repo
even exist?
The easiest way would be to download and test on portable versions. You can find them at:
PortableApps :: Google Chrome Portable
There are 313 versions on repo, 25 of them v43.0.xx, wish you luck.
Google have announced that they will require Certificate Transparency (CT) for all EV certificates issued after January 1, 2015. If a CT proof is not included either in the Certificate or as part of an OCSP stapled response, the EV certificate will not display the green address bar in Chrome.
Please look into the below links for more info
http://news.netcraft.com/archives/2015/08/24/thousands-short-changed-by-ev-certificates-that-dont-display-correctly-in-chrome.html
https://blog.digicert.com/certificate-transparency-required-ev-certificates-show-green-address-bar-chrome/
I noticed that you have mentioned that it works in version 44. Still I mentioned the Certificate Transparency as this is a known issue.
There has been multiple instances reported where chrome has not shown the green bar. Some have reported this as a bug to google forums. There has been reports of such behaviour on chrome of different versions and on different Operating systems. (Windows,Ubuntu,Mac).But many of these could not be reproduced by google and hence no concrete solution is provided on these forums.
Please check below links
https://security.stackexchange.com/questions/37367/chrome-does-not-show-green-bar-with-ev-ssl-but-firefox-and-ie-does
https://code.google.com/p/chromium/issues/detail?id=226080
https://code.google.com/p/chromium/issues/detail?id=464274
I was till last month using Chrome Browser for testing the screen share feature using WebRTC API. For doing this I enabled the flag "Enable screen capture support in getUserMedia()" in chrome://flags.
Now with recent update of the Chrome Browser, this flag is no more available and most of the other WebRTC flags are disabled. I checked with even Chrome Canary and the result was same. The flags are either missing or disabled with message "Sorry, this experiment is not available on your platform.".
I am neither able to revert to older chrome version.
I would appreciate if anyone can give me a clue as to how enable the above flag for screen capture?
Thanks
You cannot use those flags any longer and there is NO WAY to access them again short of rolling back your update. They were removed for security reasons. Now, you have to use a chrome plugin to do any desktop capture. Which is frustrating but the only way and it is fairly simple.
Here is an another SO question that should give you direction.
Firefox also now has screen/window/etc capture. For now, for similar reasons to Chrome, we've put access to the feature behind a whitelist (though an extension could extend the whitelist as well; we haven't prototyped that yet).
See http://mozilla.github.io/webrtc-landing/gum_test.html (In Firefox 33 or later - currently that's Beta; no attempt to polyfill was done there as it's an internal testing page).
Chrome (on Win and Linux) was unable to load https://apscatalog.com.
Though all other browsers and Chrome on Mac was able to load site with no warnings or errors.
Even external tools say that everything is fine: https://www.ssllabs.com/ssltest/analyze.html?d=apscatalog.com
How can I fix this issue?
Update
It seems to be a Chrome bug. Chrome v.33 works fine while v.32 fails
I would say, that the they have some broken appliance (firewall, load balancer...) in front of it. From wireshark I see the Client Hello from Chrome, but it never gets a response, not even an ACK that the packet was received. That's why it's retransmitting the Client Hello again and again until it finally gives up. I've seen such problems with older F5 BIG-IP load balancers (it's fixed in the meantime, but there are still some broken ones out there) but this does not seem to be the case here. So it's probably yet another broken appliance :(
In case you have knowledge of the infrastructure there I would really like to know what device this might be.
Interesting that https://apscatalog.com works if chrome is started with ssl-version-max=tls1:
google-chrome --ssl-version-max=tls1
We have several FogBugz customers who have reported an error in Chrome where if the user presses Enter in an edit box, the edit box will lose focus and they'll have to click back in to the box for it to gain focus.
All users reporting this error (that we're aware of) have mentioned using Chrome Beta. We don't support Chrome Beta, so we advise downgrading to Chrome Stable. We can't repro the bug on Stable.
One of our users uninstalled Beta and installed Stable. He tried again and was again able to reproduce the bug, even after clearing his browser's cache (with no tabs open) on Stable.
In a related scenario, another member of our team noticed quirky behavior in Chrome persisting when switching from Chrome Dev to Chrome Stable. He also cleared his cache and noticed the behavior persisting in Chrome.
Have any other web developers experienced this kind of behavior in Chrome with customers using their web applications? If so, is there anything you can do within your application to help users and/or do you know of a way to completely "wipe" Chrome and revert it to the Stable version? (at the moment, the latter option is preferred).
Moving up versions should be okay, since Chrome is designed to upgrade smoothly.
Moving down versions (like dev to stable) can be problematic, since there's really no provision for older versions of Chrome to understand new versions of the user directory.
If you want a fresh start, you can wipe your entire user data directory. However, since this directory contains everything about the user (caches, saved passwords, apps/extensions, etc), all of that will be lost.