OCSP Configuration

This topic provides an overview of OCSP, its use in Snowflake, and information to help diagnose OCSP issues.

In this Topic:

OCSP Overview

Snowflake uses Online Certificate Status Protocol (OCSP) to provide maximum security to determine whether a certificate is revoked when Snowflake clients attempt to connect to an endpoint through HTTPS.

Snowflake uses OCSP to evaluate each certificate in the chain of trust up to the intermediate certificate the root certificate authority (CA) issues. Ensuring that each certificate is not revoked helps Snowflake to establish secure connections with trusted actors during the identity verification process.

Depending on your client or driver version and the configuration described on this page, it is possible to turn off OCSP and to adjust the action that occurs when OCSP determines a certificate is revoked.

Fail-Open or Fail-Close Behavior

Currently, users can choose between either of two behaviors in terms of how Snowflake clients or drivers respond during an OCSP event.

  1. Fail-open

  2. Fail-close

Fail-Open

Snowflake supports a fail-open approach by default in terms of evaluating the OCSP CA response. The fail-open approach has the following characteristics:

  • A response indicating a revoked certificate results in a failed connection.

  • A response with any other certificate errors or statuses allows the connection to occur, but denotes the message in the logs at the WARNING level with the relevant details in JSON format.

Users can monitor the logs for the specific driver or connector to determine the frequency of fail-open log events.

These event logs can be combined with the Snowflake Status Page to determine the best course of action, such as temporarily restricting client access or pivoting to fail-close behavior.

Currently, the fail-open default approach applies to the following client and driver versions.

Client / Driver

Version

SnowSQL

v1.1.79 or later

Python Connector

v1.8.0 or later

JDBC Driver

v3.8.0 or later

ODBC Driver

v2.19.0 or later

SQL Alchemy

Upgrade Python Connector to v1.8.0 or later

Spark

v2.4.14 or later if using Maven or SBT to build the Spark application. . JDBC v3.8.0 or later if attaching JAR files to Spark cluster. . Request Databricks to upgrade their Spark connector if using the Databricks built-in Spark connector.

Go Driver

v1.2.0 or later

Node.js

v1.2.0 or later

Note

Snowflake does not support OCSP checking for the .NET driver. Instead, .NET uses its own framework to check the validity of the HTTPS certificate.

Fail-Close

The fail-close behavior is more restrictive to interpreting the OCSP CA response. If the client or driver does not receive a valid OCSP CA response for any reason, the connection fails.

Since this behavior is not default based on the versions listed in the fail-open section, fail-close must be configured manually within each driver or connector.

To preserve the fail-close behavior, set the corresponding ocsp_fail_open parameter to false.

Client / Driver

Setting

SnowSQL

snowsql -o ocsp_fail_open=false

Python Connector

For details, see Choosing Fail-Open or Fail-Close Mode in the Python Connector documentation.

JDBC Driver

For details, see Choosing Fail-Open or Fail-Close Mode in the JDBC Driver documentation.

ODBC Driver

Choose one of the following: . Set the connection parameter to OCSP_FAIL_OPEN=false . Use the environment variable $SIMBAINI to locate the corresponding file. Then set OCSPFailOpen=false

SQL Alchemy

See JDBC Driver settings

Spark

The Spark Connector does not have an ocsp_fail_open parameter. . Fail-close can only be preserved with Spark if using the JDBC driver.

Go Driver

Do either of the following: . - Set the connection parameter OCSPFailOpen in Config to ocspFailOpenTrue or ocspFailOpenFalse, for example: . import ( ... sf "github.com/snowflakedb/gosnowflake ... ") . config: &Config{ Account: "xy12345", ...,  OCSPFailOpen: sf.ocspFailOpenFalse, ... } . - Set the ocspFailOpen connection parameter in the connect string to true or false, for example, . user:pass@account/db/s?ocspFailOpen=false. . Note the differences in case (upper-case / lower case). . For more information on Go connection parameters, see the GoDoc gosnowflake documentation.

Node.js

Set the global parameter ocspFailOpen=false. For details, see Using the Node.js Driver.

Legacy Client & Driver Versions

If your client or driver version is older than that listed in the fail-open section, the fail-open behavior is not an option. Therefore, the fail-close behavior is default.

Snowflake deployments using legacy client and driver versions with respect to OCSP have three options:

  1. Upgrade their client or driver to its latest version (best option).

  2. Continue using the fail-close behavior.

  3. Turn off OCSP monitoring (i.e., insecure mode) as described here.

Best Practices

To mitigate risk, Snowflake recommends the following best practices to keep communications secure.

  1. Use AWS PrivateLink and block public access to Snowflake.

  2. Allow client drivers to run on managed desktops and servers only.

  3. Send client driver logs to a management system or upload to Snowflake. Monitor the connections made without OCSP checking.

Note

Support for AWS PrivateLink requires Business Critical Edition (or higher). To inquire about upgrading, please contact Snowflake Support.

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)

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 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 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)