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


#1

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!


#2

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.


#3

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?


#4

That may be the problem. “Listen” doesn’t use an ip address, use

Listen 80

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


#5

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.


closed #6

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