I am having an issue with a website where IE & MS Edge & Chrome all believe that the certificate is revoked (firefox works fine)
Error from IE:
This organisation's certificate has been revoked.
Security certificate problems may indicate an attempt to trick you or intercept any data you send to the server.
I have run check on SSLLabs, and the only problem i can see there is that it uses SHA1 hashes. Am i just seeing this error because of the SHA1 RSA Signatures?
URL: https://www.gunemporium.com.au/
Yep, SHA-1 is completely broken, and does not provide any effective encryption.
I would more suggest that there is some SSL intercepting middlebox or AV software involved which changes the certificate and the issuer of the certificate. IE and Chrome both use the same CA store and proxy settings while Firefox has their own settings which would explain why you see it with IE and Chrome but not Firefox on the same PC and why you don't see it on another PC.
I would suggest to have a look at the certificate details (subject, issuer, fingerprint) and chain and compare what you see in Firefox with what you see in IE/Chrome.
Related
When accessing https://www.twitch.tv on Chromium-based browsers (new Edge, Google Chrome, Opera) the following (commonly known) error appears:
Your connection isn't private
Attackers might be trying to steal your information from www.twitch.tv (for example, passwords, messages, or credit cards).
NET::ERR_CERT_REVOKED
When checking the SSL certificate, it states that is valid until June 13th, 2020. However, it also states that the certificate is withdrawn by the certificate authority.
Accessing the site from Firefox and from Chrome on another PC both work fine. Several SSL check websites also state that the certificate is fine.
I already tried the following:
Check date, time and timezone
Clear cookies and cache of the browser
Clear SSL state in internet options
Clear DNS cache
Temporarily disable anti-virus and windows defender
After an extensive search, I found a solution that worked for me. For those who have a similar problem: https://support.google.com/chrome/thread/24475945?hl=en
I have upgraded my Chrome to 58 and found the secured WebSocket isn't working any more, the console shows (WebSocket connection to 'wss://127.0.0.1:1234/' failed: Error in connection establishment: net::ERR_INSECURE_RESPONSE), I know Google has deprecated the SHA1 certificate, so created a new self-signed certificate with SHA256, but it still doesn't work, so is the self-signed cert not allowed in this scenario? (I'm using "new WebSocket("wss://127.0.0.1:1234")")
It turns out that the certificate should have a subjectAltName with "IP = 127.0.0.1" for my cert to work in Chrome58, not sure if it's a Chrome bug or new requirement
Edit: Please see #Edgar's answer. subjectAltName seems to have become a requirement for self-signed certificates since Chrome 58.
It appears the OP has asked this problem to Google Help Community as well. The response from Google Help Community is:
"I see that you are using Chrome Beta which is an experimental version of Chrome in which new features are tested. I'd recommend to use Chrome Stable which has gotten the full testing and is the updated version. It is the best bet to avoid crashes and other issues."
For now, that should be marked as the correct answer. I just tested wss://localhost on Chrome 59 (Canary/Beta) and it's working.
Note, moving forward, this functionality is subject for removal due to Chromium issue #378566 due to the security implications. For those of us requiring wss:// in this fashion, we should receive deprecation warnings prior to removal. As of Chrome 59 (Canary/Beta), this deprecation is not present.
How resolve this problem in google chrome for my site:
The certificate for this site expires in 2017 or later, and the certificate chain contains a certificate signed using SHA-1.
in Internet Explorer functions normally.
You resolve the problem by getting a new certificate that uses SHA2. The SHA1 algorithm has been proven to have collisions, which means someone could make up a fake certificate and impersonate your site.
Chrome on purpose warns and does not accept those certificates anymore.
Typically, if you revoke and re-issue a certificate with your CA, you will get credit for the remaining time of your existing certificate.
The problem is not with Chrome, but with your certificate being considered 'unsafe' and Chrome taking a hard stance to make sure things are actually secure.
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.