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

https://medium.com/@jamesjefferyuk/building-a-nodejs-web-server-with-haproxy-and-lets-encrypt-on-debian-stretch-2fbf16cfba3a

by JamesTheHacker • 9 years ago

1 8 9 years ago

medium.com

stephenr4• 9 years ago

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.

stephenr4• 9 years ago

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?".

JamesTheHacker3• 9 years ago

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.

JamesTheHacker3• 9 years ago

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

stephenr4• 9 years ago

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.

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

Related Stories