151–160 of 290 posts
Why 6 day and not 8? - 8 is a lucky number and a power of 2 - 8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout - 6 is the value of every digit in the number of the beast - I just don't like 6!
Worry not, cause it's not 6 days (144 hours), it is 6-ish days: 160 hours And 160 is the sum of the first 11 primes, as well as the sum of the cubes of the first three primes!
Earlier quoted context omitted.
One can also use a private CA for that scenario.
Exactly -- how many 192.168.0.1 certs do you think LetsEncrypt wants to issue?
Earlier quoted context omitted.
Because it allows to you to work for six days, and rest on the seventh. Like God did.
² By the seventh day God had finished the work He had been doing; so on the seventh day He rested from all His work. ³ Then the on-call tech, Lucifer, the Son of Dawn, was awoken at midnight because God did not renew the heavens' and the earths' HTTPS certificate. ⁴ Thusly Lucifer drafted his resignation in a great fury.
It's a huge ask, but i'm hoping they'll implement code-signing certs some day, even if they charge for it. It would be nice if appstores then accepted those certs instead of directly requiring developer verification.
I have now implemented a 2 week renewal interval to test the change to the 45 days, and now they come with a 6-day certificate? This is no criticism, I like what they do, but how am I supposed to do renewals? If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window. I'm certain there are some who need this,…
I think a pattern like that is reasonable for a 6-day cert:
- renew every 2 days, and have a "4 day debugging window" - renew every 1 day, and have a "5 day debugging window"
Monitoring options: https://letsencrypt.org/docs/monitoring-options/
This makes me wonder if the scripts I published at https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... should have the expiry thresholds defined in units of hours, instead of integer days?
Earlier quoted context omitted.
² By the seventh day God had finished the work He had been doing; so on the seventh day He rested from all His work. ³ Then the on-call tech, Lucifer, the Son of Dawn, was awoken at midnight because God did not renew the heavens' and the earths' HTTPS certificate. ⁴ Thusly Lucifer drafted his resignation in a great fury.
Is this the TLS version of the Bible?
IP addresses must be accessible from the internet, so still no way to support TLS for LAN devices without manual setup or angering security researchers.
I recently migrated to a wildcard (*.home.example.com) certificate for all my home network. Works okay for many parts. However requires a public DNS server where TXT records can be set via API (lego supports a few DNS providers out of the box, see https://go-acme.github.io/lego/dns/ )
Earlier quoted context omitted.
> 8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout There’s your answer. 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week. 8 days would result in things getting hammered on specific days of the week.
> 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week. people will put */5 in cron and result will be same, because that's obvious, easy and nice number.
Currently ACME sets its cron job to 12 days on 90 day certificates.
This is interesting, I am guessing the use case for ip address certs is so your ephemeral services can do TLS communication, but now you don't need to depend on provisioning a record on the name server as well for something that you might be start hundreds or thousands of, that will only last for like an hour or day.
The July announcement for IP address certs listed a handful of potential use cases: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...