letsencrypt integration for static publishing

[mrdomino]

I want to static publish a bunch of stuff over https. Right now, my janky solution to this is to have nginx proxy to sandstorm and stick a letsencrypt certificate on it. This forces nginx and sniproxy into my configuration (to also serve sandstorm's https from the same host.)

It'd be cool if Sandstorm could just get a cert from letsencrypt and do the whole approval dance on its own.

[zeigerpuppy]

agreed, it would be even better if letencrypt supported wildcards, but this looks unlikely at the moment.

[mrdomino]

I haven't looked at this in much detail, but it looks like Certbot might make this easier somehow.

[mrdomino]

@mischief points out that https://traefik.io/ exists.

[opensamba]

Hello, in order to make letsencrypt work with sandstorm I've a question about this: there's a way for sandstorm to know which subdomain will be generated for every grains and run an action before of this ?

if so, we can try to run a cmd like:

certbot -d $FQDN -i $EMAIL certonly  

before to generate the grains and create a specific letsencrypt cert for this every subdomain in sandstorm.

is it possible?

[kentonv]

@opensamba Please see the docs on wildcard hosts, especially the FAQ: https://docs.sandstorm.io/en/latest/administering/wildcard/

Unfortunately it's really not feasible to use Let's Encrypt with a Sandstorm server. We've talked directly to people who work on Let's Encrypt about this but there's currently no timeline for anything changing (they would have to add support for wildcard certs).

However, @mrdomino's question was different: He wants to use Let's Encrypt for sites published using certain Sandstorm apps (e.g. the Wordpress). That is entirely feasible.

[crackcomm]

Seems like wildcards are supported in Let's Encrypt.

[arthurzenika]

Lets Encrypt wildcard support would be awesome.

[xet7]

Let's Encrypt wildcard renew requires updating domain TXT records with Certbot (Nginx, Apache) or Caddy's similar autoupdate features, to get wildcard verified. I'm not a Sandstorm developer so I don't know how this would work on Sandstorm, and is it related to Sandstorm at all. If some webserver in front of Sandstorm provides Let's Encrypt wildcard, and proxies to Sandstorm, is it any different from having normal wildcard cert. Someone could try.

[zeigerpuppy]

Letsencrypt wilcard certs work just as any other wildcards do. They are fine to use with a reverse proxy infront of Sandstorm (I have tested with Apache as a proxy). There are a number of ways to deploy using the wilcard certs but the following is required:

1. control over DNS TXT record
2. ability to place a unique record on the web server
3. a compatible certbot client (the wildcard supporting version is quite new and not packaged up for most distros yet) The easiest way I have found to do this is to use the certbot docker container and then run something like the following:

docker-compose run certbot certonly --manual -d *.sandstorm.server.net -d sandstorm.server.net --server https://acme-v02.api.letsencrypt.org/directory

[kentonv]

3299 adds a bunch of code that can be reused to implement this issue, such as setting up a Let's Encrypt account. But it doesn't get us all the way there, because it only covers the Sandstorm server's main host, not aliases used for web publishing.

The things we still need are:

• In C++ gateway code, inspect SNI for incoming TLS connections. When it doesn't match the main hostname / wildcard, make an RPC to the shell requesting a certificate.
• In the shell, store certificates for web publishing domains.
• When a new domain is seen, request a certificate from Let's Encrypt on-demand using an HTTP challenge, which should complete quickly.
  • We may want to verify somehow that the hostname's public-facing DNS is really pointing to the Sandstorm server before making a Let's Encrypt request, so that this can't be exploited to spam Let's Encrypt with bogus certificate requests. We could maybe deploy a pretty simple Cloudflare Worker to do such verification...

[kpreid]

We may want to verify somehow that the hostname's public-facing DNS is really pointing to the Sandstorm server before making a Let's Encrypt request, so that this can't be exploited to spam Let's Encrypt with bogus certificate requests. We could maybe deploy a pretty simple Cloudflare Worker to do such verification...

With only this check, an attacker could create DNS entries pointing at your server, then visit them, to cause your server to flood Let's Encrypt. How about verifying that the name is one the server thinks belongs to it (i.e. there is static publishing data present for that name)? That will limit the set of names requested, which will keep things under control if paired with an outgoing request rate limit (which you need anyway to avoid tripping Let's Encrypt's maximum verification attempt rate in case of networking/DNS problems).

[zenhack]

Seeing as I've been exploring re-working static publishing to use the powerbox anyway, that may have implications for when we can check for the cert. It might be nice to find a way to do the check and acquire the cert when the static host is set up, rather than on first access.