!MthpOIxqJhTgrMNxDS:nixos.org

NixOS ACME / LetsEncrypt

92 Members
Another day, another cert renewal43 Servers

Load older messages


SenderMessageTime
9 Sep 2023
@m1cr0man:m1cr0man.comm1cr0manCool ok17:45:42
@os:matrix.flyingcircus.ioosnyx (he/him)Thanks a lot17:54:08
21 Sep 2023
@dedmunwalk:matrix.orgdedmunwalk joined the room.23:08:48
22 Sep 2023
@k900:0upti.meK900 changed their profile picture.09:53:38
25 Sep 2023
@os:matrix.flyingcircus.ioosnyx (he/him) m1cr0man: Hey, you probably want to close your alternative PR https://github.com/NixOS/nixpkgs/pull/246665 21:38:44
@m1cr0man:m1cr0man.comm1cr0manty for the reminder21:52:45
2 Oct 2023
@atra1n:matrix.orgTrain joined the room.01:42:45
@os:matrix.flyingcircus.ioosnyx (he/him)Hey, I might have run into a general issue with acme and nginx again, but wonder whether I am holding it wrong because nobody else has complained about it so far: Initial acme certificate generations fail for newly added vhosts when nginx has already been running12:33:31
@raitobezarius:matrix.orgraitobezariusI don't think I encountered this issue personally12:40:47
@raitobezarius:matrix.orgraitobezariusHow is it failing?12:40:59
@os:matrix.flyingcircus.ioosnyx (he/him) Background:
When changing the config file by e.g. adding new vhosts at switch time, nginx is not immediately reloaded and being made aware of the config changes. One of the reasons is that new vhosts might rely on certificate files yet to be generated by the acme subsystem. Reloading is thus triggered by nginx-reload-config.service.
Its dependencies are configured as such that it runs before the respective acme-domain-finished.target, but after the acme-domain.service renew service. That service though communicates with an acme registry and makes the registry fetch the validation response from nginx. With the config not being reloaded yet, nginx does not know the respective vhost and cannot serve a valid response.
12:45:48
@os:matrix.flyingcircus.ioosnyx (he/him) acme: error: 403 :: urn:ietf:params:acme:error:unauthorized 12:46:49
@os:matrix.flyingcircus.ioosnyx (he/him) Failed to fetch certificates. This may mean your DNS records are set up incorrectly. Selfsigned certs are in place and dependant services will still start. 12:47:15
@os:matrix.flyingcircus.ioosnyx (he/him) As nginx is reloaded even after failing scme service runs, the next retry of the service succeeds and after a few minutes, the certs are successfully validated. But the initial switch-to-configuration exits with a failure code. This is not very useful if you call taht switch as a part of a deployment script. 12:48:56
@os:matrix.flyingcircus.ioosnyx (he/him)

I mainly want to know whether

  1. folks here are aware of such issues
  2. this was a concious decision to live with a failing switch that repairs itself after a few minutes
  3. I am holding it wrong.
12:50:03
@os:matrix.flyingcircus.ioosnyx (he/him)The reload situation right now is <nginx.conf updated> -> <acme-selfsigned service run> -> <acme-renew run> -> <nginx-reload-config.service> -> <acme-finished target>12:52:15
@os:matrix.flyingcircus.ioosnyx (he/him)The easiest thing would be (as long as self-signed placeholder certs are used) if it was <nginx.conf updated> -> <acme-selfsigned service run> -> <nginx-reload-config.service> -> <acme-renew run> -> <nginx-reload-config.service> -> <acme-finished target>12:53:04
@os:matrix.flyingcircus.ioosnyx (he/him)Unfortunately, the same service cannot be run mutliple times within the dependency chain of a service (AFAIK). So I am thinking about duplicating the nginx reload service under 2 names to run it before and after an acme renewal. But maybe there's a better option or I am just holding thing the wrong end here.12:54:38
@os:matrix.flyingcircus.ioosnyx (he/him) * As nginx is reloaded even after failing acme service runs, the next retry of the service succeeds and after a few minutes, the certs are successfully validated. But the initial switch-to-configuration exits with a failure code. This is not very useful if you call taht switch as a part of a deployment script. 13:02:42
@os:matrix.flyingcircus.ioosnyx (he/him) * Unfortunately, the same service cannot be run mutliple times within the dependency chain of a service (AFAIK). So I am thinking about duplicating the nginx reload service under 2 names to run it before and after an acme renewal. But maybe there's a better option or I am just holding things the wrong end here.13:15:34
3 Oct 2023
@pederbs:pvv.ntnu.no@pederbs:pvv.ntnu.no changed their profile picture.21:04:38
4 Oct 2023
@pederbs:pvv.ntnu.no@pederbs:pvv.ntnu.no changed their profile picture.22:20:32
5 Oct 2023
@hexa:lossy.networkhexahttps://gist.github.com/mweinelt/3993fdc7be3caf81bcff1bc506f4492212:04:19
@hexa:lossy.networkhexa m1cr0man: 🙂 12:04:22
@m1cr0man:m1cr0man.comm1cr0mantenor_gif9132551967232721932.gif
Download tenor_gif9132551967232721932.gif
13:59:42
@m1cr0man:m1cr0man.comm1cr0man osnyx (he/him): I'm just seeing your message now. I personally use Apache and definitely have added new domains to running hosts. What I imagine has gone wrong here is that the Acme module assumes some mechanism will reload nginx when its own config changes irrespective of nginx-config-reload (aka switch-to-configuration will do it). That way the self signed certs get used initially then once renewal succeeds nginx-config-reload will reload it a second time, and http-01 validation succeeds. Really we just need to look at the order of operations during a rebuild and work from there. I would expect there to be a reload of nginx during the switch, after self signed, and before the renewal service 14:09:50
@m1cr0man:m1cr0man.comm1cr0manConfusing English gonna edit that 😅14:10:47
@m1cr0man:m1cr0man.comm1cr0man* osnyx (he/him): I'm just seeing your message now. I personally use Apache and definitely have added new domains to running hosts. What I imagine has gone wrong here is that the Acme module assumes some mechanism will reload nginx when its own config changes irrespective of nginx-config-reload (aka switch-to-configuration will do it). That way the self signed certs get used initially, http-01 validation happens, then once renewal succeeds nginx-config-reload will reload it a second time. Really we just need to look at the order of operations during a rebuild and work from there. I would expect there to be a reload of nginx during the switch, after self signed, and before the renewal service14:11:17
@os:matrix.flyingcircus.ioosnyx (he/him)

is that the Acme module assumes some mechanism will reload nginx when its own config changes irrespective of nginx-config-reload

But that cannot happen because the yet-to-be-generated certificate files are already referenced by the new config after switch, irrespectively whether the self-signed services have already run.

14:12:14
@os:matrix.flyingcircus.ioosnyx (he/him)I read (haven't tried myself) that nginx crashes when the config references nonexisting cert files. This is probably one of the main reasons for the existence of nginx-config-reload, as it has a condition gurad that checks for the existence of cert files.14:13:27

Show newer messages


Back to Room ListRoom Version: 6