Chrome NET::ERR_CERT_AUTHORITY_INVALID when browsing to vRO Control Center [vRA 7.3.0.1650 (build 5604410)]

[aenagy]

Using Google Chrome 72.0.3626.121 (Official Build)(64-bit) on Windows 10 generates the following when browsing to https://<vRA instance>:8283/vco-controlcenter/ :

Your connection is not private

Attackers might be trying to steal your information from <vRA instance> (for example,

passwords, messages, or credit cards). Learn more (chrome-error://chromewebdata/#)

NET::ERR_CERT_AUTHORITY_INVALID

[Hide advanced]  [Reload]

<vRA instance> normally uses encryption to protect your information. When Google

Chrome tried to connect to <vRA instance> this time, the website sent back unusual and

incorrect credentials. This may heppen when an attacker is trying to pretend to be

<vRA instance>, or a Wi-Fi sign-in screen has interrupted the connection. Your information

is still secure because Google Chrome stopped the connection before any data was

exchanged.

You cannot visit <vRA instance> right now because the website uses HSTS. Network errors

and attacks are usually temporary, so this page will probably work later.

This seems to be relatively new, meaning that it has worked in the past but we don't know when it stopped working. If we use the Chrome "thisisunsafe" trick then we are able to bypass this error.

Anyone know what is causing this error how how to fix it?

[daphnissov]

First, that's an old Chrome build. Current one is on the 75.x branch. Second, it's due to HSTS, often when you are using a DNS A record or CNAME in place of a load balancer and it's directing you to the actual node name. You may, in this configuration, need to open a browser in incognito mode and access the vRA appliance FQDN directly.

[aenagy]

daphnissov

First, that's an old Chrome build. Current one is on the 75.x branch.

Unfortunately, the browser version is controlled by the organization. Internet Explorer is even less helpful for the same URL.

Second, it's due to HSTS, often when you are using a DNS A record or CNAME in place of a load balancer and it's directing you to the actual node name.

After taking another look I see that the certificate subject <> URL FQDN hostname and the certificate appears to be self signed.

This seems to be a browser issue if only because this did work in the past. My best guess at the moment was that an older version of Chrome did not complain so vehemently and then a new version was distributed as part of a regular patch/update cycle and boom -- no more easy bypass. I searched to see which version of Chrome changed this behavior but didn't find anything.

Thanks.

[daphnissov]

This seems to be a browser issue if only because this did work in the past.

Yeah, but what I was saying was that Chrome 72 changed the way in which HSTS was handled, so even if you're using self-signed certs the name needs to match, but it uses stricter enforcing. Again, all if I'm not mistaken.