I'm getting a cert error in Chrome hitting an api I'm running locally via Intellij (on a macbook pro). It's not a new project but I was trying to set up self-signed certs and I messed something up.
When I look at the invalid cert in Chrome, it has the name of a cert I deleted. I've searched the drive for the cert (deleted it from Trash), and even grep'd for it. It's not in Intellij that I can tell. I've cleared browser cache and history. Other browsers fail similarly. Not in Intellij's list of certs. It's not in mac's Keychain Access.
I don't see where it's coming from. Is there a way to find out where it's getting the cert from??
Related
I am trying to access a site that requires an SSL key. I am using Chrome (latest) on Mac OSX 10.14.4.
Browsing the site I get the following error:
This site can’t provide a secure connection site.com didn’t accept
your login certificate, or one may not have been provided. Try
contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT
I can access the site on Safari, Firefox, and Chrome for Windows (using a VM). It is only Chrome for Mac that gives me an error.
When I access the SSL keys in the Chrome Preferences, I am taken to the OSX Keychain app.
The key exists in the keychain, and the permissions are set to allow use from any app (I have also tried setting this to manual and specifically setting allow with Chrome).
When I browse to the site in chrome, I am asked to pick the SSL key to use - the key is detected and I select it from the list (it is the only one available anyway).
I am completely out of ideas. Any thoughts on what I can do to fix this?
Ran into an issue earlier today with errors on our internal certificate. Other users/consumers/clients were not getting the errors. Was getting an error "there are issues with the sites certificate chain" and then when viewing the certificate, sure enough just the end certificate was listed, not the whole chain tree. The cert used to work fine after I generated it and installed on our servers a month or so ago and continues to work for my colleagues.
I am on Version 59.0.3071.115 (Official Build) (64-bit) on Ubuntu 14.04.
I resolved the issue on a whim by going to my custom CA settings here chrome://settings/certificates?search=cert and then Authorities and "edit"ing my CA, unchecking all the boxes, pressing okay, then re-editing and re-checking them and pressing okay, no browser restart needed. Next page refresh and my Certificate error was gone!
So this is likely a Chrome bug of some sort and its interaction with NSSDB.
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.
I'm creating an API using node js and express. As we are moving towards production, I decided to encrypt the api using ssl, (simply adding the require 'https' option and creating the requires key and cert files using openssl).
I want to continue working on the API using postman (chrome plugin), so to enable me to do this, I visited the API using Chrome, saved the cert for the API to disk and then imported that cert file (cer format) to the "personal" certificate store in Chrome. So far, so simple.
I was then able to start using the API over ssl as expected. Great.
Now, where it is starting to get a bit odd is that if I want to then remove that certificate from my personal certificate store in chrome, I was expecting to be able to just open up the settings - > htttps - > manage certificates and then to be able to remove the certificate, however the certificate is not visible in the list of certs. It's clearly been imported and is working, it's just not showing in the list. The machine in question is running win 10, so I also checked the certificate management console for the machine and I searched for the cert and cannot find it anywhere.
I think that this should be really simple, so where is that cert that I imported (and which is clearly imported and working) so that I can remove it?
Thanks!
So, I finally found the solution to this. From the command line start "certmgr" and from there I can see the installed certificate and remove it. Not sure why it doesn't show up when viewed from within Chrome?!
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.