Troubleshooting Auth Server Connection Errors with Public Certificates in Teleport

When managing your Teleport infrastructure, encountering issues while using tctl to retrieve user information can be disruptive. Specifically, users employing public certificates might face an error preventing connection to the Auth Server. This article addresses a common problem where the command tctl get user, when executed with a publicly trusted certificate, fails with an “x509: certificate signed by unknown authority” error. This guide will help you understand the issue, its causes, and potential steps to resolve it.

Understanding the “Unknown Authority” Error

The error message:

[CLIENT] Cannot connect to the auth server: Get https://teleport.cluster.local/v2/configuration/name: x509: certificate signed by unknown authority. Is the auth server running on 127.0.0.1:3025?

indicates that the tctl client is unable to establish a secure connection with the Teleport auth server. The core of the problem lies in the client’s inability to verify the SSL/TLS certificate presented by the auth server. This typically occurs because the client does not trust the Certificate Authority (CA) that signed the auth server’s certificate.

In scenarios where publicly trusted certificates, like those from GoDaddy, are used, the expectation is that clients should inherently trust these certificates as their root CAs are generally included in standard trust stores of operating systems. However, misconfigurations or specific Teleport setups can lead to this trust establishment failing.

Scenario: Public Certificate Setup and Connection Failure

Consider a scenario where Teleport is set up using publicly obtained certificates for its proxy and auth services. The intention is to leverage the public trust associated with these certificates to simplify client connections. However, despite successful proxy access via a browser, tctl commands fail to connect to the auth server, throwing the “unknown authority” error.

Configuration Example ( /etc/teleport.yaml )

teleport:
  nodename: proxy.mydomain.com
  data_dir: .data
  auth_service:
    enabled: "yes"
  ssh_service:
    enabled: "yes"
  proxy_service:
    enabled: "yes"
  public_addr: proxy.mydomain.com:3080
  ssh_public_addr: proxy.mydomain.com:3023
  https_key_file: /var/lib/teleport/mydomain_key.pem
  https_cert_file: /var/lib/teleport/mydomain_cert.pem

In this setup:

Public certificates (mydomain_cert.pem, mydomain_key.pem) from a provider like GoDaddy are placed in /var/lib/teleport.
The configuration points to these certificates for HTTPS.
The proxy service functions correctly, presenting the expected login page in a browser.
However, tctl get user fails with the “unknown authority” error.

Potential Causes and Troubleshooting Steps

Several factors could contribute to this issue:

Incomplete Certificate Chain: Public certificate providers often issue certificates that chain up to intermediate and root CAs. The mydomain_cert.pem file must contain not only your server certificate but also the complete chain, typically with your certificate first, followed by the intermediate certificate(s). Ensure your certificate file includes the full chain provided by your CA.
CA Trust Store Issues: While GoDaddy certificates are generally trusted, there might be situations where the system’s CA trust store is outdated or misconfigured.
- Update CA Certificates: On Linux systems, commands like update-ca-trust extract (on systems using ca-certificates) or similar tools for your specific OS refresh the system’s trust store.
- Manual Trust (Less Recommended): As a temporary measure for testing, you could attempt to add the root or intermediate CA certificate to the system’s trusted certificates manually. However, this is generally not recommended for production environments and should be approached with caution.
Teleport Client Configuration: tctl relies on the system’s default trust store. In standard scenarios, no specific client-side configuration for certificate trust is needed when using public certificates. However, if there are unusual network configurations or custom TLS settings, they might interfere with the client’s ability to verify the server certificate.
Hostname Resolution: The error message mentions teleport.cluster.local. Ensure that teleport.cluster.local resolves correctly to your auth server’s address from where tctl is being executed. If teleport.cluster.local is not correctly resolving, especially if you are using a public domain, this could lead to connection issues. While the user in the original post added 127.0.0.1 proxy.mydomain.com to /etc/hosts, ensure that the hostname used in tctl commands and Teleport configuration aligns with the actual resolvable address of your auth server.

Seeking Further Assistance

If you have verified the certificate chain, checked your system’s CA trust store, and confirmed hostname resolution but still encounter this issue, it is recommended to seek further assistance from the Teleport community. The Teleport Community Forum is an excellent resource for asking questions, sharing your specific setup details, and getting help from other Teleport users and experts. When posting on the forum, include details about your Teleport version, OS, configuration files (redacted for sensitive information), and any relevant debug logs (tsh --debug, teleport --debug) to help the community understand your situation and provide targeted guidance.

By systematically checking these potential causes, you should be able to diagnose and resolve the “unknown authority” error and successfully use tctl with your public certificates in Teleport.