Auto-provision a signed TLS certificate for proxy with LetsEncrypt

[awly]

Feature Request

Consider compiling a LetsEncrypt client into teleport to make setup easier.
A proxy can attempt to get certs for itself before falling back to self-signed certs.
Of course, we should always respect user-provided certificate first.

What if a proxy is behind a load-balancer that terminates TLS?
The ACME challenge will fail and proxy should fall back to self-signed certs.

Examples of this in the wild:

• https://caddyserver.com/docs/automatic-https
• https://github.com/haproxytech/haproxy-lua-acme
• https://perkeep.org/doc/server-config
• https://docs.gitea.io/en-us/https-setup/#using-lets-encrypt
• etc https://pkg.go.dev/golang.org/x/crypto/acme/autocert?tab=importedby

Motivation

The proxy today automatically provisions self-signed certificates.
This is better than no TLS, but has a few downsides:

• conditioning the user to ignore browser warnings and pass --insecure to the CLI
• making a production user learn and deal with certbot or some other way of getting TLS

It's 2020, TLS can be made simple and automatic.

Who's it for?

OSS User, Pro, Enterprise

[webvictim]

Great idea. The way that Caddy does this is incredibly simple to use.

[benarent]

+1 for this, our marketplace image is bundled with LetsEncrypt but it's just for DNS based verification, but I ended out using an external DNS so installed certbot.

What's our thoughts of local testing / setup? Maybe we just recommend people use https://github.com/FiloSottile/mkcert

[webvictim]

+1 for this, our marketplace image is bundled with LetsEncrypt but it's just for DNS based verification, but I ended out using an external DNS so installed certbot.

The certbot installed there should work with the regular ACME .well-known flow too - we just haven't provided any instructions about how to do that.

What's our thoughts of local testing / setup? Maybe we just recommend people use https://github.com/FiloSottile/mkcert

I haven't actually used mkcert but remember seeing it when it was first published and I like the principle a lot. It could be perfect for a Teleport PoC on one machine where you want to test the web UI without issues.

It's worth noting that one disadvantage would be that it would prevent IoT/node tunnelling (joining via port 3080) from working out of the box, unless you could also add those certs to the certificate chain somehow on the remote node such that Go can use them. Then again, this would also be an issue when using self-signed certs unless running with --insecure anyway, so it certainly doesn't make the situation worse. Nodes can still be joined via the auth server in the regular way - provide a token and CA pin hash and connect to port 3025.

[webvictim]

Optional extra goal: allow endpoints to be overridden so that users can use other ACME-compatible providers if LetsEncrypt is not to their liking.

[webvictim]

This is related to #3815

[webvictim]

The request for automatic LetsEncrypt integration becomes much more relevant with AAP because we currently expect people to mostly either:

• get their own cert for every app_service.public_addr they set up (using certbot -d teleport.example.com,app1.teleport.example.com,app2.teleport.example.com)
• get their own wildcard cert (using certbot -d teleport.example.com,*.teleport.example.com)

We should seriously think about automating the certificate part as an optional setting so that people can have Teleport installs which just do the right thing out of the box.

[webvictim]

@klizhentas Was this covered as part of #5178? We now have some ACME support, but I'm not sure whether it handles wildcard/multiple SNIs for app_service.

[awly]

This still needs docs

[benarent]

Closing this issue as the initial ACME support have been rolled out and the feature is outlined in our getting started guides.