x509: certificate signed by unknown authority in Teleport Proxy Service

Question

When deploying Teleport in a production environment, the Proxy Service must establish a trusted TLS connection to the Auth Service. In local tests the connection succeeds when the Proxy is started with --insecure or when the internal CA is manually added to the host trust store. In production, without --insecure and relying only on the system CA bundle, the Proxy logs the error x509: certificate signed by unknown authority. The unresolved decision is how to configure trust for the internal CA while avoiding insecure TLS bypasses and without altering the global system trust store.

Consider the trade‑offs between pointing the Proxy to the internal CA via --auth.ca-file versus re‑issuing the Auth Service certificate from a publicly trusted CA, taking into account certificate rotation, proxy restart requirements, and compliance with internal security policies.

Should the Proxy be configured with --auth.ca-file pointing to the internal CA bundle, or should the Auth Service be re‑issued a certificate from a public CA? What operational impact does each option have on certificate renewal, proxy restarts, and cluster‑wide trust management?

Tasadduq Burney · Answer

Answer – Use the Internal CA Bundle
The Teleport Proxy must be able to validate the Auth Service’s TLS certificate. The most straightforward and policy‑conformant way to achieve this in production is to point the Proxy at the cluster’s internal CA bundle using the --auth.ca-file (or equivalent) flag. This keeps the Auth Service certificate signed by the internal CA, avoids external dependencies, and eliminates the need for a global system trust store change or the insecure flag.
Why the Internal CA is Preferred

It is the native trust anchor for all Teleport cluster components.
It is already used for certificate rotation, cluster‑wide trust, and audit signing.
Public CAs would expose internal hostnames in Certificate Transparency logs and may not issue certificates for internal DNS names.
Adding the CA to the Proxy’s trust store keeps the system CA bundle untouched, satisfying many compliance policies.

Operational Impact

AspectInternal CA BundlePublic CA Certificate

Certificate RotationRotate the CA bundle; each Proxy must be updated and restarted (or reloaded if supported).Auth Service certificate renews; Proxy may need a restart if it does not automatically reload the system CA store.
Proxy RestartsRequired after any CA bundle change.Required after each Auth Service renewal.
Cluster‑wide Trust ManagementSingle CA bundle managed by configuration management; easy to audit.Requires ensuring the system CA store on every host contains the public root.
ComplianceMatches internal PKI policies; no external root exposure.May violate internal policy if public roots are disallowed for internal services.

Recommended Steps for This Scenario

Verify Teleport Version and Flag AvailabilityRun teleport version and check teleport start --help for the exact flag name (e.g., --auth.ca-file or --ca-file in newer releases).
Export the Internal CA BundleCopy /var/lib/teleport/ca.pem (or the path configured by ca_file in teleport.yaml) to a secure location accessible by all Proxy hosts.
Distribute the BundleUse your infrastructure automation (Ansible, Terraform, etc.) to place the bundle on every Proxy node, e.g., /etc/teleport/ca.pem.
Configure the ProxyStart or restart the Proxy with the flag:teleport start --auth.ca-file=/etc/teleport/ca.pem
Validate the ChainFrom a Proxy host, run:openssl s_client -connect auth.example.com:3025 -showcerts | openssl x509 -noout -issuer -subjectVerify the issuer matches the internal CA.
Automate CA RotationWhen the internal CA rotates, repeat steps 2–4 and restart the Proxies. Consider scripting the restart to run after the bundle update.

When to Consider a Public CA
If your organization’s policy mandates that all externally reachable services use public certificates, you may re‑issue the Auth Service certificate from a trusted public CA. In that case:

Ensure the public root is present in every Proxy’s system CA bundle.
Plan for Auth Service restarts on each renewal (typically 90‑days).
Accept that the internal CA remains required for other Teleport components.

Missing Diagnostic Detail
To fine‑tune the recommendation, please provide the Teleport release you are running (e.g., v12.1.0). The exact flag name and reload behavior vary between releases.

x509: certificate signed by unknown authority in Teleport Proxy Service

1 answer

Answer – Use the Internal CA Bundle

Why the Internal CA is Preferred

Operational Impact

Recommended Steps for This Scenario

When to Consider a Public CA

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments

Aspect	Internal CA Bundle	Public CA Certificate
Certificate Rotation	Rotate the CA bundle; each Proxy must be updated and restarted (or reloaded if supported).	Auth Service certificate renews; Proxy may need a restart if it does not automatically reload the system CA store.
Proxy Restarts	Required after any CA bundle change.	Required after each Auth Service renewal.
Cluster‑wide Trust Management	Single CA bundle managed by configuration management; easy to audit.	Requires ensuring the system CA store on every host contains the public root.
Compliance	Matches internal PKI policies; no external root exposure.	May violate internal policy if public roots are disallowed for internal services.