I need to obtain a certificate for a domain where ports 80 and 443 are occupied by a non-web service.
To work around this, my pre-hook stops the conflicting service, updates the Nginx configuration to include the domain, and reloads Nginx. A post-hook then reverts these changes.
This setup works fine when I manually run the pre-hook before renewal. However, when Certbot executes the pre-hook automatically, it seems to ignore the updated Nginx configuration. I even verified that the new config is saved (cat confirms it), but it looks like Certbot reads the configuration before the pre-hook executes.
Is there a way to ensure my script runs before Certbot reads the configuration during automatic renewal?
Let's assume that is true. I mean, maybe something else is happening but I am going to suggest alternate simpler methods. I assume you are using something like sudo certbot certonly --nginx. Yes? Because only the --nginx method requires Certbot to parse the nginx config.
One option is to use the Certbot --standalone option instead. Then, you don't involve nginx at all. You still need your pre/post hook but only to stop/start the "offending" service. If that service supports reverse proxy you could send the port 80 challenge request to the --standalone listener on an alternate port. (note if it does support that it could proxy back to nginx too on an alternate port)
Or, continue with nginx like you are but use certbot certonly --webroot -w (path) instead of the --nginx plugin. Your hooks do what they do today but Certbot has no need to read your nginx config. Certbot places a token file in the -w folder which should match the root in the server block you created to handle the challenge request.
A third option is to use a DNS Challenge and avoid all this. Although, DNS Challenges can be more difficult to automate.
Note: The command to start/reload nginx is likely asynchronous. So, make sure it is up and ready to handle the challenge by the time Certbot starts its processing and the incoming challenge arrives (that's probably at least a few seconds so probably enough but ...). Which is one advantage of the --standalone option.
