I opened certbot container like: docker exec -it certbot sh, then i tried to run his command and i got the output: The requested nginx plugin does not appear to be installed.
That is a very strange response form certbot 2.0.0.
You can try upgrading it.
You can also try using --webroot authentication.
2 Likes
I agree that they error about plug-in is odd. But, what is the value of --http-01-port 8080 when using the --nginx plug-in as authenticator?
Certbot does not control the port that nginx listens on. Or, does that option cause Certbot to modify the nginx config with a listen for that port? I thought that option was only for --standalone.
3 Likes
hmm...
Well, it's not --webroot, so it is using the nginx config [for something].
And since it has to look for the correct server block within the nginx config it might miss it when looking only for "servername=FQDN & port=80".
So...
Although it doesn't change the nginx config [certonly], it needs to know where to put the challenge file. Which can only be found by finding the correct server block.
Soooo...
The "value" is: Indispensible!
3 Likes
Ah, thanks. In this case the nginx config was already using a listen 8080; so the nginx plug-in needs to know that is the server block to update with its temp challenge info.
Got it.
The docs for that option are not as clear as your description 
This does not change your explanation but a minor note is that the plug-in does not actually place a challenge file. It uses nginx config to provide the http challenge response. An example:
server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/html;
location = /.well-known/acme-challenge/MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg {default_type text/plain;return 200 MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg.AwQwgwgwzwgwJwgw4wew3wrwxwiw-wpwvwqwxwBwswT;} # managed by Certbot
}
2 Likes
Interesting find and hack.
But is seems to confuse me within the first line.
Which seems to affect all request on all names.
But then specifies which names and port to affect.
But how does that not conflict with any existing FQDN:80 block?
And how/why is certonly modifying/restarting/unmodifying/restarting nginx ??
2 Likes
It is just an example of how the certbot nginx plug-in makes temp changes to an http server block. It adds the rewrite at the top and the location at the bottom. It does not create an entirely new server block. It just adds these 2 lines and removes them after the challenge is complete.
It is not particular to this docker thread that uses an alternate port. It is just to demonstrate the plug-in doesn't make a file and instead relies on the location statement's return clause to provide the http response.
You can see the exact code for a specific instance in the letsencrypt.log
3 Likes
In any case, it is unexpected to me.
I mean that I would NOT have expected any change when using certonly.
Who needs to look under the hood - I just like driving FAST ! - LOL
3 Likes
Yeah, the nginx plug-in authenticator always uses the same technique. That is, make temp changes to the nginx config (and reload before and after). This honors the certonly in that no permanent changes are made to the config.
Of course, using certonly webroot places a file and avoids needing to reload nginx for the challenge. And, no changes to the nginx config - temp or permanent.
I totally agree it is unexpected. It is sometimes handy when things go wrong with webroot to try the -a nginx because it is a different technique. Clever, a bit obscure, and certainly not intuitive The exact code it uses in each case is shown in the letsencrypt.log
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.