Skip to content

PATTERN Cited by 1 source

CA-bundled certificate for third-party tool trust

Intent

Configure a third-party tool that does not ship a public-CA trust store to connect to a managed service by uploading (or pasting) the managed service's CA root PEM into the tool's CA Cert field, without disabling TLS verification and without generating any self-signed certificate.

Context

Managed services (PlanetScale, Supabase, managed Postgres, managed Kafka) use a public CA — typically Let's Encrypt's ISRG Root X1 — to issue the serving certificate for their endpoint. Modern OSes, browsers, and most language drivers ship the public-CA list preloaded and validate the chain automatically. But a sizable fraction of third-party data tools (visualisation / BI tools, low-code platforms, some analytics clients) either ship with a minimal TLS stack or expect the user to supply trust explicitly via a UI field.

Observed instances (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field):

  • Google Data Studio / Looker Studio — connection UI offers CA Cert / Client Key / Client Cert fields.
  • Retool — same triple in the database-connection form.
  • Any minimal Linux container without ca-certificates installed (connection library asks for a CA bundle path).

Symptom when CA bundle is missing:

Error: Unable to get local issuer's certificate.

Forces

  • The tool's environment has no updateable trust store — often a SaaS product where the customer has no filesystem access, or a container where apt install ca-certificates is not feasible.
  • MUST not disable TLS verification — that opens MITM exposure (see self-signed-cert anti-pattern).
  • MUST not self-sign and send private keys to the managed service — fundamental PKI hygiene violation.
  • The tool does expose a CA-cert-upload UI, giving the user an in-scope fix.

Solution

  1. Obtain the managed service's CA root PEM.
  2. PlanetScale uses Let's Encrypt's ISRG Root X1; the PEM is downloadable from letsencrypt.org/certificates/ or inlined in PlanetScale Support's blog post for copy-paste convenience.
  3. Paste the PEM (or upload the .pem file) into the tool's CA Cert field.
  4. Leave Client Cert / Client Key blank (one-way TLS — the client authenticates separately via username/password).
  5. Connect. TLS verification succeeds because the tool's local trust store now contains exactly the root the service's certificate chains to.

Canonical PlanetScale Support framing (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field):

We can make use of these fields, though, to work around the issue. When there is a field where you can upload a CA Cert, you can upload Let's Encrypt's CA root certificate or, if it's a text field, paste it in. It is a regular text file after all.

Trade-offs

  • Must keep the bundle in sync with the managed service's CA. If PlanetScale rotates to a different CA (rare but possible at renewal boundaries), every third-party tool's uploaded bundle goes stale and the connection breaks. Monitoring advice from PlanetScale Support: "if you see a third-party platform having trouble connecting after a few months, make sure to check if our SSL/TLS certificate has changed and update when necessary."
  • Bundle is pinned to one CA, not to the whole public-CA list — if the managed service briefly serves a cert from a backup CA (e.g. during an incident / rotation), the bundle won't validate it. Broader fix is to upload a multi-CA bundle instead of a single root.
  • No visibility of CA rotation from the client side. The tool doesn't know the managed service rotated; first the user knows is connection failures. Some CA vendors publish rotation schedules (Let's Encrypt maintains roadmap posts); platform operators should notify customers proactively.

Alternative (preferred when available)

Install the system-wide CA-certificates package:

  • Debian/Ubuntu: apt install ca-certificates
  • Alpine: apk add ca-certificates
  • Fedora/RHEL: dnf install ca-certificates

This is preferred over the per-tool CA-upload approach because it automatically tracks upstream rotation via the Mozilla CA Certificate Program. Use the per-tool pattern only when the tool's environment is a black-box SaaS where system-wide install is not available.

Seen in

  • sources/2026-04-21-planetscale-supports-notes-from-the-field — canonical wiki example. PlanetScale Support explicitly demonstrates the pattern for third-party tools (Retool, Looker Studio) that can't reach PlanetScale on default trust, and inlines the full ISRG Root X1 PEM for direct copy-paste. Framing is explicit: "The root certificates for Let's Encrypt can be downloaded from their website. It is called ISRG Root X1 and you will need to download it in .pem format". The post also references a screenshot of a successful Retool-to-PlanetScale connection using exactly this pattern.
Last updated · 550 distilled / 1,221 read