After upgrading to Windows 10, I am receiving the ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY in Google Chrome (Firefox 39 just doesn't load the page) when I attempt to access my machine over HTTPS. I have a GoDaddy signed certificate for my computer.
I've attempted disabling most of my encryption ciphers per https://http2.github.io/http2-spec/#BadCipherSuites.
I've gone so far that I've disabled ciphers that are keeping me from RDPing to my desktop...and it still gives me an error!
Any guidance is appreciated.
Apparently you are not the only one having this issue: Disabling HTTP/2 / SPDY in HTTP.SYS and IIS in Windows 10
According to the error message this is a SPDY issue, so the certificate and the cipher suites are not the cause.
SPDY is a protocol allowing multiplexing HTTPS requests but it will be replaced by HTTP/2. As a temporary fix, you can apparently disable its support in you browser/registry/server.
I ran into this same issue after my win 10 dev machine got updated twice recently (the updates took around 35-40 minutes to deploy each time) and after this i was not able to run my Visual studio 2015 web applications over Https on Chrome but was able to run on IE
I tried out the registry method for disabling Http 2 as mentioned
here, but this did not worked for me
Then I came across the following solution: I downloaded IIS Crypto and
selected "Cipher Suites" option and clicked Best Practices button, and applied
it, My problem was gone and i can now run my web app over Https in Chrome just like before
Uncheck "Enable SSl" in your project properties under the Debug tab
I solved a similar problem by removing the parameter "Strict´Transport-Security" with value "max-age = 31536000; includeSubDomains; preload" from "HTTP Response Headers"
Related
We're having some issues on some machines related with ssl when connecting to our sites through https. sometimes, some of the users get the err_ssl_protocol_error when they try to load one of the sites. now, the weird thing is that hitting f5 solves the issue and the page that was returning the ssl error gets miraculous loaded. we've already tried most online suggestions (checking date and time, cleaning the browser/ssl cache, etc).
we have changed the ssl certificate recently (a month ago), but the issues have only started now. btw, all our requests go through our firewall (forti adc) which is responsible for enforcing the https to all our clients.
any clues on why we're getting this error?
edit: adding more info
sites are hosted in iis (windows server 2016)
our firewall is running forti adc
the requests go through a load balancer before hitting firewall
the firewall has the wildcard certificate used for ssl (all. sites)
sites are built with aspnet
it only happens on some pcs, and only with chrome (Firefox is working without any problems)
edit 2: More info from wireshark
So, I've used wireshark to capture the traffic and when I get the ERR_SSL_PROTOCOL_ERROR on chrome, I've noticed that wireshark is showing me an alert with a decrypt error in response to the server hello message:
Any clues on what's going on here?
After lots of digging and testing, it seems like there's an issue with openssl and ECDHE algorithms. Changing the algorithm to a non ECDHE seems to have solved the issue for our chrome users...
For the last few months we've has a client site working fine over HTTPS and HTTP, however as of a week or two ago we've had intermittent reports of it failing in Google Chrome.
As of last week I also got the issue, which is Chrome claiming ERR_EMPTY_RESPONSE to all requests sent through HTTPS.
This isn't replicated in any other browsers and the Security tab of the inspector declares the certificate valid and all page resources secure.
Anyone got some suggestions? I'm at a loss as to what to do, it feels like it might be a browser bug itself...
[Originally provided by a user called #daFlame, but it then got deleted within a few hours?]
The issue is caused by Chrome struggling with the cipher suites cPanel uses by default. CPanel are aware of the issue, and I've reported a ticket to Chrome.
CPanel's work around can be found here, but I'll provide a summary:
Go to WHM >> Service Configuration >> Apache Configuration >> Global Configuration
Then find the value SSL Cipher Suite and change it from the default to:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS`
Once Apache is rebuilt, the errors stop.
Since I have updated Chrome from Version 40 to 41, I no longer can access my ssl site running in a local tomcat 7 instance. I have a self signed certificate.
Chrome just prints This webpage is not available together with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
I already tried the chrome://flags switch Minimum SSL/TLS version supported to SSLv3, which did not work.
I had the same problem with my Java EE web application running with a self signed certificate on Wildfly 8.1.
You are probably using a 1024 bit DSA public key with your selfsigned certificate and Chrome stops/stopped supporting DSA(DSS).
Creating a RSA 2048 certificate and using it with your web application should solve your problem.
I doubt its an SSL/TLS protocol version problem. Most of the time this error means the server and client couldn't agree on which cipher to use. Take a look at this blog post: https://blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcat/ on how to enable a secure and compatible cipher suite in Tomcat.
In the Tomcat server.xml file you can set ciphers attribute in the SSL/TLS <connector/> element.
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_RC4_128_SHA"
This solved the problem in my case for ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chromium / Chrome and for ssl_error_no_cypher_overlap in Firefox.
If you came here from Google and since this is the highest ranking 'ERR_SSL_VERSION_OR_CIPHER_MISMATCH' entry:
another explanation is that you started an nodejs https or express server with invalid or empty credentials. The irritating bit is that the server starts without complaining and ssl seems to work, but the negotiation between browser and server fails with this error.
I am able to access a URL in Chrome 36 and IE8 but in Chrome 39 or 40 or Firefox 35 it throws the error:
Unable to make a secure connection to the server. This may be a
problem with the server, or it may be requiring a client
authentication certificate that you don't have.
Error code: ERR_SSL_PROTOCOL_ERROR}.
It seems that it is an issue related to the SSL certificate. How can I fix this?
Google announced that they would begin removing support for SHA-1 cryptographic hash algorithm beginning with Chrome 39. According to Google:
HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
There are several sites which can provide detailed analysis of your SSL certificate chain, such as Qualys SSL Labs' SSL Test.
Google Chrome does have a highly risky command-line option --ignore-certificate-errors which might bypass certain certificate errors. Be aware that ignoring certificate errors puts all of your SSL traffic at risk of being eavesdropped on.
It's also possible that this is a new bug. Google switched from using OpenSSL library to it's own "BoringSSL" library in Chrome 38. To report a bug in Chrome visit chrome://help/ and click "Report an issue".
Try this. In Chrome, enter "chrome://flags/#enable-quic" without the quotes as a URL. CTRL + F to search for "quic", at which point you'll find...
Experimental QUIC protocol. Mac, Windows, Linux, Chrome OS, Android
Enable experimental QUIC protocol support. #enable-quic
Turn that to disabled, and let it restart your browser when prompted below.
Go to Windows Firewall, click on "Restore Defaults", then again. The problem should be fixed.
For me this issue resolved when I turned off my Antivirus Browsing control.
First check that in :
Internet Explorer- go to tools/internet options/advanced in the settings box, scroll all the way to the bottom and select Use TLS 1.0 and it will fix the problem.
SSL 2.0 or 3.0 and these are should also be selected.
Google Chrome-Click "wrench" sign on the tope right of it.Click Options then Under the bonnet in network click Change Proxy Settings and follow the steps above as in Internet Explorer.
If this didn't work try the following steps:
Unhide all the files and folders.
Then go to C:\Windows\System32\drivers\etc\hosts.
Right click on hosts file,then click properties. Then click security tab. After that click edit.
Here,click system and you have to check on allow full control and uncheck deny.
Click OK and then OK.
Now delete the hosts file.
You could read google forum tips from here
or you get all the details solution about err_ssl_protocol_error from here. I hope this will work and fix the error.
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.