Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unauthorized access too hook server (hook secret did not match) #121

Open
gohai opened this issue Apr 9, 2018 · 1 comment
Open

unauthorized access too hook server (hook secret did not match) #121

gohai opened this issue Apr 9, 2018 · 1 comment

Comments

@gohai
Copy link
Contributor

gohai commented Apr 9, 2018

I recently decided to restart nginx after some configuration changes, using sudo systemctl restart nginx. Afterwards I saw renewal requests failing like so

2018/04/09 20:50:45 [error] 12017#12017: *103 [lua] hook.lua:8: server(): auto-ssl: unauthorized access to hook server (hook secret did not match), client: 127.0.0.1, server: , request: "POST /deploy-challenge HTTP/1.1", host: "127.0.0.1:8999"

(...)
 + Requesting challenge for www.somedomain.com...
 err: curl: (22) The requested URL returned error: 401 Unauthorized

and earlier also

 + Requesting challenge for delabrave.com...
 err: curl: (7) Failed connect to 127.0.0.1:8999; Connection refused

So I am wondering if the previous hook server potentially did not exit when the main resty process did? This is an issue for us, since we're quickly in Error creating new authz :: too many currently pending authorizations territory when this happens.

Any workarounds?

@gohai
Copy link
Contributor Author

gohai commented Apr 13, 2018

Looking through the source code a bit I suspect that this hick-up might have something to do with the fact that our systemd unit configuration for nginx used the default PrivateTmp=true.

While I don't fully understand the code, it seems that the sockproc code uses /tmp/shell.sock and /tmp/auto-ssl-sockproc.pid, and also expects those to persists across restarts, so I could see how this could have caused an issue with systemd putting those file into a private (per-runtime) directory, and deleting it after a stop.

We changed our configuration to PrivateTmp=false and will monitor if this happens again. Feel free to close the bug in the mean time.

(Not sure if other paths than /tmp were considered for those files, but this could make sense if more people trap into this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant