Diagnosing Common Connectivity Issues

There are a variety of issues you could encounter while connecting to any online service, including Snowflake.

Currently, this topic focuses on two major areas:

  1. Potential issues you may encounter with the OCSP (Online Certificate Status Protocol) checks performed by Snowflake clients.

  2. Using the Snowflake Connectivity Diagnostic Tool (i.e., SnowCD) to evaluate and troubleshoot network connections to Snowflake.

As an integral component of securing communications, each Snowflake client (Python, JDBC, ODBC, etc.) verifies the current validity of the signed Snowflake certificate issued by a trusted CA (certificate authority). If communication is blocked between a Snowflake client and the CA site or OCSP responder, a TLS/SSL error is generated.

In this Topic:

Verifying Communication with Your CA Site or OCSP Responder

To verify that communication is not blocked:

Step 1: Retrieve the URL for Your Certificate

Retrieve the URL used by Snowflake for OCSP checks on your signed Snowflake certificate:

  1. In Google Chrome, log into the Snowflake web interface.

  2. In the top-right corner of the browser window, click the icon (“Customize and control Google Chrome”). Then, click on More Tools » Developer Tools.

  3. The Developer Tools frame appears. In the frame, click on the Security tab.

  4. Click the View certificate button, then expand the Details section.

  5. Scroll through the details until you find the appropriate extension and make note of the URL for:

    Online Certificate Status Protocol (e.g. http://ocsp.netsolssl.com)

    For example:

    Viewing OCSP URL for certificate in Developer Tools

Next, test your ability to access the URL (see Step 2). Various network issues could prevent the Snowflake client from accessing the URL. For example, your firewall may be blocking access to the sites used by Snowflake.

Step 2: Test the URL

Complete the operating system-specific steps to check whether you can reach the URL (<ocsp_url>) you retrieved in Step 1:

Windows
  1. Open a PowerShell window on the host where the connectivity problem persists.

  2. Execute the following command:

    Invoke-WebRequest <ocsp_url>
    

    The Invoke-WebRequest command sends an HTTP request to a web page or web service and returns a response.

Linux / macOS
  1. Open a terminal on the host where the connectivity problem persists.

  2. Execute the following command:

    curl -I <ocsp_url>
    

If successful, the command will return results similar to:

HTTP/1.1 200 OK
Server: Apache
X-OCSP-Responder-ID: dwdccaocsp27
Content-Length: 5
Content-Type: application/ocsp-response
Date: Thu, 09 Aug 2018 19:19:20 GMT
Connection: keep-alive

If the command return an error, report the issue to your network administrator to diagnose further. They might need to explicitly whitelist the OCSP host used to check your certificate.

If the command returns a status code other than 200, contact Snowflake Support.

CA Site and OCSP Responder Hosts Used by Snowflake (by Cloud Platform and Region)

Snowflake uses the following hosts for OCSP certification checks. Note that the hosts may differ by Snowflake Region for a given cloud platform.

Important

These are examples of the most commonly-used hosts. For each region (or individual account), Snowflake may use a certificate issued by a different CA, which results in different hosts and URLs. For example:

  • For most accounts in US West (on AWS), Snowflake currently uses Digicert-signed certificates from Network Solutions.

  • For other Snowflake Regions (on AWS), Snowflake mostly uses certificates from the Amazon CA.

In addition, Snowflake may change certificates as they expire or require enhancement, which will result in different hosts and URLs.

For a complete list of hosts and URLs for your account, please contact Snowflake Support.

Snowflake on AWS

Host

US West

Other Regions

Notes

ocsp.snowflakecomputing.com:80

Snowflake’s OCSP response cache server. Note that the hostname is different if AWS PrivateLink is enabled.

*.amazontrust.com:80

*.digicert.com:80

*.netsolssl.com:80

*.ss2.us:80

*.usertrust.com:80

Snowflake on Microsoft Azure

Host

East US 2

Notes

ocsp.snowflakecomputing.com:80

Snowflake’s OCSP response cache server.

*.digicert.com:80

*.msocsp.com:80

OCSP Certification Checks Require Port 80

All communication with Snowflake happens using port 443. However, OCSP certification checks are transmitted over port 80. If your workstation is behind a firewall, make sure that the network administrator for your organization has opened the firewall to traffic on ports 443 and 80.

JDBC and ODBC Drivers No Longer Use CRL

A CRL (certificate revocation list) specifies the certificates that have been explicitly revoked by a given CA. Older versions of the JDBC and ODBC drivers used either CRL or OCSP to verify TLS/SSL certificates. Starting with the following versions, the drivers use only OCSP for all certificate verification:

  • JDBC 3.5.0 (or higher).

  • ODBC 2.15.0 (or higher)

Snowflake Connectivity Diagnostic Tool (SnowCD)

The Snowflake Connectivity Diagnostic Tool (i.e., SnowCD) helps users to diagnose and troubleshoot their network connection to Snowflake.

SnowCD leverages the Snowflake hostname IP addresses and ports output from either the SYSTEM$WHITELIST() or SYSTEM$WHITELIST_PRIVATELINK() functions to run a series of connection checks to evaluate and help troubleshoot the network connection to Snowflake.

Important

If your Snowflake account uses AWS PrivateLink, execute the SYSTEM$WHITELIST_PRIVATELINK function to obtain the Snowflake hostname IP address and ports to evaluate and troubleshoot network connections to Snowflake.

For more information regarding Snowflake and AWS PrivateLink, see AWS PrivateLink & Snowflake.

This information this tool returns includes the following:

  1. All checks passed to indicate a healthy network connection.

  2. A message to state that one or more checks failed with a troubleshooting suggestion.

Users can leverage this tool to evaluate the network connection to Snowflake at any time to verify the required configuration settings are correct. For example, users can integrate SnowCD into these use cases:

  1. Automated deployment scripts.

  2. A prerequisite check before deploying a service that connects to Snowflake.

  3. Environment checks while starting a new machine.

  4. Periodic checks on running machines.

Attention

Troubleshooting one or more network connection issues is challenging. Depending on the environment, it may be necessary to use SnowCD with other troubleshooting approaches. For example, if the tool returns information on an OCSP issue, consult the OCSP sections on this page.

Step 2: Download and Install SnowCD

Linux

Installation procedure

  1. Download the latest version of the SnowCD (i.e., snowcd) for your Linux operating system.

  2. Open the Linux Terminal application and navigate to the directory where you downloaded the file.

  3. Verify the SHA256 checksum matches.

    $ sha256sum <filename>
    
  4. Extract the file.

    $ gunzip <filename>
    
  5. Make the file executable.

    $ chmod +x <filename>
    
  6. Rename the executable to snowcd.

    $ mv <filename> snowcd
    

Note

Linux users running RHEL or CentOS can install SnowCD using yum while Debian users can install using apt.

macOS

Installation procedure

  1. Download the latest version of the SnowCD (i.e., snowcd) for your Apple (i.e., mac64) operating system.

  2. Open the Terminal application and navigate to the directory where you downloaded the file.

  3. Verify the SHA256 checksum matches.

    $ shasum -a 256 <filename>
    
  4. Extract the file.

    $ gunzip <filename>
    
  5. Make the file executable.

    $ chmod +x <filename>
    
  6. Rename the executable to snowcd.

    mv <filename> snowcd
    

Windows

Installation procedure

  1. Download the latest version of the SnowCD (i.e., snowcd) for your Windows (i.e., win64) operating system.

  2. Run the MSI file using the Windows Installer.

Step 3: Run SnowCD

  1. From the command line in macOS or Linux environments, execute snowcd <path_to_whitelist.json> [flags].

  2. In Windows environments, execute snowcd.exe <path_to_whitelist.json> [flags].

Tip

For a full description on the flags snowcd supports, execute snowcd -h.

If all checks are valid, SnowCD returns the number of checks on the number of hosts with the message All checks passed as follows.

Performing 30 checks on 12 hosts
All checks passed

If you try to run SnowCD without passing in the JSON whitelist information from SELECT SYSTEM$WHITELIST(), the following error message displays as a reminder to include the file, with the list of currently supported flags, their data type where applicable, and a brief description of the flag.

Error: please provide whitelist generated by SYSTEM$WHITELIST()
Usage:
./snowcd <path to input json file> [flags]

Examples:
./snowcd test.json

Flags:
  -h, --help                   help for ./snowcd
  --logLevel string            log level (panic, fatal[default], error, warning, info, debug, trace) (default "fatal")
  --logPath string             Output directory for log. When not specified, no log is generated
  --proxyHost string           host for http proxy. (When not specified, does not use proxy at all
  --proxyIsHTTPS               Is connection to proxy secure, i.e. https. (default false)
  --proxyPassword string       password for http proxy.(default empty)
  --proxyPort int              port for http proxy.(default 8080) (default 8080)
  --proxyUser string           user name for http proxy.(default empty)
  -t, --timeout int            timeout for each hostname's checks in seconds (default 5) (default 5)
  --version                    version for ./snowcd

If SnowCD detects an incorrect setting or configuration, information on the failed check(s) displays with a troubleshooting suggestion. For example, the response below indicates an invalid hostname.

Check for 1 hosts failed, display as follow:
==============================================
Host: www.google1.com
Port: 443
Type: SNOWFLAKE_DEPLOYMENT
Failed Check: DNS Check
Error: lookup www.google1.com: no such host
Suggestion: Check your configuration on DNS server

Using the SnowCD with an HTTP Proxy

SnowCD can be run against an HTTP proxy to determine its connectivity status.

Using Linux as a representative example, execute the following command to run the tool against a proxy, replacing the flag values where necessary.

snowcd whitelist.json \
  --proxyHost <hostname> \
  --proxyPort <port_number> \
  --proxyUser <username> \
  --proxyPassword <password>

Logging is optional and you can add the two logging flags to the proxy command. It is important to include a path to the log file to ensure logging occurs when running the command.

snowcd whitelist.json \
  --proxyHost <hostname> \
  --proxyPort <port_number> \
  --proxyUser <username> \
  --proxyPassword <password> \
  --log level trace \
  --logPath test.log

After executing this command, you can view the trace in the test.log file.