Using: Chrome 67.0.3396.99
Our webserver implements X.509 client authentication. The certificates are offered through the PKCS#11 interface; we connect a smartcard (in this case: Yubikey 4), the browser prompts for the certificate selection and PIN.
We disconnected the smartcard and visited the authenticated domain (say, localhost:8000) to observe the behavior of the webserver (in a local development environment).
The webserver correctly refused to serve the request.
However, Chrome now does never send anymore the certificates while visiting localhost:8000, even if the smartcard is connected.
The following did not resolve the problem:
Clearing all site data through the developer console;
Resettting site preferences to their defaults (through chrome://settings/content/siteDetails?);
Rebuilding the webserver.
Any pointer where I can clear this state from Chrome would be greatly appreciated. As a temporary fix, we run the server at a different port but this is not an option on the long term. As this scenario is very plausible to also happen in production.
Related
Background: I have a web app that is accessed via Chrome on a Windows 10 machine.
I also have a native Win10 application installed on the device. The web app sends data to the Win10 application via a local web service running on the machine in IISExpress.
To allow for HTTPS communication on port 44300, I've created a self-signed certificate via PowerShell:
New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(60)
And then imported it to 'Local Computer\Trusted Root Certificates\Certificates'
From within the web app I send a command to the win10 app that looks something like this:
https://localhost:44300/CMTService.svc/JumpToAssignment?Param=Key=418584577
The win10 app is polling for these requests and picks up the message.
Issue:
Different versions of Chrome behave differently with the acceptance of the self-signed certificate. For instance versions 62, 64 and 75 all accept the certificate and allow for communication with the web service. But other versions of Chrome like 76 and 78 block communication. The Security tab in the Chrome DevTools shows https://localhost:44300 as "Unknown / cancelled" and my requests fail with ERR_SSL_CLIENT_AUTH_CERT_NEEDED. Whereas in working versions of Chrome my URL shows under "Secure origins". The only thing that I change is the Chrome version to get these different results.
I've tried enabling the Chrome setting to allow for invalid certs for localhost (chrome://flags/#allow-insecure-localhost). This temporarily works, but then after closing and reopening chrome, my requests start failing again with the same error code.
If I take one of my failing URLs and paste it into a new Chrome tab, suddenly communication with my native app in my web app resumes as normal. But it only works for that session - when I close and reopen Chrome my communication is broken again.
Question:
How do I allow for communication between my Chrome v78 web app and my local native app?
ERR_SSL_CLIENT_AUTH_CERT_NEEDED means the server is asking the browser for a certificate for client authentication.
You've described how you setup server authentication, but not described how you setup client authentication.
Likely you have enabled certificates for client authentication, but have not configured the web app to send the correct client certificate or have not configured the native app to accept the correct client certificate. That's a very open ended topic to be prescriptive without knowing more about your development efforts, but you can confirm if client authentication is enabled by inspecting a packet capture. One description of the handshake is here : https://blogs.technet.microsoft.com/nettracer/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication/.
Just an update: I implemented a javascript workaround to get around my communication issues. When first loading the web app, I simply send my first communication to IIS (destined for Win10 native app) in a separate chrome browser tab. For whatever reason this allows for successful acceptance of the certificate and kick starts the communication with IIS. This is my code to send the command in a new tab and then close it:
var inst = window.open(launchWinAppURL);
if (inst != null) {
window.setTimeout(function() {
inst.close();
}, 1000);
}
This is not the most elegant solution, but it seems to work on all chrome versions, so i'm satisfied.
Is the web app only communicating with the one win10 machine? Have you installed the self-signed cert directly to the machine? I would try installing it directly to the machine and see if the later instances of chrome allow communication.
We are looking for a way to have Chrome bypass the HSTS requirements for our dev environment.
We are working on a project for https://foo.com.
Within our organizations internal dns we have DNS entries for foo.com.dev which points to our internal dev server which has historically allowed us to reach our dev server via https://foo.com.dev. Secure web requests to this site have always been met with a security warning that we have been able to bypass but in a recent build of Chrome it seems that the ability to bypass the warning has been removed. We can continue to use this method in IE but would like to be able to test Chrome as well.
Additionally, developers have been able to use there own machine names as suffixes. For example a https://foo.com.workstation10
Any suggestions would be very welcome because the prospect of reconfiguring our entire dev environment is not a pleasant one.
To be clear - access to these sites are entirely limited to internal users by both firewall setup and dns configuration.
You can try one of the following options:
Send the Strict-Transport-Security header only for foo.com, and do not specify includeSubDomains.
Make self-signed certificates for foo.com.dev on server and import in on your local device's chrome.
If your target domain is restricted only for internal purpose, you can bypass it just typing badidea in the chrome window. Further details are available here
For more details about HSTS refer HSTS RFC
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
I'm using Advanced REST Client to test external API which requires me to specify
Connection: Keep-Alive. The connection fails (NO RESPONSE) and inspecting Chrome console I noticed Refused to set unsafe header "Connection" followed by net::ERR_INSECURE_RESPONSE
Is there any Chrome settings that allow me to override this? BTW, the API works when I use external tools like APIGee. I've tried Chrome CORS extension (Allow Control Allow Origin) but still unsuccessful.
The issue is that chrome is refusing to load a resource that has an invalid or expired SSL certificate. Even if you could get it to bypass that it would be a bad idea as it would make man in the middle attacks easier in your application.
My suggestion would be (if you trust the server or if it's running locally) to import that certificate to your store so it's trusted in your development environment. If the cert is expired and it's hosted locally look at the documentation on how to change the certificate or to add a self signed one (which you then also would add to your trusted sites)
How to add a self signed very to your store
For Mac
For windows
You'll have to restart chrome for it to see the certs in the store after doing this
Again, be sure you trust these certs origin as they'll be considered trusted as if a legit CA HAD issued them
I need to connect to a web service via HTTPS in my windows phone 8.0 app. It seems that there is no client SSL support from Microsoft about this issue.
I really need to know how to deal with certificates in WP8. What is the correct certificate? Which certificates need to be imported?
Scenario: I have a https endpoint: https://10.1.1.2 and when I connect there from my PC I am being prompted to view and install the certificate of the server. The certificate name "The Root CA" is being saved locally. The same certificate is installed in the mobile device w/o problems. When I open the https://10.1.1.2 from the mobile internet explorer it informs me that the web page is secure and I have to choose between close and continue the page. I am clicking continue and the https://10.1.1.2 transaction takes place. Every time I go to the same URL via the mobile internet explorer there is no warning to the end user regarding security.
According to Microsoft: In most cases, you do not have to do anything
to enable this for your Windows Phone app with the exception of using
an address that begins with the https:// protocol scheme. Windows
Phone then examines the certificate that is returned by the web
service, and if the certificate is from one of the trusted authorities
listed in SSL root certificates for Windows Phone OS 7.1, the Windows
Phone app platform then uses the certificate in conjunction with the
web service to encrypt all further communication, including the
exchange of the authentication credentials as described previously.
Although you can install trusted certificates on the Windows Phone, in
the current release, the Windows Phone app platform does not expose
those certificates’ values to apps. As a result, in the current
release, you cannot implement mutual authentication scenarios –
scenarios in which the client sends its own certificates to the web
service in addition to receiving one -- using certificates installed
in the root store.
So, is this procedure OK? I cannot use one of the certificate authorities that Microsoft
trusts by default. Do I need code?
Self signed certificate cannot be used and it does not automatically fetch data without intervention.
First of all, when testing your SSL connection through mobile IE, it appears from my testing that by pressing continue you are adding an exception to IE, not installing any certificates or getting the exception to apply phone-wide.
Secondly, using self-signed certificates on WP8 appears to be severely limited by the fact that any cert chain that does not use a built-in root CA will generate a failed certificate validation in your code. See the MSDN blog entry at http://blogs.msdn.com/b/davidhardin/archive/2010/12/30/wp7-and-self-signed-ssl-certificates.aspx
Where he states "You can implement your own certificate authority using Microsoft Certificate Services but you’ll still need a certificate from one of the phone’s certificate authorities to chain your certificate authority to."
The only "solution" I've seen posted is to effectively ignore all certificate warnings - which is no solution at all.