| Product(s): | CONNECTION Client |
| Version(s): | All |
| Area: | Access |
Problem
At the start of the CONNECTION Client it says "Connection Failure - Could not connect"
Possible Cause #1
Proxy Server Setting configuration
Solution
Open the Bentley Licensing Tool, click on Tools > Options - If your company does not require a proxy server setting, it should then be left blank.
Possible Cause #2
If you see the following error in the logs that says either the computer or the user account are not trusted or allow delegation:
ERROR - Manager - Failed to get WSG token: System.Security.Cryptography.CryptographicException: The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.
Follow the solution below.
Solution
Instructions on how to enable computer and user accounts to be trusted for delegation are here.
The Windows data protection API used to securely store a user’s token is encountering connection issues with the domain controller. The following troubleshooting steps from Microsoft may help. The third resolution usually resolves the issue, but the first two are worth trying anyway. If the issue persists, please refer to the following alternative instructions.
Please reboot the system after making changes.
Possible Cause #3
The following error shows that the user does not have the ISRG Root X1 security certificate installed:
ERROR - BUDDIClient - GetUrl() encountered an error: System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority 'buddi.bentley.com'. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Explanation
Several Bentley servers utilize a security certificate signed by Let's Encrypt. Let's Encrypt certificates are signed by R3 which in turn is signed by ISRG Root X1 as described in the following explanation from Let's Encrypt. If ISRG Root X1 is not trusted, some of our security certificates will not be either. Following is an explanation for the transition to ISRG Root since Let's Encrypt was previously signed by a different root certificate authority.
Solution
Have IT confirm ISRG Root X1 is listed in the Trusted Root Certification Authorities list in the Certificate snap-in for Microsoft Management Console.
NOTE:
We do not provide the certificate and if it is missing your internal IT department needs to obtained it from the Certificate Authority - navigate to the CONNECT Center, click the padlock icon to the left of the URL, select "Connection is secure" and click the certificate information/icon - the certificate details will be displayed, click the "Issuer Statement" button, which will direct you to the Let's Encrypt Certificate Authority.
See Also
Script Error dialog on sign in with 'Promise' is undefined error