| 26 Dec 2021 |
 aanderse | that happens on a timer so it's not a practical issue | 22:17:24 |
 m1cr0man | If your config is based on master/your own PR, you should be able to tell if renew has worked based on the age of the cert your caddy server is giving out right? | 22:20:36 |
| aanderse | that sounds right | 22:37:08 |
 hexa | I use rfc2316 with my own authoritative server and by default lego waits a minute between each SAN | 22:42:48 |
| hexa | if I reduce that time to ~10s it fails sometimes | 22:43:06 |
| hexa | which is worrying | 22:43:13 |
| hexa | like … why wouldn't 10 seconds work for a dynamic dns update 😕 | 22:43:22 |
 Winter (she/her) | In reply to @aanderse:nixos.dev
Winter: yes
i like my dns provider because they have an awesome feature set and are a good price
i do not like how it takes 30 minutes for my wildcard to renew 😑 what DNS provider if I may ask? | 22:55:50 |
| aanderse | namesilo | 23:03:50 |
 moritz.hedtke | In reply to @hexa:lossy.network
like … why wouldn't 10 seconds work for a dynamic dns update 😕 I could imagine because of the issues documented in https://letsencrypt.org/2020/02/19/multi-perspective-validation.html | 23:58:53 |
| moritz.hedtke | If I understood correctly what you mean | 23:59:04 |
| 27 Dec 2021 |
| moritz.hedtke | when I think about it the reasoning doesn't make sense in that case | 00:00:05 |
| moritz.hedtke | TTL? | 00:00:19 |
| hexa | moritz.hedtke: the record doesn't exist before the validation try | 00:02:41 |
| hexa | so negcache at worst | 00:02:57 |
| hexa | but letsencrypt probably won't do caching here | 00:03:04 |
| moritz.hedtke | And you think the record is there before e.g letsencrypt starts querying? I'm not too familiar with acme using dns | 00:05:55 |
| hexa | something like that | 00:53:31 |
| hexa | I haven't dug deeper | 00:53:34 |
| hexa | Merged! | 16:38:09 |
| m1cr0man | Thanks! | 16:59:15 |
| m1cr0man | haha so many emails from the 8 closed tickets | 16:59:24 |
| 29 Dec 2021 |
| Winter (she/her) | In https://github.com/NixOS/nixpkgs/blob/ac169ec6371f0d835542db654a65e0f2feb07838/nixos/modules/security/acme.nix#L417, it says that this makes it readable to the group specified by the cert service, but the perms for /var/lib/acme are 0750. Wouldn't the cert be inaccessible even by the group specified by the cert service, then? | 03:03:55 |
| Winter (she/her) | ah, I see https://github.com/NixOS/nixpkgs/blob/ac169ec6371f0d835542db654a65e0f2feb07838/nixos/modules/security/acme.nix#L294 now | 03:07:40 |
| Winter (she/her) | So because of the fix permission service having its working directory set to /var/lib/acme, I guess acme:acme would be the owner of /var/lib/acme. | 03:09:35 |
| Winter (she/her) | But then wouldn't the permissions of 0750 would still disallow access to the cert specified groups? | 03:10:19 |
| Winter (she/her) | * But then wouldn't the permissions of 0750 still disallow access to the cert specified groups? | 03:10:27 |
| Winter (she/her) | # These StateDirectory entries negate the need for tmpfiles
StateDirectory = [ "acme" "acme/.lego" "acme/.lego/accounts" ];
StateDirectoryMode = 755;
WorkingDirectory = "/var/lib/acme";
...ah.
| 03:16:37 |
| m1cr0man | yeah, we really went all-in on statedirectory/systemd activation logic for the folder creation. It ended up solving all previous permissions issues we were encountering, whilst also providing systemctl clean --what=state acme-mydomain.service for easy full renewals | 13:22:39 |
| m1cr0man | There's a bunch of really difficult to figure out logic wrt when directories need to be created, recreated or permissions changed which all depend on systemd service activation. Hence, it was best to leave it to systemd where possible | 13:30:20 |
