| 20 Feb 2025 |
 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 |
| emily | and has buy in from CT operators / Chrome / etc. | 14:55:15 |
| emily | shouldn't be an issue | 14:55:24 |
| emily | shorter lifetimes and better scalability are being coordinated across the entire ecosystem | 14:55:53 |
| emily | actually it was internal LE systems that were considered the bottleneck to shorter issuance times for a long while, so I think the most recent development is just them starting to work on scaling their own issuance up | 14:56:43 |
| m1cr0man | Are the channel blocker tests defined in nixpkgs or somewhere else? | 19:47:11 |
 K900 ⚡️ | In nixpkgs, yes | 19:48:05 |
| K900 ⚡️ | What are you looking for? | 19:48:30 |
| m1cr0man | I want to replace the ACME test with two of the new individual tests in this PR https://github.com/NixOS/nixpkgs/pull/355087 (the http01-builtin and dns test) | 19:48:53 |
