Building a Node.js Web Server with HAProxy and Let’s Encrypt on Debian Stretch | Hacker News Reader

Building a Node.js Web Server with HAProxy and Let’s Encrypt on Debian Stretch

medium.com

So many issues in this, I have to assume the author is just copy pasting from elsewhere.

I can't see how his setup as-is will ever work beyond the initial certificate lifetime. It is possible to have zero-downtime ACME issued certs with haproxy, but this isn't it.

Hmm so I can't edit any more, so here's a more detailed critique now that I can type a bit easier:

- Certbot is available in the main repo for Stretch, and in Backports for Jessie, including both cron-based and systemd timer-based auto-renewal jobs. The file downloaded seems to be a shell script that installs stuff and.. who knows what else, but it's not exactly clear from a quick glance what the purpose of it is, as opposed to just `apt install certbot`.

- If you want to run the standalone ACME authenticator process on non-standard (i.e. other than 80,443) ports, you need to tell it that using `--http-01-port` and/or `--tls-sni-01-port` options

- The setup seems be attempting to use the `http-01` challenge, but it's doing that in a https front-end, which not only doesn't work (ACME doesn't make http-01 challenges over https) it can't work, because haproxy will never listen on 443 in http mode without the initial certificate. You should be directing requests to the standalone authenticator for the `http-01` challenge from a regular http (port 80) front-end, and for the tls-sni-01 challenge from a tcp-mode front-end/listener on port 443.

- You don't need to open up any firewall ports for the standalone authenticator - the ACME requests will come through port 80 or 443.

- The process of joining certificates for HAProxy (and doing a soft reload) should be handled as a certbot post-hook, otherwise the subsequent automatically renewed certificates will never get merged into one file, and HAProxy will never know about them.

There are numerous other wtf's (those environment variables. Making a `curl` request instead of `ip addr show`, etc) but those are less "this won't work" and more "huh?".

I've addressed everything you've mentioned here. I would greatly appreciate it if you could take a look and offer any constructive feedback.

Many thanks for your time and help.

In the words of Roy Trenneman.... Oh dear oh dear oh dear!

I.. Um. It's different now but I'm pretty sure certs still won't renew, and if they did haproxy wouldn't know about them.

I'm not sure what your motivation is for posting this article but honestly you need a better understanding before trying to give other people technical advice about something.

Edit: also the weirdness persists. Why are you allowing inbound dns requests. Why is your firewall blocking first instead of last. Why are you using sudo for curl that gets piped. Jesus why are you curl|bash at all. I'm pretty sure your cron job is unnecessary and won't even work.

<breathe>... There is still a lot wrong with this but I can't type easily so that will have to do for now

- your HAProxy config expects certbot to listen at port 54321. You never configure certbot to do that, so it won't do it, and renewal will not work.

- if renewal did work, the certs HAProxy is reading are never replaced.

Really, there are already good tutorials for HAProxy and certbot out there, why muddy the water with another, broken attempt at one?

If you are setting this up in a test environment and are writing it up as you go, I recommend having screen recording/shell logging so you can afterwards check exactly what you did and write it down (at least that has helped me in the past). If you don't, then you really should do a test run and verify what you do works. Writing up something you did a while ago without replicating it makes it really easy to miss crucial steps.

Brother, there's a million ways to skin a cat. The article is already 2000 words long and took me a long time to write/test. Going into huge amounts of detail isn't within the scope of the article.

A appreciate the feedback you posted below, and will be making modifications to the article to address some things I wasn't aware of

But, the setup works. There is no zero downtime. I've been using this setup for my smaller applications for over a year and I've never had downtime. Ever.

Also, I rarely provision in bash and haven't provisioned a server manually for a very long time. I use Ansible. But, regular node developers are unlikely likely to be using Vagrant, Docker, Ansible, Chef etc. I didn't want to include that complexity.

I'll address these issues today. You could have gave the feedback without the ear bashing but I'll take that as you're being "cruel to be kind" :)

Peace

The steps you had (I haven't checked for updates) definitely wouldn't produce a working setup - for the reasons I detailed in my other comment.

I'm not saying "this is fundamentally the wrong way to do skin a cat", it seems to be trying to achieve what I consider to be one of the best ways to skin said cat, but the article had (and may still have) actual technical errors that could not produce a skinned cat.

I honestly really appreciate the advice, it's been super helpful. I have now amended the article. I will revisit it tonight and go into a little more detail explaining what everything does.

Reply on news.ycombinator.com