Please fill out the fields below so we can help you better.
I ran this command: certbot --nginx
My web server is (include version): nginx/1.12.1
The operating system my web server runs on is (include version): Ubuntu 16.04
I’m curious if I for whatever reason messed with “listen 443 ssl; # managed by Certbot” and changed 443 to a different port in nginx conf file, leaving everything the same, can certbot renew certificate? Will certbot change it back to 443 after certificate renewal?
The certificate authority requires the verification of your ownership of the domain to happen on port 443 [or port 80], but that doesn’t mean that you’re required to use the certificate on port 443 the rest of the time. 
I believe that if you change it to another port, the renewal should still work. Certbot should temporarily reconfigure it to also listen on port 443 during the renewal process, and port 443 will have to be available for nginx to bind during that process.
This is a slightly unusual configuration, so it’s possible that you’ll unearth a bug of some sort as a result of doing this. If you do, please let us know about it so we can help fix it!
In this case, other software is listening on port 443. Nginx is listening on port 80 for http and port 4430 for ssl/tls. Certainly nginx cannot use port 443 during the process, but it can access port 80. I run a silmulation renewal:
certbot renew --dry-run
It turned to be working. So am I right you can renew with only port 80 available to nginx?
That would work for certificates that were obtained with --webroot, but not with --nginx (the two use different challenge methods).
Well，I used --nginx. I forget to mention, the software listening on 443 redirect packages to port 4430. Does this allow challenge to work?
If you also told it that that was the port to use to satisfy challenges, then it should. Otherwise, I’m puzzled about why it works!
Does certbot change nginx.conf to listen on 443 and restart nginx to complete the challenge when renew? If so nginx wouldn’t restart because it could not bind to 443. I understand that using --nginx to obtain the certificate involves binding nginx to 443, but is it the same for renewal? It is true that when I obtained the certificate nginx was listening on 443, after which I changed it to listen on 4430. Also, note that 4430 is set to deny in ufw, so the data use to complete the challenge must have received via either port 443 or port 80. If it is not necessary for nginx to bind to port 443 to complete the challenge, then that the software redirecting traffic from 443 to 4430 could explain how it works.
Yes.
But it could have been changed if you specified --tls-sni-01-port 4430, which would then have been remembered for renewal purposes as well.
Thanks! But I still could not understand how nginx could bind to 443 if a program is already using it. Anyway, I will change the tls-sni-01-port.
Bingo! I found why it works. See this:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
tcp 0 0 0.0.0.0:4430 0.0.0.0:* LISTEN 1419/nginx -g daemo
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1419/nginx -g daemo
tcp6 0 0 :::443 :::* LISTEN 1524/python3.5
...
tcp6 0 0 :::80 :::* LISTEN 1419/nginx -g daemo
...
udp6 0 0 :::443 :::* 1524/python3.5
This is quite interesting. Thanks for helping me.
One subtlety is that I think if Apache or nginx is listening on various ports, some of their internal request routing logic may sometimes allow a virtual host that was originally designed to listen on one port answer requests that arrive on another port. However, I haven’t investigated whether this is true if the declarations appear in different virtual host stanzas.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.