[Docs]: Include information on where TLS certificates for the HTTPS API are stored

[ZelnickB]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to document this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Affected area/feature

I'm running a certificate authority via a Docker container. I have a Docker port forward set up from 127.0.0.1:9000 on my container host to the API listening port inside of the container. I want to make the API accessible via a Nginx reverse proxy (proxy_pass) as follows:

1. Client request to https://certificates.my.lan →
2. Nginx, which presents the same server certificate that is presented by 127.0.0.1:9000 →
3. Nginx decrypts the request and then re-encrypts it using the server certificate presented by 127.0.0.1:9000 →
4. Forwarded request to https://127.0.0.1:9000

I'd like to accomplish this by mounting the SSL/TLS certificate and key used when serving the CA HTTPS API in the container into the container host system and then configuring Nginx to use that. However, I cannot find where this certificate is stored inside of the container. Can this information be added to the documentation?

[hslatman]

Hey @ZelnickB,

The reason you can't find the certificate (nor the key), is that they're only available in memory. They're generated and signed at startup, and the certificate is automatically renewed every 24 hours. It's unlikely we'll change this method of operation soon.

Generally we advise to let the CA perform TLS termination, and when a proxy is to be used, to configure it as a TCP proxy, so that the connection is forwarded directly. On the CA side, you can configure certificates.my.lan as an additional DNS name for the CA, so that it'll be included in its HTTPS certificate, and clients will see it as a valid certificate for the hostname they're connecting to. Here are some docs on this setup: https://smallstep.com/docs/step-ca/certificate-authority-server-production/#proxying-step-ca-traffic.

An alternative is to configure your Nginx with a different TLS certificate obtained from the CA, effectively fronting the CA. The connection between Nginx and the CA will still use the CA HTTPS certificate, but the clients will connect to Nginx's own certificate (chaining to the same root as the CA uses).

Recently we've merged a PR that will make things more flexible in the future, including supplying your own certificates, but we haven't planned building functionalities on top of that one (yet).