SSL certificate works with port 3080 but doesn't with port 3025

I have requested a Let’s Encrypt certificate for the domain pointing to the Teleport daemon server (where all the 3 roles are running), the teleport config file has the 2 attributes https_key_file and https_cert_file pointing to the certificate files, and connecting via HTTPS (port 3080) works fine from the web browser and the CLI.

Running the command openssl s_client -connect returns me:

Verify return code: 0 (ok)

When I’m trying to add a node, it complains about the certificate when trying to GET the Auth API service on port 3025, so I tried again the command with the Auth API port:

$ openssl s_client -connect

But it ends with:

Verify return code: 21 (unable to verify the first certificate)

Looking at the 2 commands output, I have 2 different chains.
For port 3080, the working one:

Certificate chain
 0 s:/CN=
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

For the 3025, the non-working one:

Certificate chain
 0 s:/street=/postalCode=null/O=Admin/CN=XXX7593f-XXXX-XXXX-XXXX-9c3ddffXXXdb.main

So it’s like the Auth API is not using the SSL certificate, or a self-signed one, not sure.

Can you please help me to solve this so that the Auth API uses the right certificate?

The auth API generates its own self-signed certificates by design. The purpose of Teleport’s auth server is to set up two certificate authorities - one for hosts and one for users. It issues certificates from the host CA to authenticate hosts joining the cluster, and issues certificates from the user CA to grant users access.

The only endpoints in a Teleport cluster which should be “public-facing” (i.e. accessible by users) are those on the proxy server, so port 3080 for web access, port 3023 for SSH proxy access, port 3024 for incoming tunnel connections and port 3026 for Kubernetes proxying. To this end, what you’ve done with getting a LetsEncrypt certificate and setting that up for the web endpoint is absolutely the right thing to do and I think you’re most of the way there.

If the error you’re getting is x509: certificate signed by unknown authority then usually this means that you have some cached data left over on your new node’s disk from a previous attempt to join the cluster. The easiest way to fix this is to shut down any Teleport processes on the new node, delete the /var/lib/teleport directory from disk and then try running the node join command again.

Let us know how you get on.

1 Like

Thank you for your quick and clear answer :+1:

Deleting the /var/lib/teleport folder solved the issue for the node that was complaining about the TLS/SSL certificat, thank you!

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.