LetsEncrypt support for sandboxes

[lmakarov]

This is a followup issue to the Allow usage of own certificate per project + HTTP-->HTTPS redirect PR.

Once LetsEncrypt adds wildcard cert support, we'll want to explore the option to integrate that into the CI sandboxes workflow. Using wildcard certs should help with the rate limits LE has.

docksal/vhost-proxy is "heavily inspired" by https://github.com/jwilder/nginx-proxy, which has LE integration available via a companion container.

Note: LE won't work for local domains (e.g. *.docksal).

[frederickjh]

Setting DOCKSAL_DNS_DOMAIN= in .docksal/docksal.env one can setup a real internet domain to use with Docksal. One must of course make sure that DNS, (dynamic, internet, router, local, etc.) is setup correctly to resolve the internet domain.

Since the ability to set a real internet domain name to use with Docksal has already been added, this should be taken into account when LetEncrypt support is added.

[lmakarov]

LetsEncrypt released wildcard cert support a few days ago! https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

[lmakarov]

I've got a POC with automatic LetsEncrypt cert generation working using GUI/lua-resty-auto-ssl (on a sandbox server, where LE can verify the domain ownership).

Here's a good article on this approach: How We Generate SSL Certificates for Custom Domains using Let’s Encrypt

[sean-e-dietrich]

@lmakarov have you been able to commit this into a branch somewhere or is the POC available to check? I am having a similar issue where I need LE for a project using sandboxes.

[frederickjh]

@sean-e-dietrich I see a branch feature/certs here on github on this repo. It has three commits ahead of the develop branch. The last commit was on June 19, so it may or may not have all @lmakarov final work from his POC.

[lpeabody]

@lmakarov ping on this, just curious where this stands? I'm trying to get automatic LetsEncrypt cert generation working right now and just found this issue.

EDIT: I reviewed the feature/cert branch, but I didn't notice if there was a mechanism in those changes that automatically generated certificates from LetsEncrypt... I've been digging into LetsEncrypt for a grand total of one day at this point, so it's easily possible I'm just not noticing something :)

EDIT2: FWIW, our initial thinking was to use domain validation to update a file in the domain's path. Say our CI sandbox lives at ci.docksalsandbox.com. vhost-proxy owns that domain. Ideally, we could configure vhost-proxy to serve the domain validation file. Our reason for wanting vhost-proxy to serve the file is because its easier for us to automate management of that file vs automating management of a TXT DNS record (our provider doesn't support any sort of API for managing DNS records, unfortunately) for getting domain validation working.

[lmakarov]

@lpeabody this is on hold. There may be a larger overhaul of the vhost-proxy service coming in the next few months, which will replace nginx/openresty altogether.

Internally (at FFW) we use certbot to generate a wildcard cert for our sandbox server domain every 3 months. The cert is installed (copied over manually) and picked up by vhost-proxy. The docs for this are in this repo's README. There's also an issue in the main project to cover this used case better on docs.docksa.io.

While that is not a fully automated approach, it does not present a lot of overhead and works just fine for us.

[lpeabody]

Thanks for feedback @lmakarov. Mind if I ask what domain validation method you are using? DNS record or file?

We currently have Certbot generating the wildcard cert, copying that into ~/.docksal/certs and setting DOCKSAL_VHOST_PROXY_DEFAULT_CERT="ci.docksalsandbox.com", and run fin system reset vhost-proxy and that is working very well.

However, to fully automate the process we need to automate the domain validation portion of it as well. As state above, we don't have a mechanism for automating the DNS method, but we can do it using the file method. We'd have to serve that file somewhere in a path off of ci.docksalsandbox.com, which means vhost-proxy would have to serve that file.

I won't push the issue since the openresty implementation of vhost-proxy is being phased out, but I'm just wondering if you have any insight into how you would go about modifying vhost-proxy to serve that single file if requested directly on the ci.docksalsandbox.com domain?

[lmakarov]

Wildcard certs can only be validated using the DNS method, so that's what we are using. It's a manual process for us as well. While it could be automated in our case (AWS Route 53), the overhead has not been large enough to pursuit this.

The HTTP challenge (file) method can only be used for individual domains. This is what GUI/lua-resty-auto-ssl plugin does (used on the POC). I don't know if this can be easily done using just certbot and pure nginx config.

[lpeabody]

Awesome, that helps simplify some things for us. Thank you very much for the insight!

[frederickjh]

@lpeabody if your DNS registrar has an API the chances are good that the automate tools that are out there to renew Let's Encrypt wildcard certificates will work for you. I have seen several of these recently but can't remember their names. Let me know if you need help tracking them down.

[lmakarov]

Automated LE support was implemented in docksal/sandbox-server a while ago. That integration assumes that all projects on the server use the same base wildcard domain. I believe this covers the original scope of this issue.

Supporting LE with custom domains falls more into the production hosting category, which is a different use case. While vhost-proxy can be used there, it has not been designed for that use case.

Traefik is something that can be used in prod. If interested, take a look at the "Docksal in production" POC I put together a while ago: https://github.com/lmakarov/docksal-prod-poc