Certbot renew failing - (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80

My domain is: www.avenue-x.com

The operating system my web server runs on is (include version): CentOS release 6.5 (Final) x64

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.32.0

I ran this command: ./certbot-auto renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/avenue-x.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for avenue-x.com
http-01 challenge for www.avenue-x.com
Error while running apachectl graceful.
httpd not running, trying to start

(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

Unable to restart apache using [‘apachectl’, ‘graceful’]
Error while running apachectl restart.
httpd not running, trying to start

+++++

This is the first time the cerbot-auto renew has failed. Previous 3 times it was successful. In cursory investigating I looked at my current httpd.conf file and one from before the last successful renew. I then remembered I recently updated httpd.conf to disable IPV6 checking. Changing Listen 80 to Listen 0.0.0.0:80. Could that be the issue?

I also checked what could be using port 80 maybe thinking it wasn’t a cerbot issue but an httpd one:

ps ax | grep httpd
2108 pts/2 S+ 0:00 grep httpd
7695 ? S 0:07 /usr/sbin/httpd
16270 ? R 0:05 /usr/sbin/httpd
16668 ? S 0:04 /usr/sbin/httpd
17581 ? S 0:04 /usr/sbin/httpd
18127 ? S 0:04 /usr/sbin/httpd
18745 ? S 0:04 /usr/sbin/httpd
18852 ? S 0:04 /usr/sbin/httpd
19191 ? S 0:04 /usr/sbin/httpd
28565 ? S 0:01 /usr/sbin/httpd
28573 ? S 0:01 /usr/sbin/httpd
28577 ? S 0:01 /usr/sbin/httpd
28578 ? S 0:01 /usr/sbin/httpd
28579 ? S 0:01 /usr/sbin/httpd
28580 ? S 0:01 /usr/sbin/httpd
28583 ? S 0:01 /usr/sbin/httpd
28584 ? S 0:01 /usr/sbin/httpd
28585 ? S 0:01 /usr/sbin/httpd
28586 ? S 0:01 /usr/sbin/httpd
28587 ? S 0:01 /usr/sbin/httpd
28589 ? S 0:01 /usr/sbin/httpd

Last bit of info…I checked the letsencrypt log from the previous successful renew against the current failed renew, to see where they differ:

Log from last GOOD run:
2018-12-23 23:20:48,076:DEBUG:certbot_apache.http_01:writing a post config file with text:
<Directory /var/lib/letsencrypt/http_challenges>
Order Allow,Deny
Allow from all

<Location /.well-known/acme-challenge>
Order Allow,Deny
Allow from all

2018-12-23 23:20:48,177:DEBUG:certbot.reverter:Creating backup of /etc/httpd/conf/httpd.conf
2018-12-23 23:20:51,360:INFO:certbot.auth_handler:Waiting for verification…
2018-12-23 23:20:51,361:DEBUG:acme.client:JWS payload:
etc…etc…etc

Log from current BAD run:
2019-03-20 00:43:23,347:DEBUG:certbot_apache.http_01:writing a post config file with text:
<Directory /var/lib/letsencrypt/http_challenges>
Order Allow,Deny
Allow from all

<Location /.well-known/acme-challenge>
Order Allow,Deny
Allow from all

2019-03-20 00:43:23,501:DEBUG:certbot.reverter:Creating backup of /etc/httpd/conf/httpd.conf
2019-03-20 00:43:23,501:DEBUG:certbot.reverter:Creating backup of /etc/httpd/conf/httpd-le-ssl.conf
2019-03-20 00:43:23,723:ERROR:certbot.util:Error while running apachectl graceful.
httpd not running, trying to start

(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

Any help would be greatly appreciated!

Hi @debaron

looks like you have used tls-sni-01 validation. That's deprecated, support is stopped.

Your domain is invisible ( https://check-your-website.server-daten.de/?q=avenue-x.com ):

Domainname Http-Status redirect Sec. G
http://avenue-x.com/
192.99.101.111 -2 1.326 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:80
http://www.avenue-x.com/
192.99.101.111 -2 1.323 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:80
https://avenue-x.com/
192.99.101.111 -2 1.317 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:443
https://www.avenue-x.com/
192.99.101.111 -2 1.316 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:443
http://avenue-x.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
192.99.101.111 -2 1.313 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:80
Visible Content:
http://www.avenue-x.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
192.99.101.111 -2 1.314 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 192.99.101.111:80
Visible Content:

Is there a blocking firewall or something else?

If you use http-01 validation, an open port 80 is required.

So it's impossible to see what runs on port 80.

thank you Juergen for your reply. Unfortunately I have no idea why my domain name is invisible as I haven't changed anything server wise (except for the changing listen 80 to listen 0.0.0.0:80 in httpd.conf). I'll talk to my server host.

Regarding the tls-sni-01 validation being deprecated, should I uninstall certbot and reinstall new?

That may be the problem. "Listen" doesn't use an ip address, use

Listen 80

No, you have a new Certbot, that's ok.

thanks. The problem is I was running into mail issues (I believe gmail) where it was rejecting e-mails due to checking for iPV6 or something, and coding listen 0.0.0.0:80 was stated as the way to look for iPV4 only and that solved that issue. I’ll keep searching.

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