 | NixOS ACME / LetsEncrypt | 105 Members |
| Another day, another cert renewal | 45 Servers |
| NixOS ACME / LetsEncrypt | 105 Members |
| Another day, another cert renewal | 45 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Jul 2025 | ||
 emily | most of it is still good, it's just OCSP stapling went away and ARI changed the renewal timing landscape a bit and so on | 11:09:40 |
 Christian Theune | yup | 12:12:06 |
| Christian Theune | as an outsider that just makes it hard to estimate which parts. i did understand it that way: ocsp and ari having changed. | 12:12:30 |
| emily | well, it's only really relevant for client developers, or comparing existing implementations but then you basically have to read code to see what they get right in some cases | 12:28:14 |
| emily | the fundamental issue with lego is that things like ARI don't fit great into a cron job type format if you want the best implementation of them | 12:29:00 |
| emily | and all the hashing etc. we have to do around it is just working around the model not being quite right | 12:29:20 |
| emily | (the end result does work well though at least at medium scale, it just takes a whole bunch of complexity to make the square peg fit the round hole) | 12:29:44 |
| Christian Theune | yup | 12:34:38 |
| Christian Theune | do you know what the list of supported DNS-01 provider APIs looks like in acmez compared to lego? | 12:35:05 |
| Christian Theune | so far that's been the reason why I decided to stick with lego for now. | 12:35:14 |
| Christian Theune | I got a green bar on the refactoring I demoed above. Trying to get the other tests clean again now. On disk formats are all compatible ... \o/ | 12:35:38 |
| Christian Theune | I need to explicitly praise the test coverage in the acme module. This helps a lot to find little glitches that I didn't properly catch. | 13:21:03 |
| Christian Theune | 🎉 | 13:21:06 |
| Christian Theune | so ... anyway ... i'll have to clean this up a bit more. i'll also need to rework the locking (with systemd 258 we could leverage the slice parallel unit limits, but i'll do a small change to get rid of the static hashing from build time to put it into a runtime solution as an intermediate step) | 13:45:05 |
| Christian Theune | off from the sprint for now ... | 13:45:09 |
| emily | everything libdns supports | 14:31:00 |
| emily | it's pretty extensive | 14:31:05 |
| emily | https://github.com/orgs/libdns/repositories?type=all | 14:31:20 |
| Christian Theune | ah, that sounds interesting. ok. i'll still try to wrap up my stuff over the next days and maybe take a fresh look after. i think it was definitely worthwhile to understand what the current system does ... | 15:01:23 |
| 6 Jul 2025 | ||
 m1cr0man | The test suite really is the most valuable bit of the acme module at this point. If you can get everything to pass, then you can be reasonably confident there are no major regressions. | 13:12:27 |
| m1cr0man | I can't remember any concrete reason right now as to why it was introduced. Removing it may be difficult, as people definitely are using it. I understand you are reworking this for your own use case which sounds quite complex and large-scale, but keep in mind that most people use the ACME module for the simplest of cases - they have a vhost, they set I definitely think there is a solution here where we can keep the self signed cert optionality and what you are trying to do. Your primary concern seems to be around the lack of a syntactically valid cert being present for consumer services. If this option is explicitly set to false, then it can be assumed that users do not care about this guarantee. | 13:19:06 |
| emily | the one talking about OCSP stapling is at least obsolete :) | 13:32:26 |
| 7 Jul 2025 | ||
| Christian Theune | m1cr0man: yeah, not breaking things by introducing my own use case is absolutely on my list. thanks for the github search ... going through the list, the use case is basically DNS-01 where you can get certificates up early. I'll ponder the optionality. Also, I can try to get in touch with the users ... so thanks again for that list. | 05:09:40 |
| 8 Jul 2025 | ||
| Christian Theune | One aspect about not using self-signed certificates is that dependencies become really tricky without. You could end up with services that both rely on and don't rely on self-signed certificates and then ordering needs to be to run acme orders for non-self-signed first, then start the services that depend on self-signed certificates (once all non-self-signed are there) or you end up with invalid intermediate runtime states ... 🙈 | 11:34:26 |
 Zhaofeng Li | It's okay to start them services as long as they can reload certificates automatically (or get restarted), right? There is also the need to make sure they don't get traffic until it's actually healthy | 20:16:03 |
| Zhaofeng Li | * It's okay to start the services as long as they can reload certificates automatically (or get restarted), right? There is also the need to make sure they don't get traffic until they're actually healthy | 20:16:43 |
| 9 Jul 2025 | ||
| Christian Theune | Well, that's the core of the issue about self-signed certificates: the services are always configured with the names of the (final) certificate names. If you have a mixture of validations using HTTP-01 then those vhosts will need self-signed certificates. If you have another set of vhosts that use DNS-01 then those don't need self signed certificates. However, if the DNS-01 ones are then configured without self-signed certificates, then the server can't start at all unless the DNS-01 has been successfully validated. That also means that any errors in the DNS-01 verifications will completely block starting the server unless that is fixed. | 07:12:47 |
| Christian Theune | From my experience, this kind of dependencies quickly leads to an operational nightmare when something goes unexpectedly wrong. Designing for a "everything is sunny in california" environment doesn't resonate very well with me. Especially because the complexity is getting so high that making predictions about reliability and not forgetting some corner case is becoming impossible. | 07:14:07 |
| Christian Theune | IMHO the overall design would be much better off if we ripped out the "no self signed certificates" knob ... | 07:14:41 |
| Christian Theune | This will let us have a single straight path in the dependencies to ensure servers come up somehow and then let users deal with partial degradations instead of complete failure that then becomes impossible to fix because of opposing dependencies. | 07:15:46 |