ArcGIS Web Adaptor 10.5 and Google Chrome

[SamJehle1]

Hello,

I am publishing this question in the Portal location as I did not see a location specifically catering to the Web Adaptor. I have installed web adaptor 10.5 on a server and configured both Portal for ArcGIS and ArcGIS for Server with different web adaptor names. Both Portal and ArcGIS Server are separate servers. I am able to use Internet Explorer and access the websites for Portal and ArcGIS Server through the web adaptor, however when I use Google Chrome to accomplish the same task I get the error "This site can't be reached: ERR_CONNECTION_RESET". Has anyone encountered this before? While IE is my company's recommended browser, we will have several users that will use Chrome.

[JonathanQuinn]

What OS is the Web Adaptor installed on?  Does it work if you reach Portal and Server through http on Chrome?  I think there's a problem with an SSL setting in IE that causes problems for Chrome, I can't seem to find it though.

[SamJehle1]

The OS for the Web Adpator is Windows Server 2012. I can access ...arcgis/rest URL for the ArcGIS Server using http. The ArcGIS Server is federated with portal so I have https access only set up for the portal. Anytime I try to access portal through http it will load the home page for a split second, then go back to the same ERR_CONNECTION_RESET error. I'm waiting on certificates still so maybe once I have those properly imported Chrome will work.

[AdamZiegler1]

Common name support was removed at version 58 of Chrome. It will only trust and allow access via https using a cert from a trusted CA. From: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ 

"Many people don’t know that the “Common Name” field of an SSL certificate, which contains the domain name the certificate is valid for, was actually phased-out via RFC nearly two decades ago. Instead, the SAN (Subject Alternative Name) field is the proper place to list the domain(s).

However, this has been ignored and for many years the Common Name field was exclusively used. Chrome is finally fed up with the field that refuses to die. In Chrome 58, the Common Name field is now ignored entirely.

This means certificates that were exclusively using that field to indicate the valid domain name are no longer supported. Publicly-trusted SSL certificates have been supporting both fields for years, ensuring maximum compatibility with all software – so you have nothing to worry about if your certificate came from a trusted CA."

Adam Z

[JonathanQuinn]

While Chrome does require a SAN now, you'll receive the typical error indicating the browser doesn't trust the certificate if it doesn't have it:

This can simply be trusted ignored by clicking Proceed to <servername>.  That change shouldn't cause an ERR_CONNECTION_RESET response.  I believe the problem I was thinking about revolved around IIS 10, (the default on Windows Server 2016), HTTPS, IWA, and Chrome.  In that situation, I think the default for HTTP is HTTP/2, but Chrome doesn't have support for that enabled by default, so it returns the ERR_CONNECTION_RESET error but then can switch to use standard HTTP or HTTP1/1.  If Sam Jehle isn't seeing the browser redirect automatically, something else is going on.

[SamJehle1]

Is there any additional information you would like me to provide, Jonathan?

[JonathanQuinn]

Can you go into any other resource within your IIS using Chrome?  For example, create a new virtual directory, add an image to it, and browse to the image over HTTPS.  If that works, then you may want to reach out to Technical Support as it will likely be easier to troubleshoot with them directly.  If that doesn't work, then it seems like Chrome doesn't like something with your web server or certificate and your IT staff is likely the best resource.

[SamJehle1]

Yes, we've encountered the SAN field issue in our certificates and we are able to just advance passed them. With my current issue I am completely unable to advance to Portal through the Web Adaptor.