letsencrypt could not start HTTP server for challenge: listen tcp :80: bind: address already in use

sec-is

Verified User
Joined
Feb 14, 2020
Messages
85
I am seeing errors on letsencrypt
I am having more and more domains, over different servers, going into 'negative days to renewal' if you look at the number of days for renewal.

The latest ./build letsencrypt does not download a new version of scripts/letsencrypt.sh

The letsencrypt.sh script which was downloaded Feb 7 with version 2.0.32 is working. (and found one on Feb 6)
$ ll scripts/letsencrypt.sh
-rwx------ 1 diradmin diradmin 27749 Feb 7 05:40 scripts/letsencrypt.sh

$ head scripts/letsencrypt.sh
#!/bin/bash
#VERSION=2.0.32
# This script is written by Martynas Bendorius and DirectAdmin


The letsencrypt.sh script which was downloaded Feb 15 has no version number (and does not work as expected)
-rwxr-xr-x 1 root root 22784 Feb 15 09:53 ../scripts/letsencrypt.sh

Note: today I installed a DA box, and this is the file (just installed hours ago):
# ll scripts/letsencrypt.sh
-rwxr-xr-x 1 root root 22784 Feb 15 04:03 scripts/letsencrypt.sh
[root@217-182-193-117 directadmin]# head -5 scripts/letsencrypt.sh
#!/bin/bash

if [ "$(id -u)" != "0" ]; then


As you can see, no version number.

Output when we request a simple domain and www.domain certificate:
Code:
Cannot Execute Your Request

Details

ss: unrecognized option '--no-header'
Usage: ss [ OPTIONS ]
ss [ OPTIONS ] [ FILTER ]
-h, --help this message
-V, --version output version information
-n, --numeric don't resolve service names
-r, --resolve resolve host names
-a, --all display all sockets
-l, --listening display listening sockets
-o, --options show timer information
-e, --extended show detailed socket information
-m, --memory show socket memory usage
-p, --processes show process using socket
-i, --info show internal TCP information
-s, --summary show socket usage summary
-b, --bpf show bpf filter socket information
-Z, --context display process SELinux security contexts
-z, --contexts display process and socket SELinux security contexts
-N, --net switch to the specified network namespace name

-4, --ipv4 display only IP version 4 sockets
-6, --ipv6 display only IP version 6 sockets
-0, --packet display PACKET sockets
-t, --tcp display only TCP sockets
-S, --sctp display only SCTP sockets
-u, --udp display only UDP sockets
-d, --dccp display only DCCP sockets
-w, --raw display only RAW sockets
-x, --unix display only Unix domain sockets
-f, --family=FAMILY display sockets of type FAMILY

-A, --query=QUERY, --socket=QUERY
QUERY := {all|inet|tcp|udp|raw|unix|unix_dgram|unix_stream|unix_seqpacket|packet|netlink}[,QUERY]

-D, --diag=FILE Dump raw information about TCP sockets to FILE
-F, --filter=FILE read filter information from FILE
FILTER := [ state STATE-FILTER ] [ EXPRESSION ]
STATE-FILTER := {all|connected|synchronized|bucket|big|TCP-STATES}
TCP-STATES := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|closed|close-wait|last-ack|listen|closing}
connected := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}
synchronized := {established|syn-recv|fin-wait-{1,2}|time-wait|close-wait|last-ack|closing}
bucket := {syn-recv|time-wait}
big := {established|syn-sent|fin-wait-{1,2}|closed|close-wait|last-ack|listen|closing}
2024/02/15 21:40:34 [INFO] [mydomain.com, www.mydomain.com] acme: Obtaining SAN certificate
2024/02/15 21:40:35 [INFO] [mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3156876654565
2024/02/15 21:40:35 [INFO] [www.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3457765157656
2024/02/15 21:40:35 [INFO] [mydomain.com] acme: Could not find solver for: tls-alpn-01
2024/02/15 21:40:35 [INFO] [mydomain.com] acme: use http-01 solver
2024/02/15 21:40:35 [INFO] [www.mydomain.com] acme: Could not find solver for: tls-alpn-01
2024/02/15 21:40:35 [INFO] [www.mydomain.com] acme: use http-01 solver
2024/02/15 21:40:35 [INFO] [mydomain.com] acme: Trying to solve HTTP-01
2024/02/15 21:40:35 [INFO] [www.mydomain.com] acme: Trying to solve HTTP-01
2024/02/15 21:40:36 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3157676654565
2024/02/15 21:40:36 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3457765185656
2024/02/15 21:40:36 Could not obtain certificates:
error: one or more domains had a problem:
[mydomain.com] [mydomain.com] acme: error presenting token: could not start HTTP server for challenge: listen tcp :80: bind: address already in use
[www.mydomain.com] [www.mydomain.com] acme: error presenting token: could not start HTTP server for challenge: listen tcp :80: bind: address already in use
Failed to issue new certificate

(note: acme urls are fake, anonymized)

When I do ./build letsencrypt I see:
download_cached: using cached '/usr/local/directadmin/custombuild/cache/lego_v4.14.2-SNAPSHOT-cd63b325_linux_amd64.tar.gz' file
lego
######################################################################## 100.0%
Lego 4.14.2-SNAPSHOT-cd63b325 Installed.

Same output if I do ./build lego.

(I also emptied the cache, but to no avail).

NOTE: lego is okay, and not 'the problem'. It is the script letsencrypt.sh.

I looked (in evo skin) to choose for 'versions' of letsencrypt, but I can not choose an older version there, letsencrypt is not even shown there ( /evo/admin/custombuild/customize-versions ).
I know I can manually overwrite letsencrypt.sh with a version from https://files.directadmin.com/services/all/letsencrypt/
But strange enough I am not able to find version 2.0.32 there.

I will keep using VERSION 2.0.32. But I assume it will get overwritten by a next update of DA. I hope they read this thread and it gets repaired soon.

it would be nice if the POST THREAD button had a checkbox [x] notify directadmin, this is a system problem. But they would get too many notifications I guess.
Anyone having this same problem: please contact DA. I am using the older version and have no helpdesk access. They do PM me though when needed, which is good.
 
Same issue.

Workaround could be modify scripts/letsencrypt.sh file:

line 347: if ss --no-header --listening --numeric --tcp 'sport = 80' | grep --quiet LISTEN; then

remove "--no-header":

if ss --listening --numeric --tcp 'sport = 80' | grep --quiet LISTEN; then
 
@DA when will you fix this? I have to keep editing the script over and over as you keep overwriting it?
I do not want to make the script readonly, since I do not want to make it go outdated.
 
@fln Every update of DA I have to repair the letsencrypt script. Why can't this been fixed on your end?
I am now thinking of writing a cron script to make the change when needed, on a daily basis. Do end users need to patch on a daily basis? Can you please fix this.
 
Nice of you to let me know your thought. Still it is strange DA is doing micro updates and then every time overwrites a script which is in use every day. And I could 'fix' it with chattr or something like that, but then I would not get any updates for this script and might have new problems.
I do not know how many licenses are 'in use' but I have several servers that have the problem.
Do note: I already wrote a cronjob to solve this for the servers having this problem.
I am using this simple line to fix it:
sed -i 's/ss --no-header/ss/' /usr/local/directadmin/scripts/letsencrypt.sh

No need to comment on this, I understand the situation and made sure I no longer have this problem on my servers.
 
My question is tho:

What distro are you running?
Are all servers running the same distro?
Are time and date correct on your servers?
Did you change something to the LEGO script before?
Did you install other Cert software besides the default?

There must be something that causes the issue on your systems that it does not on others.

I'm also running
lego4.14.2-SNAPSHOT-cd63b325
 
They are running a distro which is NOT YET end of life and supported by Direct Admin (RHEL 7).
OS NameOS EOL DateDirectAdmin EOL DateComment
RHEL 7June 2024September 2024glibc 2.17, kernel 3.10

They are being migrated (as planned) to a new distro/server and this will all go away. But because they are valid distro's and DA supports them, I might expect them to keep things working.
I am already migrating these since January, but it takes a while because my customers have lots of special modifications and requirements, which causes a lot of work ahead, to be done per server.
 
@Zhenyapan Did you not read my comment?
>> I do not want to make the script readonly
I do want to keep receiving updates from DA and not break anything.
 
Do note: I already wrote a cronjob to solve this for the servers having this problem.
If something needs to be fixed, it needs fixing, however, for the time being, why don't you use the custom directory?
Make your change as you want, then copy your customized letsencrypt script to the custom directory and then (if things work as should be) the script won't be changed on update anymore.

So no need to have a cron, no need to change everytime and no neet to make the script readonly. Isn't that a better temporary solution?
I'm doing the same at this moment with the get_main_ip6.sh script as ipv6 addresses are not added to the SPF line at this moment.
 
Hoi Richard,

Thank you for your regards on this.
My fix is the only one that is good (for me). Why? As said: I want to accept updates to the script. I can't use a custom script as that may break things.

If I had to fix the IPv6 thing I would consider to use the custom folder, but in the script (with the same name) do the change in the original script and in a temporary script run that. This way you are always 'up to date'. Note: I know this is not fail safe, but you do get updates from DA this way.
 
do the change in the original script and in a temporary script run that.
Well... that would be a good advise, but that won't work in this case. DA runs the script, not me. And DA itself is using the script when creating a new domain or restoring from a backup. I can't configure a "use that other script as of now" in DA.

And if I use a custom script in a custom directory, then the original script will be overwritten by the custom script anyway. So it's even better to have it work directly, to adjust the original script and copy that. Instead of creating a custom script and copy that back overwriting the original script. In fact it's the same result.
And I'm not going to rewrite a script every time via cron either.

I understand your way of view, but the LE script is only rarely updated and if that is done, it's mentioned in the release thread. In dat case, temp move or delete the custom script and your original script is updated again so you don't miss out. Or use the force DA update.
Especially since the script is working in custom mode (both LE and ipv6) it's not that bad if you miss a minor update, if any. These scripts won't break things.

However, ofcourse you can best choose an option you feel happy with. I was merely trying to give an alternative so you didn't have to rewrite the script again every time.
 
@sec-is tool ss is provided by the iproute package. On RHEL 7 systems you should have iproute 4.11.0-30 installed.

The script is tested against this version and do handle --no-header parameter. Could you please provide the output of the following commands:
  • yum info iproute should show Version : 4.11.0
  • ss --version should print iproute2-ss170501
Quick search on the upstream repo shows this option was introduced in iproute 4.7.0:


At the time this feature was introduced internal iproute2 snapshot version was 160518

 
@sec-is tool ss is provided by the iproute package. On RHEL 7 systems you should have iproute 4.11.0-30 installed.

The script is tested against this version and do handle --no-header parameter. Could you please provide the output of the following commands:
  • yum info iproute should show Version : 4.11.0
  • ss --version should print iproute2-ss170501
Quick search on the upstream repo shows this option was introduced in iproute 4.7.0:


At the time this feature was introduced internal iproute2 snapshot version was 160518

# yum info iproute
Installed Packages
Name : iproute
Arch : x86_64
Version : 3.10.0
Release : 87.el7
Size : 1.4 M
Repo : installed
Summary : Advanced IP routing and network device configuration tools
URL : http://kernel.org/pub/linux/utils/net/iproute2/
License : GPLv2+ and Public Domain
Description : The iproute package contains networking utilities (ip and rtmon, for example)
: which are designed to use the advanced networking capabilities of the Linux
: 2.4.x and 2.6.x kernel.
# ss --version
ss utility, iproute2-ss130716

# cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)
 
Seems quite old. I would recommend upgrading all system packages to the latest available version, but for this particular issue yum update iproute should be enough to fix it.
 
Seems quite old. I would recommend upgrading all system packages to the latest available version, but for this particular issue yum update iproute should be enough to fix it.
Code:
# yum info iproute
Installed Packages
Name        : iproute
Arch        : x86_64
Version     : 3.10.0
Release     : 87.el7
Size        : 1.4 M
Repo        : installed
Summary     : Advanced IP routing and network device configuration tools
URL         : http://kernel.org/pub/linux/utils/net/iproute2/
License     : GPLv2+ and Public Domain
Description : The iproute package contains networking utilities (ip and rtmon, for example)
            : which are designed to use the advanced networking capabilities of the Linux
            : 2.4.x and 2.6.x kernel.


Code:
# yum update iproute
No packages marked for update
 
looks like it installed manually, different repo from my centos7:
Installed Packages
Name : iproute
Arch : x86_64
Version : 4.11.0
Release : 30.el7
Size : 1.8 M
Repo : installed
From repo : base
Summary : Advanced IP routing and network device configuration tools
------
check maybe it in yum excludes? or you can replace it from RPM package
 
If system reports no updates available it could mean there are issues with yum configuration, for example main repo is disabled or configured to not use the latest CentOS 7 repo but some older version. Commands yum repolist enabled and yum repolist -v enabled | grep Repo-baseurl might provide more information on what actual repo URLs are being used.

For example http://mirror.centos.org/centos/7/os/x86_64/Packages/ shows iproute-4.11.0-30.el7.x86_64.rpm as latest available version. Maybe older CentOS 7 minor releases used to have older versions.
 
Back
Top