Setting up a static HTTPS website on your Raspberry Pi using Docker and Nginx | Hacker News Reader

Setting up a static HTTPS website on your Raspberry Pi using Docker and Nginx

gist.github.com

56 pointsrain177 comments

I was initially looking at this to see how they automated their Let's Encrypt and if it was better than just using Caddy. I was disappointed to find they are just creating a self-signed RootCA and issuing certs.

  > Now if you go into Chromium browser settings and search "certificates", in the Security tab, Manage Certificates, you can add an Authority. Import 'ca.pem'. Tell the browser to Trust this certificate for identifying websites. This should add 'org-test-ca' to your browser. This allows HTTPS certificates signed by that to be seen as valid in your browser.

This is how I automate LE (technically ACME/ZeroSSL) in my Nginx reverse proxy.

https://git.inportb.com/jyio/docker-nginx-auto

Basically, inotifywait on the config directory and request new certificates as needed. Grep the config files for hostnames (and ignore if labeled NOSSL). And a configuration snippet to include the same SSL config for anything that needs SSL (including the .well-known/acme-challenge directory). Oh, and use cron to renew periodically.

> inotifywait on the config directory

I like this idea. I'm going to start using this.

Just be aware that nginx needs a self-signed certificate in the very beginning, to serve the .well-known/acme-challenge directory. To simplify the initial setup, I include a default "snake oil" certificate, which gets overwritten.

It doesn't. You can serve it over http.

Interesting! Thanks for pointing that out.

Though... I think I'd still include the snake oil cert and serve everything over SSL, because it simplifies the configuration.

With apache2 httpd, you can of course serve the challenge over insecure HTTP, but httpd won't start if you say it should use a cert that doesn't actually exist, so for the sake of automated setup and not having to edit the config multiple times it's way easier to write a self-signed cert and then overwrite it with LE. I think the situation is the same with nginx but not 100% sure.

I just use dns and acme.sh for that reason and not bother about it anymore

You can use IfFile to gate the TLS part of the server until the certificate file exists, if you really don't want to edit your config files during TLS bootstrap.

The situation is the same with nginx. It's way easier to write a self-signed cert and then overwrite it with LE.

How I solve this is that I deactivate all configuration files that have missing certificates, and then reactivate them again after the files have been created.

https://github.com/JonasAlfredsson/docker-nginx-certbot

> I was disappointed to find they are just creating a self-signed RootCA and issuing certs.

Agreed. Not sure why you'd go through the trouble of importing a self-signed CA when you can provision certs for any internal service with LE. I dont use self-signed and instead have been using LE certs provisioned for internal services for the last couple years. Extra nice to be able to leverage DNS challenge for cert provisioning at home to get around overloading common ports.

I know a lot of people mention Caddy but I find Traefik [0] (pronounced "traffic") more flexible. It's routing and middleware configurations are fantastic. Especially when you want to stick a reverse proxy in front of things that are a pain to provision certs into (switches, routers, old embedded web interfaces, etc).

[0] https://traefik.io/traefik/

didn't know you could do this with LE. Good tip. Although this seems quite complicated to do.

A lot of webservers now have ACME built in and you can just have it automatically handle the entire certificate life cycle.

Do it 90s style.

Install apache (or nginx or lighttpd) on your box using your distros package manager of choice.

Configure https on apache.

Seriously. Adding a docker layer to a device as lightweight as a Raspberry Pi just seems like insanity.

It doesn’t really. Don’t confuse docker with a virtualization layer. Well made containers bring just the processes you’d be running anyway.

I run a few containers on my RPi and cannot tell a difference in performance.

I agree if the container brings any benefits. In this case there is nothing that a standard distro-packaged apache/nginx wouldn't do. There is no automation of build steps, lets-encrypt or similar.

Installing docker and running that daemon for just this is not the right way.

> Seriously. Adding a docker layer to a device as lightweight as a Raspberry Pi just seems like insanity.

Your definition of insanity is perplexing. Docker in this context is pretty trivial to setup and run, and it's used mainly to manage packaging and deployment. Do you happen to have any experience at all with Docker?

Yes, and it's doubly pointless here, because it isn't doing anything that couldn't be done better by the OS's own package manager. Better, probably, because you will get timely security updates.

> Yes, and it's doubly pointless here, because it isn't doing anything that couldn't be done better by the OS's own package manager.

No, not really. With Docker, packaging is a solved problem, and you also get for free a deployment history which you can roll back and forward at will. You also get introspection and blue/green deployments, and if you really want to you can also setup a cluster of nodes for free where you can run whole application stacks with a one-liner.

There is really no excuse to do things the hard way.

It still does have a non-zero cost, especially in the long run, when security vulnerabilities pop up. With distribution package management, on Ubuntu, you can rely on your Nginx being updated and restarted automatically while you sleep. With Docker, you need to subscribe to a security mailing list in order to know about the vulnerability in the first place, and then run some commands manually that re-create the container.

> It still does have a non-zero cost, especially in the long run, when security vulnerabilities pop up.

It really doesn't. Unless you were planning on doing a one-and-done deployment, it's trivial to update and redeploy Docker images. Even in my side projects I have CI/CD pipelines updating and redeploying Docker images daily.

> With distribution package management, on Ubuntu, you can rely on your Nginx being updated and restarted automatically while you sleep.

Whatever you can do with Ubuntu, you can do precisely the same with Docker when running a base image of Ubuntu.

> With Docker, you need to subscribe to a security mailing list in order to know about the vulnerability in the first place, and then run some commands manually that re-create the container.

No, you really don't. Just pull the latest base image, build your images by calling apt to update your dependencies, and you're done.

Whatever you can do with a bare metal/VM install, you can do with Docker.

There is nothing magical stopping you from doing the basic stuff with Docker.

patrakov is talking about updating the docker daemon/engine (that runs on the host), not the images that you run with docker.

Nope, I was talking about the images. More precisely, about knowing when to update them.

Docker is extremely light weight and I wouldn’t have any concerns about running it on an rpi

It seems like a lot of work to serve a static site over your local network. How is this different from running `python -m SimpleHTTPServer`?

For development I'm sure SimpleHTTPServer is fine for most use-cases (except SPAs, of course), but for more serious use, nginx and SimpleHTTPServer couldn't be more different.

Doesn't involve installing an obsolete version of Python.

I just meant if you aren't exposing it to the outside world, why not use any other server? Curious about the real advantages.

python -m http.server

ok fun guy

Why even use docker for a static website server?

"One command" production ready server

You mean like `apt install nginx`? :)

I am not a fan of docker for everything but 'apt install nginx' would not give you https out of the box. I am beginning to like Caddy which comes with https enabled but I have never used it in production yet.

If you want https you can just run certbot. It will bootstrap the nginx config. I dislike programs that change the configuration automatically, and thus run dehydrated instead of certbot, but running apt install nginx certbot and some certbot incantation to make it bootstrap your domains is not really any more bothersome, than having to figure out how docker works, and how to manage changes to my nginx config with it over time, etc..

I totally disagree with this reply, and agree with the thread starter... I really, really do not see the point of this.

One command? Did you read the github page?

At the end, this doc even has you hand editing your nginx for SSL?!? Why on earth... why not just use certbot automation? This seems totally counter to the idea. Again, am I being dense? Is this just "look what I can do with docker that makes my life more complicated"? Honestly, at this point it feels like more work for less output.

This seems way harder than installing nginx and certbot, and now I have a hard dependency on docker and whatever else you pulled in.

Seems like optimizing a thing that's already pretty quick and easy to set up (and using docker and similar does not mean you don't need to understand how nginx works).

To learn a bit about Docker?

Spawn a VM instead of mutilating your Pi?

Hacking is called mutilating now? Give the guy/girl a break. I don't think this is meant to be a production setup so whatever is fine, and you can always reflash it if needed so not sure I'd call this "mutilation"

Your docker-compose file becomes configuration-as-code, and it's a one-line change to set up different websites on different ports.

Sure, I could install lighttpd myself, but docker-compose gives me a common configuration file format.

Docker is a hard dependency if you need your article on the front page of HN.

Tangential at best: where can you get a hold on a Raspberry Pi 4 in Europe? Every store is sold-out and the ones that aren't only allow one per customer.

Pimoroni has some in stock https://shop.pimoroni.com/products/raspberry-pi-4?variant=29...

> This product is limited to 1 per customer

Most people just need one, fortunately.

Sure, that's probably true. Wasn't what I asked for in my original comment though :)

Oops, sorry didn’t notice that they are doing this now. I’ve bought some at few weeks of distance tho (a zeroW and a 3B)

Are there any other, more available cheap boards, that could run a simple web server?

ive reflashed old routers with openWRT into a server cluster, they are a lot more portable, quiet and power efficient, of course this doesnt scale up well as the hardware has its limits. keep in mind you dont have to host the entire website on one server, so you can balance the load that way if you need to.

Check out some of the supported boards for armbian, nanopis are usually pretty cheap and decent enough.

Why are pis so often limited like this, is it a requirement from the foundation? Just curious.

Demand outstrips production. Especially with a chip shortage and lots of people stuck inside lookin for projects.

So why does the retailer benefit from limiting like this? To sell more starter kits etc?

https://rpishop.cz/869-mini-pocitace

> Maximálně 1 ks na zákazníka.

Which I assume means something like "This product is limited to 1 per customer"

https://botland.com.pl will sell you up to 10.

Thanks, looks like a nice choice! Unfortunately they only have 2 (4GB model, rest is out of stock) in stock at the moment ("Available quantity: 2" it says), but will keep an eye for when they get re-stocked.

https://www.verkkokauppa.com/fi/product/57364/mndkd/Raspberr...

You might want to also grab the sd card from there.

I recommend getting the power supply, case and fan from Digikey.

It's a bit more work, but for single-digit quantities you could just buy one per store from a bunch of vendors, possibly repeating weekly or whatever until you get the desired number?

I accomplish this with raspberry pi + docker + swag https://docs.linuxserver.io/general/swag

I'm ashamed that I was so naïve about this, but I was disappointed to realize that hosting a website to the entire public internet on my Pi was non-trivial. Of course once I dug into the idea it was obvious why it was difficult and furthermore that it would be a dangerous thing to do. Just sharing and curious if anyone has done it or knows useful documentation on the topic.

Why was is complicated? I'm hosting https://talumriel.de for my German novels on a Rapberry Pi 3b, using Nginx and Letsencrypt with cryptbot. It's probably not super-secure, but the setup was very easy. I basically just followed one of the tutorials on the Net.

Just FYI, your server is not reachable with the IPv6 address.

Thanks. I think it's because of my router.

It sounds like you Pi doesn't have a public IP address. So you need some way to tunnel requests to it. On solution would to be SSH into one of your own public boxes somewhere and use reverse port forwarding (-R). Although that's probably not very reliabile on its own as you have to make sure the connection stays alive. More professional solutions are probably ngrok or cloudflare tunnel. The latter is meant exactly for what you describe: expose a service on a private machine as a public facing web site.

Port forwarding from your router is another option, redirect all 443/80 traffic from the public interface of the router to your Raspberry, preferably on a separate VLAN and also firewalls on both your router and Raspberry before enabling that.

Some VPNs offer public IPs, too (and from some, even static IPs can be bought). E.g. PureVPN.

This guide is just for hosting locally. If you want to host to the outside internet you also need to do port forwarding on your router. So that when someone connects to your outside IP your router relays that to the pi specifically.

It's not super dangerous, just make sure you keep everything updated (your linux OS, your server software). And make sure that you only open the ports you need to.

I've been hosting my application on a 3B+ for years. What makes the Pi different to any other machine that you have on your home network? Assuming you have a static IP, all you have to do is forward ports 80/443 (or whatever) to the right machine/ports.

They're great little machines for this exact purpose. No need to have a full blown PC serving trivial stuff. Only problem is, they use SD cards and eventually. I've had a quality 128GB card in mine that has died/been corrupted about 3 times in 4 years. That's my biggest issue with these amazing little machines

Instead of opening ports on your firewall, you could introduce a mesh. I'm using nebula by slack, rest is 90's style with apache /nginx, lego for le dns-challenged certs, and the nebula lighthouse as a proxy. Works fine, is secure and does not bind 443 on your router to.a specific pi.

Why in the absolute hell does a static site need docker? I don't get it, it is not that hard to properly configure software.

the goal was to run nginx in docker, if you want to run nginx without docker you can just not do the docker parts. not sure what you mean about properly configure software - you can configure nginx the same whether you use docker or not?

Why does a static site even need hardware? Just drop it on GitHub/lab pages and call it a day.

This is a bad guide and should be recognized as such. They should be using certbot or some other utility, not creating their own CA.

One command" production ready server

Reply on news.ycombinator.com