Recently, when i use Chrome to visit github, i meet the following error.
Cannot connect to the real github.com
Something is currently interfering with your secure connection to github.
Try to reload this page in a few minutes or after switching to a new network. If you have recently connected to a new Wi-Fi network, finish logging in before reloading.
If you were to visit githu.com right now, you might share private information with an attacker. To protect your privacy, Chrome will not load the page until it can establish a secure connection to the real github.com.
It works well in Firefox/Safari, my desktop environment is Mac OS Mavericks,
anybody can help on it?
Many thanks
You need to delete the expired certificate from your login keychain, and restart Chrome.
Here is the DigiCert link that explains how to do it.
https://blog.digicert.com/expired-intermediate-certificate/
On July 26,2014 at 12:15 PM, some customers and users on sites secured by DigiCert reported that Mac OS X systems were experiencing certificate chain errors due to what appears to be a bug in how the Apple OS handles expired intermediate certificates in the SSL trust chain. Customers on Windows and other platforms have not reported any issues.
The problem actually affect any client platform with a locally cached intermediate certificate.
Related
I have little experience with DNS and its related systems. I have a business website running on a server at my house, and as a side project setup a local DNS cache and zone that allows me to connect locally using my remote domain name. Bind9 on ubuntu.
It works. On Iphone safari, there are no issues. Using the domain to connect samba shares has had no issues. But on my computer google has some issues. After immediately opening chrome everything works, and I can access the site. However after a minute and for no apparent reason I can no longer connect.
Is google chrome switching to another DNS server? Can I change this in settings? Google chrome settings has an option relating to secure DNS. Does this not allow it to connect to a DNS server that doesn't have some encryption? Thanks.
When i tried to open my site (https://thaimeditationcenter.com/) by Google Chrome on My mac using macOS Sierra Version 10.12 i got an error like this.
Your connection is not private
Attackers might be trying to steal your information from thaimeditationcenter.com
(for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Automatically report details of possible security incidents to Google. Privacy policy
But when i open it on Firefox , Safari or Google chrome on my Iphone it seems fine there was no error at all.
How can i fix this?
Thanks!
According to SSLLabs your site is not configured properly:
Chain issues Incomplete
This means that a chain certificates is missing. Some browsers cache chain certificates when visiting other sites and therefore can work around this problem. Other browsers try to download the missing chain certificate. The rest will fail because the trust chain cannot be built.
To fix this you need to add the missing chain certificate to your server configuration. While doing that you should probably also fix all the other problems shown by the SSLLabs report which lead to a bad Grade F for your site.
We're using Jetty 9.2.x in the embedded mode in conjunction with Restlet 2.3.1 to develop our application sever. Recently we've enabled support for HTTPS, which utilises a certificated signed by a self-established CA.
Everything seemed to be working correctly when connecting to this server from various web browsers under Linux and Mac operating systems. However, when we expended out testing to machines running Windows 7 and 8 (all machines are on the same LAN), we've discovered that the Chrome browser (ver. 42.x) would not establish a connection, reporting
This web page is not available
ERR_FAILED
The webpage at https://host_name:9999/ might be temporarily down or it may have moved permanently to a new web address.
Trying to analyse TCP/IP messages between the browser and the server suggests that HTTPS handshake does not succeed. Surprisingly, everything works correctly under Windows XP.
Unfortunately, we're not sure how to proceed any further in trying to solve this problem. Any suggestions as to a possible cause or a solution to the described situation?
It has also beed observed that Firefox under Windows 7/8 was able to establish the connection, but did not render the page due to lack of HTML5 imports support. This was confirmed by observing the page source from Firefox.
Edit: Configuring Jetty to use a self-signed certificate resolved the connectivity problem. This suggests that there is some issue with signing a certificate by a self-established CA, which seems to be specific to an operating system/web browser combination.
It has been identified that the originally used certificate was at fault. More specifically, its Common Name contained a value, which was not recognised as a suitable domain name. Generating a new certificate, signed with a self-established CA, but providing a suitable (albeit not registered) domain name in property Common Name has solved the problem.
The very original intent for thus issued certificate was to use it for internal development purposes and not for public consumption. Thus, the Common Name property was entered to reflect the local nature of the certificate (e.g. application-name.local).
I've got a web site that uses SSL Client certificate authorization.
All client certificates are generated using OpenSSL and are self-signed. Everything worked with all web-browsers, but the recommended one was Google Chrome, because it uses same SSL warehouse as IE, so certificate installation was pretty easy (click-click-password-done!).
After last update of Google "Chrome 29.0.1547.57 m", noone can access my web-server, even me.
Google chrome error only! IE and FF working fine.
Error is: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.
Same in server error log.
Do you have any suggestions?
The problem is that most part of clients are non familiar with PC's and they got very frightened about that situation. So phone support guys are under the wave of calls.
We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP
negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384)
hash function.
We found that Chrome fails when it receives "client certificate request" following SERVER HELLO.
SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic
packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.
Invoking Chrome with "--enable-logging --log-level=0" outputs the following message:
ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816
This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.
I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.
Anyone else seeing this?
EDIT:
I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?
I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).
EDIT2:
Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.
I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.
The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.
To do the reset:
In Keychain Access app right-click each private key that fails and select "Get Info".
Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.
It is combination of Win XP and Google Chrome 29.0.1547.57 m
On Win 7/8 this problem doesn't occur.
You could install older working version 28.0.1500.95
http://www.filehippo.com/download_google_chrome/15657/
But settings for disabling updating are not so easy.
http://dev.chromium.org/administrators/turning-off-auto-updates
The problem is caused by Chrome running TLSv1.2 on Windows XP.
This can be disabled on the server side but also on the client side.
To run Chrome with a lower version of TLS, start it with the command-line option --ssl-version-max=tls1.1
I had this problem Connecting Chrome with WebSockets to apache throw proxy_wstunnel_module.
My solution was configuring httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets does not like the parameter SSLVerifyClient optional
I hope this helps.
I'm having a strange problem with a separately hosted subdomain I have. I'm running an application on Engine Yard, let's call it mysite.com. I have a wildcard SSL certificate installed there which covers all the subdomains (things like api.mysite.com). We recently decided to migrate our blog to be hosted independently (right now it lives on wordpress.com). Because I can't run the blog alongside our Rails app with ease on Engine Yard, I decided to grab some cheap hosting space from Dreamhost to host our Wordpress blog there. I set up the server there to fully host our subdomain (let's call it blog.mysite.com), and updated the DNS A record on Hover (our DNS provider) to point blog.mysite.com to the Dreamhost server. So here's the issue:
If I go to blog.mysite.com via Firefox or Safari on my Mac I see the basic Wordpress install which I set up. However, if I try to view things with Chrome I get the following error:
This webpage is not available
Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out.
This happens on all Macs running Chrome I could get my hands on. I tried both clearing the cache and flushing the DNS but nothing. The weirdest part is Chrome keeps looking for https://blog.mysite.com instead of http://blog.mysite.com. There is no SSL cert installed on the subdomain for the blog on Dreamhost because it's not necessary.
Has anyone ever come across this before? And in case anyone wants to try the actual address is http://blog.frestyl.com.
sounds like you have a 301 permanent redirect that Chrome registered http://blog.frestyl.com -> https://blog.frestyl.com. Besides clearing the cache I'm not sure what else can be done.