Environment
- OS: Windows 11 Enterprise (corp-managed, MDM-enrolled)
- VS Code: latest
- Extension: databricks.databricks (latest)
- Network: corp CA certificate distributed via Group Policy to Windows Certificate Store
Description
On corp Windows machines, TLS certificates signed by an internal CA are trusted by the OS, browsers, and most Windows-native apps — but the Databricks VS Code extension (running on Node.js) does not consult the Windows certificate trust store. This causes SELF_SIGNED_CERT_IN_CHAIN or UNABLE_TO_GET_ISSUER_CERT_LOCALLY errors when the workspace host uses a cert signed by the corp CA, or when an HTTPS-intercepting proxy presents its own cert.
Node.js (18+) has --use-openssl-ca and WIN_TLS_STORE experimental support, and VS Code itself ships a workaround via the NODE_EXTRA_CA_CERTS env var and its own certificate injection, but the extension does not document how to use this.
Steps to Reproduce
- Corp Windows machine with internal CA cert in Windows Certificate Store (but NOT in a .pem file)
- Databricks workspace is behind a reverse proxy using the corp CA cert
- Open the extension and attempt cluster connection or OAuth login
- Observe: TLS handshake fails with certificate error
Expected vs Actual Behavior
Expected: Extension either reads Windows Certificate Store natively or documents how to configure NODE_EXTRA_CA_CERTS / SSL_CERT_FILE to trust the corp CA.
Actual: Extension fails with TLS error; no guidance in docs for corp CA trust.
Additional Context
VS Code itself injects system certs via --use-openssl-ca on Windows. Extension-level HTTP clients (e.g.
ode-fetch, �xios, custom https.Agent) need to be passed the same CA bundle or explicitly opt into the VS Code-level injection. A docs section on corp certificate setup would unblock many enterprise users.
Environment
Description
On corp Windows machines, TLS certificates signed by an internal CA are trusted by the OS, browsers, and most Windows-native apps — but the Databricks VS Code extension (running on Node.js) does not consult the Windows certificate trust store. This causes SELF_SIGNED_CERT_IN_CHAIN or UNABLE_TO_GET_ISSUER_CERT_LOCALLY errors when the workspace host uses a cert signed by the corp CA, or when an HTTPS-intercepting proxy presents its own cert.
Node.js (18+) has --use-openssl-ca and WIN_TLS_STORE experimental support, and VS Code itself ships a workaround via the NODE_EXTRA_CA_CERTS env var and its own certificate injection, but the extension does not document how to use this.
Steps to Reproduce
Expected vs Actual Behavior
Expected: Extension either reads Windows Certificate Store natively or documents how to configure NODE_EXTRA_CA_CERTS / SSL_CERT_FILE to trust the corp CA.
Actual: Extension fails with TLS error; no guidance in docs for corp CA trust.
Additional Context
VS Code itself injects system certs via --use-openssl-ca on Windows. Extension-level HTTP clients (e.g.
ode-fetch, �xios, custom https.Agent) need to be passed the same CA bundle or explicitly opt into the VS Code-level injection. A docs section on corp certificate setup would unblock many enterprise users.