4 ms·

Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls u

Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)?

ffsm8 1y ago
Yes, we had lengthy discussions in itops (I had a admin role when LE was launched) about it. The team lead couldn't get over the slogan "devops, automating downtimes since 2010" whenever someone wanted to add a new nonessential automation that does things on prod servers. I mean he wasn't completely wrong, it was a non essential automation with high risk and very little reward (<1h saved every 2 yrs), which is why we never switched to LE for our main site, only internal tooling was allowed to use it
- cpach 1y ago
  Perhaps you know this already but in the future, certs issued by a “real” CA will not be allowed to live for more than 47 days. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
  - ffsm8 1y ago
    I didn't know that, interesting. I was merely retelling an anecdote about how LE was always positioned to be exclusively about refreshing certs automatically, though. As I've moved out of (dev-)ops roles around 2016/2017 so I'm really not up to date with operations topics
throw0101d 1y ago
> Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)? And? Automation sometimes breaks, both for internal reasons (OS patching) or external. For the latter, LE at some point in the past changed CDNs, and this caused JWST headers to be sent back differently, which broke different clients, e.g.: * https://community.letsencrypt.org/t/jws-has-no-anti-replay-nonce/103324 https://community.letsencrypt.org/t/jws-has-no-anti-replay-n... * https://github.com/dehydrated-io/dehydrated/issues/684 https://github.com/dehydrated-io/dehydrated/issues/684 Being able to get e-mails was an extra level of monitoring that was handy, even if you had automation.
- Jedd 1y ago
  > And? And you set up your own monitoring systems for your own infrastructure, as you have always done. Or better yet, set up auto-renewal as per vendors recommendation. Vendors - especially vendors you aren't paying - may provide some reminder services, but assuming those to be your sole method for 'managing' your renewals is a deeply poor operational position. This is going to get really important as cert longevity gets reduced, eg https://news.ycombinator.com/item?id=43693900 https://news.ycombinator.com/item?id=43693900 If you're using Prometheus or Prom-friendly systems - https://github.com/ribbybibby/ssl_exporter https://github.com/ribbybibby/ssl_exporter

Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)?

ffsm8 1y ago

Yes, we had lengthy discussions in itops (I had a admin role when LE was launched) about it. The team lead couldn't get over the slogan "devops, automating downtimes since 2010" whenever someone wanted to add a new nonessential automation that does things on prod servers. I mean he wasn't completely wrong, it was a non essential automation with high risk and very little reward (<1h saved every 2 yrs), which is why we never switched to LE for our main site, only internal tooling was allowed to use it

cpach 1y ago
Perhaps you know this already but in the future, certs issued by a “real” CA will not be allowed to live for more than 47 days. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
- ffsm8 1y ago
  I didn't know that, interesting. I was merely retelling an anecdote about how LE was always positioned to be exclusively about refreshing certs automatically, though. As I've moved out of (dev-)ops roles around 2016/2017 so I'm really not up to date with operations topics

throw0101d 1y ago

> Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)? And? Automation sometimes breaks, both for internal reasons (OS patching) or external. For the latter, LE at some point in the past changed CDNs, and this caused JWST headers to be sent back differently, which broke different clients, e.g.: * https://community.letsencrypt.org/t/jws-has-no-anti-replay-nonce/103324 https://community.letsencrypt.org/t/jws-has-no-anti-replay-n... * https://github.com/dehydrated-io/dehydrated/issues/684 https://github.com/dehydrated-io/dehydrated/issues/684 Being able to get e-mails was an extra level of monitoring that was handy, even if you had automation.

Jedd 1y ago
> And? And you set up your own monitoring systems for your own infrastructure, as you have always done. Or better yet, set up auto-renewal as per vendors recommendation. Vendors - especially vendors you aren't paying - may provide some reminder services, but assuming those to be your sole method for 'managing' your renewals is a deeply poor operational position. This is going to get really important as cert longevity gets reduced, eg https://news.ycombinator.com/item?id=43693900 https://news.ycombinator.com/item?id=43693900 If you're using Prometheus or Prom-friendly systems - https://github.com/ribbybibby/ssl_exporter https://github.com/ribbybibby/ssl_exporter