ODBC Test Connect from ODBC Administrator Fails With: org.apache.commons.httpclient.HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated[1001]Issue You have installed any version of the ODBC Driver. From the Windows menu you go to ServiceNow ODBC -> ODBC Administrator -> System DSN tab -> Select Data Source ServiceNow -> select button Configure... In Custom Properties it is setup pointing to a correct instance URL, possibly with optional properties, for example: url=https://<instance_name>.service-now.com;BatchSize=1000;LegacyDurationTimeZone=true When selecting the "Test Connect" button valid Data Source User Name and Data Source Password are entered and OK selected. This fails with the error: org.apache.commons.httpclient.HttpException:javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated[1001] ReleaseApplies to any ODBC driver version.CauseThe machine where the ODBC driver is installed cannot communicate with the instance.ResolutionFor cloud instances ServiceNow support can confirm that the Test Connect request has or has not reached the instance by checking the load balancer logs, this is what an example Test Connect request would look like in the log if it did reach the instance: 2021-09-02 20:45:28Z src=10.10.10.10 vip=10.10.10.10 instance=myinstance node=10.10.10.10:16073 method=POST uri=/sys_properties.do?SOAP&displayvalue=all&redirectSupported=true reqtime=95 rtt32=564 rescode=200 s=901CF2 xff="70.34.48.20" sslv=TLSv1.2 sslc=ECDHE-RSA-AES128-GCM-SHA256 odbc="1.0.15" ua="remote_glide_record_client" cl=202 txid=3fa891ae1b9ahost = adc-000.abc0.service-now.comsource = /glide/log/adc-000.abc.service-now.com/udp-5520-f5_access_log.logsourcetype = f5_access_logsrc_ip = 10.10.10.10 Once it is confirmed that the request did not reach the instance please debug the issue from the machine that is hosting the ODBC driver: (1) Open a windows terminal window and ping the instance: ping <instance_name>.service-now.com Example of working ping: C:\>ping <instance_name>.service-now.com Pinging <instance_name>.service-now.com [10.10.10.10] with 32 bytes of data:Reply from 10.10.10.10: bytes=32 time=166ms TTL=128Reply from 10.10.10.10: bytes=32 time=166ms TTL=128Reply from 10.10.10.10: bytes=32 time=166ms TTL=128Reply from 10.10.10.10: bytes=32 time=179ms TTL=128 Ping statistics for 10.10.10.10:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 166ms, Maximum = 179ms, Average = 169ms You could also check the network path with a tracert from a windows terminal window: tracert <instance_name>.service-now.com Example of working tracert: C:\>tracert <instance_name>.service-now.com Tracing route to <instance_name>.service-now.com [10.10.10.10]over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.10.10.10..........12 173 ms 166 ms 166 ms vip-10.10.10.10.cust.service-now.com [10.10.10.10] Trace complete. Note that just because those commands work, it does not mean that the ODBC driver will be able to reach the instance, but if the above ping and tracert fail then there is a block that is preventing the ODBC driver machine from reaching the instance. (2) If the commands above are not giving access to the instance you will need to check with your network team to be sure they are not blocking access to the instance IP addresses, they need to make sure that the IP address(es) shown under "The address to which your instance resolves" are open in your firewall, see this KB: Finding the IP information for your instance (3) Can you reach the instance URL from a browser running on the ODBC driver machine?: https://<instance_name>.service-now.com If not again contact your network team about access. (4) Check with your network team: do you need to connect the ODBC driver to the instance using a proxy? If so make sure the proxy is set up in the ODBC driver configuration as in the documentation here: Configure ODBC to use proxy servers If the proxy is set up already, make sure that the proxy is up and running with your network team, you may also ping it and also try to telnet (you may need to enable telnet on Windows, you can look this up online) to it from a windows command window: telnet <proxy host or IP address> <port> For example: telnet myproxy.com 8080 (5) If needed you could run a wireshark packet capture from the ODBC driver machine to see what is happening when the ODBC Test Connect is done, wireshark can be downloaded from here and installed on Windows: https://www.wireshark.org/download.html After install a packet capture can be taken to check what is happening on the network when trying to connect to either the instance directly or to the ODBC driver proxy (if you are using one). Is there communication from the ODBC driver machine to the configured ODBC proxy/instance hostname? It may also be necessary to do a wireshark/packet capture at the edge of your network, i.e. the last stop in your network path before requests go out to the cloud to confirm that communication with the instance is possible. Is there communication from the ODBC driver machine to the instance hostname? Once end-to-end connectivity from the ODBC driver machine to the instance is confirmed the error should no longer be seen.