Avoid listening on port 443 during renewal

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

On AWS EC2 instance, I’m running a custom web server that’s listening on port 443.

I’m trying to renew certificates for subdomains of fbpinningtest.com.

With certbot 1.4.0, I ran this command

sudo certbot renew --preferred-challenges=http-01 --dry-run

It produced this output:

[...]
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for pass05.fbpinningtest.com
Error while running apachectl graceful.
httpd not running, trying to start

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs
[...]

I was hoping that certbot would start httpd listening only on port 80 to perform its verification. Right now, I have to stop my custom web server, run certbot which starts an httpd instance listening on port 443, then stop it again, and restart my server. That’s annoying. Is there a way to verify on port 80 without having httpd listen on 443 at any time?

I can login to a root shell on my machine.

1 Like

Modify your Apache configuration not to listen on port 443.

As far as I know, certbot doesn’t add any virtualhost listening on port 443, so I assume it must be a pre-existing Apache configuration file.

But a better question might be: why are you using the Apache authenticator and even the Apache installer when you’re running a custom webserver without having a running Apache at all? Why not just use the webroot authenticator? And I’m guessing the Apache installer isn’t useful for installing the certificate in your custom webserver, right?

1 Like

Hi @pillar

checking your domain via https://check-your-website.server-daten.de/?q=pass05.fbpinningtest.com - there is something on port 443.

Domainname Http-Status redirect Sec. G
http://pass05.fbpinningtest.com/ 3.12.105.63 -2 1.360 V
ConnectFailure - Unable to connect to the remote server
http://www.pass05.fbpinningtest.com/ 3.12.105.63 -2 1.363 V
ConnectFailure - Unable to connect to the remote server
https://pass05.fbpinningtest.com/ 3.12.105.63 204 4.154 B
Date: Mon, 06 Jul 2020 19:10:20 GMT
Connection: close

With a curious 204 - NoContent - answer.

And without any header information about the server.

So if you have an additional Apache, Certbot tries to start that instance if you use --apache.

But port 80 isn’t used, so use --standalone and open the firewall. Grade V and an answer < 2 seconds looks like a blocking firewall, not like a simple timeout (> 10 seconds).

2 Likes

The custom web server, a small golang program that simply responds with 204, only listens to 443. When it’s running, apache httpd is offline.

I’m pretty sure port 80 is open on the EC2 instance, I’ll check again. I’ll try with --standalone.

Thanks!

No, I manually copy/move and configure the certificates for my custom webserver.

I think when I first ran certbot, it used apache by default (I can’t remember for certain), so I kept using it, turning it off/on.

The /etc/httpd/conf/httpd.conf file doesn’t contain a 443 VirtualHost. However, there’s also a /etc/httpd/conf/httpd-le-ssl.conf file that does contain a <VirtualHost *:443> entry for each certificate that needs to be renewed.

Those were generated by certbots apache plugin when you used to use Apache as your webserver. This setup apparently isn’t compatible with your current setup. You should disable httpd-le-ssl.conf, but you’d also need to configure certbot not to use the apache installer plugin. There’s no easy way for that. Either generate the certificate again by using --cert-name <name of cert> (you can find the name of the cert by running certbot certificates) and for example the --standalone plugin as suggested earlier. Or manually modify the renewal configuration file for the certificate to change the installer setting to none and authenticator to standalone.

2 Likes

Yup, good to know. I did just that. Under /etc/letsencrypt/renewal, in each .conf file for each certificate, I changed those properties as you suggested and it now works properly.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/pass05.fbpinningtest.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer null
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for pass05.fbpinningtest.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of null server; fullchain is
/etc/letsencrypt/live/pass05.fbpinningtest.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 Like

Great it works!

But…:

I’m pretty sure that’s a bug in certbot :grin: Did you by accident type null in the renewal configuration file in stead of none? What version of certbot are you using?

1 Like

Yes, indeed I did write null instead of none :persevere:

2 Likes

With what version of certbot? Could be you’ve unconvered a bug.

1 Like

I’m using certbot 1.4.0. Did you expect it to fail somehow if null was provided?

1 Like

Yes. It acts like there actually exists something called the “null” plugin (like the apache or nginx plugin). But no such plugin obviously exists and you can’t “reload [the] null server” after a successful certificate issuance, like it showed in your log.

I’ll try to reproduce this with the most recent version and if I can reproduce, file a bug report.

Edit:
I can reproduce this bug with the most recent git version of certbot :slight_smile: Will file a bug.

Oh snap. While searching if this bug was already filed, it seems to be intentional :crazy_face: :

I’m not sure if the reason it still exists is still valid, but hey, at least it’s not a bug :stuck_out_tongue:

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.