OCSP Configuration¶

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

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.

Fail-open
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 (uppercase / lowercase). . For more information on Go connection parameters, see the GoDoc gosnowflake documentation.
Node.js	Set the global parameter `ocspFailOpen=false`. For details, see Node.js options reference.

Legacy client and 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:

Upgrade their client or driver to its latest version (best option).
Continue using the fail-close behavior.
Turn off OCSP monitoring (i.e., insecure mode) as described in this Knowledge Base article (in the Snowflake Community).

Best practices¶

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

Use private connectivity to the Snowflake service and block public access to Snowflake.
Allow client drivers to run on managed desktops and servers only.
Send client driver logs to a management system or upload to Snowflake. Monitor the connections made without OCSP checking.

Note

Support for private connectivity to the Snowflake service requires Business Critical (or higher). To inquire about upgrading, please contact Snowflake Support.

CA site and OCSP responder hosts used by Snowflake¶

You can call the SYSTEM$ALLOWLIST or SYSTEM$ALLOWLIST_PRIVATELINK function in your Snowflake account to get the hosts Snowflake uses for OCSP verification checks. The host values are unique to the cloud platform and region where your Snowflake account exists. The reasons for the different host values are based on the CA that the cloud platform uses and when the certificates are updated or renewed.

For example:

SELECT t.VALUE:type::VARCHAR as type,
  t.VALUE:host::VARCHAR as host,
  t.VALUE:port as port
FROM TABLE(FLATTEN(input => PARSE_JSON(SYSTEM$ALLOWLIST_PRIVATELINK()))) AS t
WHERE type ILIKE ANY ('OCSP%');

Copy

+-----------------------+---------------------------------------------------------------+------+
| TYPE                  | HOST                                                          | PORT |
|-----------------------+---------------------------------------------------------------+------|
| OCSP_CACHE            | ocsp.account1234.us-west-2.privatelink.snowflakecomputing.com | 80   |
| OCSP_CACHE_REGIONLESS | ocsp.my_org-my_account.privatelink.snowflakecomputing.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 a given CA explicitly revoked. Older versions of the JDBC and ODBC drivers used either CRL or OCSP to verify TLS 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)