| 26 Dec 2021 |
 Winter (she/her) | is that on the server side? | 21:59:42 |
 m1cr0man | In reply to @aanderse:nixos.dev
hmmm ok
my cert takes 30 minutes to renew (no, I'm not being sarcastic at all ... between 20 and 30 minutes) so i actually haven't tested that it worked - i cannot properly You can nix-build the test suite now if you need a quick testing solution. Just comment out all the other subtests ;) | 22:14:59 |
 aanderse | 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 😑 | 22:16:24 |
| aanderse | but since it's a wildcard i only need to do the one cert | 22:16:52 |
| 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 |
