5 ms·

That rant sounds like me some years and years ago. I don't mind if the protocol if FUBAR. It works for me and it works for an awful lot of people. And it encry

That rant sounds like me some years and years ago. I don't mind if the protocol if FUBAR. It works for me and it works for an awful lot of people. And it encrypts the web. Before that, it was manually re-creating a cert, faffing with chains (converting formats and dealing with bad documentation) and update the production servers manually. It was a royal PITFA. Don't forget to set a calendar reminder for the next year's renewal.

agjmills 4y ago
Or better, an alert to check the cert is still valid
- yebyen 4y ago
  You don't want an alert to check the cert is still valid, that's how you get outages. It's an alert to check cert has at least 2 weeks or more life left in it! (So it either fires ideally before you leave for that long vacation, or so that you can still take care of it when you get back.)
  - agjmills 4y ago
    But also check it’s still valid, because revocations
    - GauntletWizard 4y ago
      This is all built in very nicely to https://github.com/prometheus/blackbox_exporter https://github.com/prometheus/blackbox_exporter - Though they could use a blazing red link to an example rules file.
caiusdurling 4y ago
There's also issuance via DNS which took most of the complexity out of it for me. (Especially as the first time I went to deploy LetsEncrypt I had something like four web servers behind a LoadBalancer without the LB terminating TLS.) I think the tooling has improved somewhat since too, although I didn't look too closely.
- Zekio 4y ago
  issuance via DNS is awesome when it comes to LE, lets you get certs without your service being reachable from the outside
KronisLV 4y ago
> I don't mind if the protocol if FUBAR. It works for me and it works for an awful lot of people. And it encrypts the web. To me, it feels like most stuff becomes much more troublesome once you peel back the curtain and drop down to the internals. For most folks (myself included), using a web server that handles most of this for you will be enough. There's Traefik, there's Caddy and plenty of other options. Even Apache has support for ACME with mod_md, about which I wrote on my blog last year: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-httpd-in-2022 https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... It's not perfect (you still need a restart/reload for the new cert to be actually used), but the configuration side of things is simple enough and most of the issues are known: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html > Before that, it was manually re-creating a cert, faffing with chains (converting formats and dealing with bad documentation) and update the production servers manually. It was a royal PITFA. This has always been a pain to me, for example, the OpenSSL CLI is a bit like tar in how unintuitive it is, vs something like the Docker CLI which walks you through a tree of commands with all of their parameters that you might be interested in. Curiously, I've had most success with using graphical software for manually working with certificates, like Keystore Explorer: https://blog.kronis.dev/tutorials/lets-run-our-own-ca https://blog.kronis.dev/tutorials/lets-run-our-own-ca The linked article is a bit barebones (I didn't feel like Googling for the OpenSSL equivalents for the actions to demonstrate the difference in UX), but I want to express the importance and usefulness of your software (CLI, TUI, GUI, API, whatever) telling you what options are available to you, which makes a world of difference. In my eyes, there's no reason why a junior dev or someone who hasn't worked with OpenSSL (or an equivalent piece of software) in the past should have their first time doing so be miserable. Then again, needing to think about bunches of different formats and what technology accepts what is probably always going to be at least moderately painful or annoying: https://serverfault.com/a/9717 https://serverfault.com/a/9717 > Don't forget to set a calendar reminder for the next year's renewal. Thankfully, this is pretty easy to deal with! Even if you use ACME, you'll still want this in place, in case automatic cert renewal fails, or if the cert just isn't swapped over to by the web server. For example, for the self-hosting crowd, something like Uptime Kuma allows you to have all sorts of reminders, including certificate expiry: https://github.com/louislam/uptime-kuma https://github.com/louislam/uptime-kuma (note: Uptime Kuma does not batch those notifications, I got about 30 messages in Slack at the same time because a bunch of sites had the same wildcard certificate that was going to expire) Basically, it's nice to see that as a end user of software you can have a decent experience, for the most part. Definitely a bit better in some regards than what you might have been dealing with 10 years ago or so. Not that all of the problems or nitpicks are solved, or will be for the foreseeable future. Personal worries: what if Let's Encrypt becomes a non-viable option for whatever reason? There aren't that many ACME compatible providers out there.

agjmills 4y ago

Or better, an alert to check the cert is still valid

yebyen 4y ago
You don't want an alert to check the cert is still valid, that's how you get outages. It's an alert to check cert has at least 2 weeks or more life left in it! (So it either fires ideally before you leave for that long vacation, or so that you can still take care of it when you get back.)
- agjmills 4y ago
  But also check it’s still valid, because revocations
  - GauntletWizard 4y ago
    This is all built in very nicely to https://github.com/prometheus/blackbox_exporter https://github.com/prometheus/blackbox_exporter - Though they could use a blazing red link to an example rules file.

caiusdurling 4y ago

There's also issuance via DNS which took most of the complexity out of it for me. (Especially as the first time I went to deploy LetsEncrypt I had something like four web servers behind a LoadBalancer without the LB terminating TLS.) I think the tooling has improved somewhat since too, although I didn't look too closely.

Zekio 4y ago
issuance via DNS is awesome when it comes to LE, lets you get certs without your service being reachable from the outside

KronisLV 4y ago

> I don't mind if the protocol if FUBAR. It works for me and it works for an awful lot of people. And it encrypts the web. To me, it feels like most stuff becomes much more troublesome once you peel back the curtain and drop down to the internals. For most folks (myself included), using a web server that handles most of this for you will be enough. There's Traefik, there's Caddy and plenty of other options. Even Apache has support for ACME with mod_md, about which I wrote on my blog last year: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-httpd-in-2022 https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... It's not perfect (you still need a restart/reload for the new cert to be actually used), but the configuration side of things is simple enough and most of the issues are known: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html > Before that, it was manually re-creating a cert, faffing with chains (converting formats and dealing with bad documentation) and update the production servers manually. It was a royal PITFA. This has always been a pain to me, for example, the OpenSSL CLI is a bit like tar in how unintuitive it is, vs something like the Docker CLI which walks you through a tree of commands with all of their parameters that you might be interested in. Curiously, I've had most success with using graphical software for manually working with certificates, like Keystore Explorer: https://blog.kronis.dev/tutorials/lets-run-our-own-ca https://blog.kronis.dev/tutorials/lets-run-our-own-ca The linked article is a bit barebones (I didn't feel like Googling for the OpenSSL equivalents for the actions to demonstrate the difference in UX), but I want to express the importance and usefulness of your software (CLI, TUI, GUI, API, whatever) telling you what options are available to you, which makes a world of difference. In my eyes, there's no reason why a junior dev or someone who hasn't worked with OpenSSL (or an equivalent piece of software) in the past should have their first time doing so be miserable. Then again, needing to think about bunches of different formats and what technology accepts what is probably always going to be at least moderately painful or annoying: https://serverfault.com/a/9717 https://serverfault.com/a/9717 > Don't forget to set a calendar reminder for the next year's renewal. Thankfully, this is pretty easy to deal with! Even if you use ACME, you'll still want this in place, in case automatic cert renewal fails, or if the cert just isn't swapped over to by the web server. For example, for the self-hosting crowd, something like Uptime Kuma allows you to have all sorts of reminders, including certificate expiry: https://github.com/louislam/uptime-kuma https://github.com/louislam/uptime-kuma (note: Uptime Kuma does not batch those notifications, I got about 30 messages in Slack at the same time because a bunch of sites had the same wildcard certificate that was going to expire) Basically, it's nice to see that as a end user of software you can have a decent experience, for the most part. Definitely a bit better in some regards than what you might have been dealing with 10 years ago or so. Not that all of the problems or nitpicks are solved, or will be for the foreseeable future. Personal worries: what if Let's Encrypt becomes a non-viable option for whatever reason? There aren't that many ACME compatible providers out there.