Tips on setting up TLS?

[bubelov]

I'm trying to figure out the easiest way to deploy a Rocket-based app on a Linux server. The app is supposed to be self-hosted, so ease of installation and maintenance is crucial. Having a single self-contained binary is already a huge win, but setting up TLS does require a few extra steps. Here is a few options I thought of:

1. Bind to port 80 directly (super easy, but no TLS)
2. Create a self-signed cert and bind to port 443 directly (slightly more involved + all the usual issues with self-signed certs)
3. Install nginx + certbot and proxy-pass to the app (it's getting a bit more involved but still manageable if documented well)
4. Bind to port 443 directly and let certbot issue and renew certs automatically (no nginx proxy, one less step and dependency)

I like option 4, but option 3 exposes both ports 80 and 443 and takes care of HTTP -> HTTPS redirection. Not having that isn't a big deal for my particular use case but it's a nice feature to have. Is there a way to configure Rocket to do the same or maybe someone can recommend a simpler way of achieving the same goal?

[the10thWiz]

I'm not sure what the best option is, but I hope to be able to give some insight.

Ideally, it would be best to avoid the need to run nginx, since it could (in theory) impact the performance of the server. However, if performance isn't a critical concern, I wouldn't worry about it.

There is (I believe) an open issue in Rocket for adding the ability to swap the TLS Cert without restarting Rocket, but I don't think this has been addressed yet. I'm not aware of any ability for Rocket to redirect http requests to https (i.e. 80 -> 443), but I think this might be worthy of a feature request. I assume the server bound to port 80 would just serve back a redirect to the same url, but with https.

If the first issue (Rocket swapping TLS certs on the fly) is addressed, it could (in theory) be possible for a certbot type client to be built into the same executable, allowing you to eliminate that dependency as well.

[bubelov]

If the first issue (Rocket swapping TLS certs on the fly) is addressed, it could (in theory) be possible for a certbot type client to be built into the same executable, allowing you to eliminate that dependency as well.

That would be really cool because it would make self-hosting more accessible. Multi-port and redirect rules are probably more controversial because it can be sorted out via reverse-proxies but bringing up another web server just for serving redirects also feels odd =)

Are you aware of any host header filtering? It looks like Rocket can be bound to an IP address but not to a domain name

[the10thWiz]

As far as I'm aware, Rocket doesn't bind to more than one port. Even if it did, some major changes would need to be made to handle routing the traffic correctly. Having a route redirect is actually quite easy, you just return a Redirect. Bringing up a second server is a bit odd now that I'm thinking about it, but it still feels like the best option. That being said, if you only need to support modern browsers, I would just bind to port 443, and call it a day. Most modern browsers should automatically try https (i.e. port 443) first anyway, and even if they don't, they should automatically try it after http (port 80) fails. I would test this, but I'm pretty sure it should just work.

As far as I'm aware, Rocket doesn't do host header filtering. Rocket is typically intended to be run for a single service (i.e. host), so reverse proxies are probably the correct solution for that. Technically, it is possible to have a route make a web request to a third party server, and serve the response, but I don't think this is particularly common. Rocket is also definitely not designed to be a scalable reverse proxy.