| 19 Feb 2025 |
 emily | I think systemd keeps track of services that are "starting" but not started | 17:02:19 |
| emily | so it may not try to run lego again if it's blocking from before | 17:02:27 |
 hexa |
Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running.
https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
| 17:05:02 |
| emily | but oneshots aren't "active" until they finish, right? | 17:11:56 |
| emily | or maybe they're "active" but not "running"? | 17:12:05 |
| hexa | they should be in activating while running iirc | 17:19:01 |
| 20 Feb 2025 |
| hexa | ok, merged lego 4.22.2 | 18:05:34 |
| hexa | so now we have ari enabled with wait time 0 | 18:05:41 |
| hexa | so at least we'd get immediate cert renewal if within a requested renewal window even if the cert was valid for longer than 30 days | 18:06:20 |
| hexa | --ari-disable Do not use the renewalInfo endpoint (draft-ietf-acme-ari) to check if a certificate should be renewed. (default: false)
| 18:07:53 |
 ThinkChaos | Did they remove --ari-enable or do they have both now? 😄 | 18:08:48 |
| emily | is 0 "no wait" or "indefinite"? | 20:31:12 |
| hexa | no wait aiui | 20:55:07 |
| hexa | yes, ari is default on now and you can disable it | 20:55:20 |
| 21 Feb 2025 |
| emily |
You’ll also want to be sure your ACME client is running frequently - both for the sake of renewing short-lived certificates and so as to take advantage of ACME Renewal Information (ARI). ARI allows Let’s Encrypt to notify your client if it should renew early for some reason. ARI checks should happen at least once per day, and short-lived certificates should be renewed every two to three days, so we recommend having your client run at least once per day.
| 16:04:44 |
| emily | wonder if we should consider moving to 2×/day | 16:04:52 |
| emily | (https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/) | 16:04:57 |
| 22 Feb 2025 |
 m1cr0man | I mean we only ever had it > 1 day for LE's sake (DDOS) 😅 I don't see why we couldn't do 2x/day.
Sorry just catching up on this all now. Was on holidays. | 00:26:31 |
| hexa | ideally we could configure the intervals relative to the total certificate lifetime | 14:50:52 |
| hexa | * ideally we could configure the intervals relative to the total certificate lifetime provided by the profile | 14:51:01 |
| hexa | but in the end it probably doesn't matter too much | 14:51:41 |
| hexa | I still worry a bit about shortlived certs and CT logs | 14:52:13 |
| hexa | https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/_335unOyteQ | 14:52:38 |
 Arian | As in. CT log performance? | 14:52:44 |
| hexa | * I still worry a bit about shortlived certs and the impact on CT logs | 14:52:46 |
| hexa | yeah, they are these very big and slow platforms already | 14:52:54 |
| hexa | and now we effectively allow people to recreate their certificates 15 times as much | 14:53:19 |
| hexa | * and now we effectively allow people to recreate their certificates 15 times as often | 14:53:22 |
| emily | the sunlight effort is making ct scale much better | 14:54:48 |
| emily | https://sunlight.dev/ | 14:55:04 |
