Tableau Ingestion SSL Errors: Using session_trust_env to Honor Custom CA Bundles – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: Tableau Connector SSL / TLS Configuration

Issue

Tableau ingestion fails at the authentication step with an SSL error when the deployment uses a custom or internal Certificate Authority (CA). Even when a CA bundle path is specified via the ssl_verify recipe parameter, or when the pod's environment already has REQUESTS_CA_BUNDLE and SSL_CERT_FILE set to a valid bundle, the connector still raises an SSLError PEM lib failure. The root cause is a bug in the Tableau connector's make_tableau_client method: when ssl_verify is set to a file path string, the code incorrectly passes that path to the cert parameter of the underlying requests session (intended for client-side mTLS certificates) rather than to the verify parameter (intended for CA bundle trust). OpenSSL's client-certificate PEM loader then fails when it encounters a CA bundle file, producing error code 524297. Separately, even without the path bug, the Tableau connector's requests.Session defaults trust_env to False, meaning environment-level CA settings are ignored entirely unless explicitly enabled.

Error Messages

<class 'ValueError'>: Unable to login (check your Tableau connection and credentials): HTTPSConnectionPool(host='<tableau-host>', port=443): Max retries exceeded with url: /api/2.4/auth/signin (Caused by SSLError(SSLError(524297, '[SSL] PEM lib (_ssl.c:3948)')))
ERROR {datahub.ingestion.source.tableau.tableau:955} - Tableau Login Error: Failed to authenticate with Tableau.

You Might Be Asking

Why does Tableau ingestion fail with an SSL error even though I added my CA certificate to the container image?
Why does setting ssl_verify: /path/to/ca-bundle.pem in my Tableau recipe cause an SSL PEM lib error instead of fixing it?
Why does the Tableau connector ignore my REQUESTS_CA_BUNDLE or SSL_CERT_FILE environment variables?
How do I make the Tableau connector use my organization's internal or self-signed CA certificate?
What is the difference between ssl_verify and session_trust_env in the Tableau source config?

Solution

Two workarounds are available depending on your situation. The recommended approach is Option A, which restores full CA verification using your organization's CA bundle without disabling SSL.

Option A (Recommended): Use `session_trust_env: true` with Environment Variables

This approach instructs the underlying requests session to honor the environment's CA configuration, bypassing the broken ssl_verify string-path code path entirely.

Ensure the following environment variables are set in your ingestion executor pod, pointing to your organization's CA bundle file:
```
REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
```
Adjust the path to match your image's CA bundle location. Common paths by OS family:
- Debian/Ubuntu: /etc/ssl/certs/ca-certificates.crt
- RHEL/CentOS: /etc/pki/tls/certs/ca-bundle.crt
- Alpine: /etc/ssl/certs/ca-certificates.crt

Update your Tableau ingestion recipe. Remove any ssl_verify path string and add session_trust_env: true to the source config:

source:
  type: tableau
  config:
    connect_uri: 'https://<your-tableau-host>/'
    session_trust_env: true
    token_name: '${tableau_token_name}'
    token_value: '${tableau_token_value}'
    ingest_owner: true
    ingest_tags: true
    platform_instance: <your-platform-instance>

Run ingestion. The requests session will now pick up REQUESTS_CA_BUNDLE from the environment and use your organization's CA store for TLS verification.

Option B (Insecure — Temporary Only): Disable SSL Verification

This option disables TLS certificate verification entirely and should only be used as a very short-term measure while you implement Option A. It is not acceptable for production use.

source:
  type: tableau
  config:
    connect_uri: 'https://<your-tableau-host>/'
    ssl_verify: false
    token_name: '${tableau_token_name}'
    token_value: '${tableau_token_value}'

Permanent Fix

A code fix correcting the ssl_verify string-path routing bug in make_tableau_client has been merged. Once the fix is available in your version, passing a CA bundle path directly via ssl_verify will work as documented:

source:
  type: tableau
  config:
    connect_uri: 'https://<your-tableau-host>/'
    ssl_verify: /etc/ssl/certs/ca-certificates.crt
    token_name: '${tableau_token_name}'
    token_value: '${tableau_token_value}'

Behavior Summary by Configuration

ssl_verify value          | requests parameter used | Result (before fix)
--------------------------|-------------------------|-------------------------------
unset (default: true)     | verify=True             | Uses certifi; misses custom CAs
false                     | verify=False            | SSL disabled; succeeds insecurely
"/path/to/ca-bundle.pem"  | cert=<path>            | PEM lib parse error (bug)
session_trust_env: true   | trust_env=True          | Honors REQUESTS_CA_BUNDLE env var

Additional Notes

The permanent fix for the ssl_verify string-path bug is available as of CLI release v1.6.0.7 and will be included in DataHub Cloud releases after v2.0.0. Until you upgrade to a fixed version, use the session_trust_env: true workaround.
The session_trust_env: true parameter defaults to false in the Tableau connector. This is why environment-level CA variables are ignored unless this flag is explicitly set.
The Python certifi library maintains its own CA bundle that is entirely separate from the OS-level or pod-level trust store. Adding a CA certificate to the container image does not automatically make it available to Python's requests library unless REQUESTS_CA_BUNDLE is set or session_trust_env: true is used.
This issue affects any on-premise or self-hosted DataHub deployment connecting to a Tableau server that uses an internal or self-signed CA certificate.
Affected environment context: Python 3.11+, OpenSSL 3.x, urllib3 2.x, requests 2.x. The bug is in configuration-to-request-parameter translation and is not timing or environment dependent — it reproduces deterministically.
Do not leave ssl_verify: false in production. It disables all TLS certificate verification and exposes your ingestion pipeline to man-in-the-middle attacks.