Trust a Private Certificate Authority in Your Application

This page shows you how to make your application trust a private or corporate certificate authority (CA), so it can call a partner API or an internal service whose certificate that CA issued — the fix when your application fails with errors such as unable to get local issuer certificate, certificate signed by unknown authority or PKIX path building failed.

There are two ways to do it. Both are yours to set up; nothing on the platform needs to change.

Option	When to use it
Bake the CA into your container image	The most robust option: the CA is there wherever the image runs, and your system tools trust it too
Mount the CA from a ConfigMap	When you cannot rebuild the image, or the CA differs between Environments

A CA certificate is public information, so a ConfigMap is fine for it. Never put a private key in a ConfigMap.

Option 1 — bake it into the image

Add the CA to your image's system trust store when you build it. For a Debian or Ubuntu based image:

COPY corporate-ca.crt /usr/local/share/ca-certificates/corporate-ca.crt
RUN update-ca-certificates

Push the new image and deploy it as usual. Java applications also need the CA in the Java truststore — see the table below.

Option 2 — mount it from a ConfigMap

Create a ConfigMap holding the CA certificate in PEM format, using the K8s Config Component — see Shared ConfigMaps (K8s Config).
Mount it into your application as a single file, in the application Component's Helm values (original application chart):
```
app:
  volumes:
    configMaps:
      corporate-ca:
        mountPath: /etc/ssl/custom/corporate-ca.crt
        subPath: corporate-ca.crt
```
Mount a single file with subPath. Mounting a whole ConfigMap over /etc/ssl/certs would hide the image's own CA certificates and break every other HTTPS call.
Point your runtime at the file with an environment variable, from the table below, in app.envValues.
Click Save. The application redeploys with the CA mounted.

A subPath mount does not pick up later changes to the ConfigMap. After changing the CA, restart the application — see Restart an Application or a Single Pod.

Point your runtime at the CA

A mounted file is not trusted automatically. Tell your runtime where it is:

Runtime	Setting	Adds to or replaces the default CAs
Node.js	`NODE_EXTRA_CA_CERTS=/etc/ssl/custom/corporate-ca.crt`	Adds
Python `requests`	`REQUESTS_CA_BUNDLE=<bundle file>`	Replaces
Go, curl, OpenSSL	`SSL_CERT_FILE=<bundle file>`	Replaces
Java	a truststore passed with `-Djavax.net.ssl.trustStore=…` (for example in `JAVA_TOOL_OPTIONS`)	Replaces

Where a setting replaces the defaults, the file must contain the public CA certificates your application still needs as well as your private CA — otherwise calls to ordinary public HTTPS services start failing. For those runtimes, Option 1 is usually simpler.

Verify it worked

Call the partner API or internal service from your application again. The certificate error should be gone. If you have namespace access, you can test from inside the pod — see Namespace Access.

Still having issues?

If the error persists, raise a request with the Component, the hostname your application calls, the exact error message, and which option you used.

Shared ConfigMaps (K8s Config) — creating and mounting ConfigMaps
Use Your Own TLS Certificate — the opposite direction: serving your own certificate to visitors
Container Registry Repositories and CI Push Access — pushing a rebuilt image

Option 1 — bake it into the image

Option 2 — mount it from a ConfigMap

Point your runtime at the CA

Verify it worked

Still having issues?

Related articles