WebSocket connection error: ERR_CERT_AUTHORITY_INVALID

When connecting to Aura using the Browser, if you see this error (or one like it):

WebSocket connection to: 'wss://stringofcharacters...<dbid>.orchestra.neo4i.io' failed: Error in connection establishment: net::ERR_CERT_AUTHORITY_INVALID

You may be encountering a known issue with TLS certificates being replaced at your corporate proxy. Your organization may have a policy of performing deep-packet inspection on all connections. In order to do that, it first must decrypt any connections crossing its boundary, then re-encrypt them with its own certificate so that the connection is still safe from other listeners within the corporate network. 

What is happening is that when your corporate proxy replaces the certificate in order to do all of that, it's only updating the new certificate with information for the initial connection. So it only has the "*.neo4j.io" domain in its CN attribute. 

However, the certificates used to encrypt connections to the AuraDB Instances themselves use the domain "*.orchestra<number>.neo4j.io" in their CN. And because a wildcard certificate can only be valid for the closest subdomain, the hosts in the orchestra subdomains can't use the "*.neo4j.io" certificate. 

You can confirm these by running openssl against your main AuraDB Instance URI and then again against one of the constituent members of the AuraDB Instance behind the scenes. You can retrieve the hostname for anyone of them in the Browser, then click on the database icon on the left panel and then ":sysinfo" to bring up details about the AuraDB Instance. Choose any one of the three hosts listed. Then run:

openssl s_client -connect <database URI>:7687
 openssl s_client -servername <database hostname> -connect <database URI>:7687

You'll see that the CN is different on those certificates. 

To resolve this, your corporate proxy needs to be configured either to allow all of our certificates without replacing them; or, it needs to add the proper orchestra subdomain as an SNI to the certificate it generates. But keep in mind that with the second option that orchestras may change without notice, so it should do this programmatically. 

We strongly recommend going with the first option and add the "*.neo4j.io" domains to an allowlist so that the certificates are not replaced.