| 24 Nov 2021 |
 m1cr0man | oh look echo 1>&2 "certificate domain(s) have changed; will renew now" | 22:22:04 |
| m1cr0man | https://github.com/m1cr0man/nixpkgs/commit/34b5c5c1a408d105beb9b92b9ed5b1565135e75e "Allow for key reuse when domains are the only thing that changed!" Aha. | 22:23:01 |
 hexa | ah, we lost extraDomains /o\ | 22:23:34 |
| m1cr0man | ok so the question is, can I delete the cert files and not the key and will lego do a renew | 22:23:47 |
| hexa | I can give that a try | 22:24:22 |
| hexa | the certificate is likely the only place that has the info about the old san | 22:24:50 |
| hexa | do you need me to test something or can I just go ahead and purge this mess? | 22:38:14 |
| hexa | m1cr0man: ^ | 22:44:13 |
| m1cr0man | sorry - go ahead and purge | 22:53:27 |
| 25 Nov 2021 |
| m1cr0man | I think I simply overlooked testing removing a domain from existing domains. I'm going to add this to the test suite and then work on fixing it plus working on another ticket I saw (allowing setting more cert options at the sercurity.acme level) | 00:14:59 |
| m1cr0man | it's an easy enough thing to fix - but it's hard to fix without triggering mass renewals which is always a concern with ACME stuff | 00:15:29 |
| m1cr0man | https://github.com/NixOS/nixpkgs/issues/108237 also this one is interesting. The easy solution here is to add a message explaining that "If you are reading this after a nixos-rebuild - don't panic! This is just a certificate renewal failure and self-signed certs will be in place" (or something along those lines), but that would have to appear for all failures not just on rebuild. If anyone has suggestions feel free to shout them out. I'm off for now but will be working towards a PR by the weekend | 00:20:59 |
| 26 Nov 2021 |
| m1cr0man | If I'm doing some work to fix multiple issues, should I make a PR for each issue or do what I normally do and make one PR for all of them? I always make separate commits for each fix regardless. | 21:50:07 |
| hexa | the latter should be fine given they're separate commits | 22:01:35 |
| hexa | saves rebase headaches between pr's possibly | 22:01:45 |
| m1cr0man | yeah, cool. | 22:06:27 |
| m1cr0man | I also just found that It would be silly (and require a rebase) to fix one of these issues and not the other in one commit :P | 22:06:45 |
| m1cr0man | Btw turns out separating domain hash from the certsDir hash was a great idea - because now i can safely remove domainhash entirely and fix your issue. Btw, can you open a ticket for that, just so that we can track the change reasoning against it? | 22:07:27 |
| hexa | https://github.com/NixOS/nixpkgs/issues/147540 | 22:12:30 |
| hexa | here we go | 22:12:31 |
| m1cr0man | ty# | 22:12:39 |
| m1cr0man | * ty | 22:12:40 |
| m1cr0man | ugh no you know what, I'm at a crossroads here with domainhash:
- If I remove it, since extraDomains + domain aren't in the certDir hash, I would have to add them otherwise a change in domains wouldn't change the certs on disk
- If I add the domains to certDir I'll regenerate everyone's certificates, so I would have to use domainhash.txt to check if I should do a "lego run" instead.
In the past changing hashData has been met with some backlash, so I think I am stuck with option 2
| 22:18:20 |
| m1cr0man | Is this our problem actually? Maybe we should open a bug report upstream to lego | 22:24:23 |
| m1cr0man | https://github.com/go-acme/lego/issues/1532 lol | 22:26:56 |
| m1cr0man | 3 days ago | 22:26:58 |
| m1cr0man | that's some oddly close timing 😅 | 22:27:04 |
| m1cr0man | Ok fantastic, if upstream fixes that issue as I described in the comment, we can safely remove domainHash entirely :) | 22:32:07 |
| hexa | fun fact: I ported some portions of our acme logic to an ansible role we use at work with ubuntu | 22:49:50 |
| hexa | the hash part is crucial there as well | 22:49:56 |
