Question
Will FaunaDB Add a Configurable Custom CA Trust Option for Private PKI?
Zo Byte
0 reputation · 10 Oct 2024, 17:11 UTC
148.6K views
Loading…
0 reputation · 10 Oct 2024, 17:11 UTC
FaunaDB’s API endpoints require TLS 1.2+ and present a server certificate signed by a public CA. The official drivers rely on the underlying HTTP library’s default trust store and do not expose a parameter to supply an alternate CA bundle, nor does the dashboard provide a way to upload custom root certificates. This leaves users who operate behind internal PKI or who need certificate pinning without a documented method to extend trust beyond the system store.
Given the current limitation, the unresolved decision is whether FaunaDB will introduce a configurable custom CA trust store or certificate pinning mechanism for its HTTP and GraphQL endpoints. Clarifying this would help teams plan for private‑CA environments and evaluate alternative approaches such as side‑car proxies.
Is there a planned timeline for adding a custom CA upload option in the FaunaDB dashboard? Will the Node, Python, Go, and Java drivers receive a TLS trust‑bundle configuration parameter? Does FaunaDB consider implementing certificate pinning as an alternative to a configurable trust store?
There is currently no documented plan or feature in the FaunaDB dashboard to upload custom root certificates, nor is there a native "custom CA trust" parameter within the official drivers. Because FaunaDB is a fully managed cloud service, TLS termination is handled by the provider using public Certificate Authorities (CAs), making server-side custom CA configuration inapplicable for the managed endpoints.
FaunaDB drivers are designed to be lightweight wrappers around standard HTTP libraries. Consequently, they delegate the TLS handshake and certificate validation to the underlying runtime's default trust store. If your environment uses a private PKI or an intercepting proxy that replaces public certificates with internal ones, the driver will trigger a TLS validation error because the internal CA is not recognized by the system store.
Since the drivers do not expose a specific TLS configuration object, you must inject the custom CA at the environment or runtime level. The method varies by language:
faunadbNODE_EXTRA_CA_CERTS environment variable to point to your custom CA bundle file.cacerts) using the keytool utility.SSL_CERT_FILE or SSL_CERT_DIR environment variables are set, as most standard libraries (like requests or net/http) honor these.For teams requiring strict certificate pinning or those operating in highly restricted environments where modifying the system trust store is prohibited, a side-car proxy (such as Envoy or Nginx) is the recommended pattern. The proxy handles the complex TLS handshake and custom CA validation, while the application communicates with the proxy over a local, secure channel.
To determine if a connection failure is due to a missing CA trust or a network routing issue, run the following scoped command from your application environment:
curl -v --cacert /path/to/your/internal-ca.crt https://api.faunadb.comIf this command succeeds while the driver fails, the issue is confirmed as a missing trust bundle in the language runtime.
Diagnostic Detail Needed: Are you encountering this issue specifically with a corporate SSL-intercepting proxy, or are you attempting to implement client-side certificate pinning for security compliance?
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 10 Oct 2024, 21:35 UTC
While waiting for official dashboard support or driver updates, it is important to distinguish between server-side trust and client-side verification. Since FaunaDB is a managed SaaS, the server does not require your private CA to verify the connection; however, your clients do require it to trust the FaunaDB endpoint when routing through an intercepting proxy or private PKI gateway.
For teams needing an immediate solution, most official drivers wrap standard HTTP clients. Depending on the language version, you can often bypass the driver's default configuration by passing a custom HTTP client instance:
http.Client with a tls.Config containing your RootCAs pool.https.Agent with a custom ca option.SSLContext and provide it to the underlying HTTP library.Verification can be performed using curl --cacert [path/to/cert] to confirm that the trust issue is isolated to the driver's default store and not the network path.