Workspace deployed via AWS Marketplace.

KrumIT
New Contributor

‎04-14-2026 07:19 AM

Workspace deployed via AWS Marketplace.
Internal endpoint 10.53.215.1 exists in VPC but
SSL handshake fails. Cannot connect to metastore.
Workspace URL: dbc-bb08dd2f-f142.cloud.databricks.com
AWS Account: 452456948535
Region: us-east-1"

0 Kudos

pradeep_singh
Honored Contributor III

‎04-14-2026 10:50 AM

Can you try using the hostname for your endpoint instead of IP address . 

Thank You
Pradeep Singh - https://www.linkedin.com/in/dbxdev
0 Kudos

balajij8
Esteemed Contributor

‎04-15-2026 05:09 AM

Databricks TLS validation requires SNI with the correct hostname for certificate verification - Check if you are connecting to the metastore via IP instead of hostname. Always use the documented metastore hostname.

Ensure the Databricks Private Link VPC endpoints are configured (*.cloud.databricks.com & meta store) with "Enable Private DNS" checked so hostnames resolve to private IPs & not public. Verify the endpoint status is In Service in AWS VPC Console. Exclude *.cloud.databricks.com from interception if using a proxy/TLS inspection appliance

0 Kudos

nayan_wylde
Esteemed Contributor II

‎04-15-2026 11:42 AM

Databricks endpoints present certificates for hostnames like *.cloud.databricks.com (or *.privatelink.cloud.databricks.com when PrivateLink is enabled). If your client connects to https://10.53.215.1 directly, the TLS ClientHello typically lacks the right SNI hostname, and the server returns a cert that doesn’t match the IP → handshake fails.
Fix: Always connect using the workspace URL hostname, not the IP:

dbc-bb08dd2f-f142.cloud.databricks.com (public DNS)
or dbc-bb08dd2f-f142.privatelink.cloud.databricks.com (if private access settings force PrivateLink)

Databricks explicitly recommends allowlisting FQDNs (not IPs) because IPs can change and are not the stable contract for SCC relay / endpoints.

View solution in original post

0 Kudos