Let's encryprt keep looking for the old IP adresse

[dclement]

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: dhis.dsnis.bi

I ran this command: certbot --standalone certonly -d "dhis.dsnis.bi" -m "cdadjo@hispwca.org" --agree-tos --dry-run

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for dhis.dsnis.bi

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: dhis.dsnis.bi
Type: unauthorized
Detail: 161.97.161.86: Invalid response from http://dhis.dsnis.bi/.well-known/acme-challenge/VgIxvf8573Zpw2NbZMBJj8yDwYnhbkJBQsfRkOAaCok: 404

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): apache2

The operating system my web server runs on is (include version): ubuntu server 22.04 LTS

My hosting provider, if applicable, is: contabo

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 1.21.0

[Osiris]

Looks like this is a so called "glue record" problem in the .com. TLD zones nameservers.

The authorative nameservers for your domain dhis.dsnis.bi are ns9.afriregister.co.ke. and ns3.afriregister.com.. The former is fine, but when the DNS resolver is getting these authorative nameservers from a DNS server of the .com. TLD, e.g. k.gtld-servers.net, then that nameserver replies with:

osiris@erazer ~ $ dig @k.gtld-servers.net ns3.afriregister.com.

(...)
;; QUESTION SECTION:
;ns3.afriregister.com.		IN	A

;; AUTHORITY SECTION:
afriregister.com.	172800	IN	NS	ns3.afriregister.com.
afriregister.com.	172800	IN	NS	ns02.afriregister.com.

;; ADDITIONAL SECTION:
ns3.afriregister.com.	172800	IN	A	80.241.213.244
ns02.afriregister.com.	172800	IN	A	149.102.157.47

;; Query time: 82 msec
;; SERVER: 2001:503:d2d::30#53(k.gtld-servers.net) (UDP)
(...)
osiris@erazer ~ $ 

The line

ns3.afriregister.com.	172800	IN	A	80.241.213.244

is important here.

Because if you request THAT specific IP address for your domain, you get:

osiris@erazer ~ $ dig @80.241.213.244 dhis.dsnis.bi.

(...)
;; QUESTION SECTION:
;dhis.dsnis.bi.			IN	A

;; ANSWER SECTION:
dhis.dsnis.bi.		14400	IN	A	161.97.161.86

;; AUTHORITY SECTION:
dsnis.bi.		86400	IN	NS	ns9.afriregister.co.ke.
dsnis.bi.		86400	IN	NS	ns3.afriregister.com.

;; ADDITIONAL SECTION:
ns9.afriregister.co.ke.	14400	IN	A	5.189.141.132
ns3.afriregister.com.	14400	IN	A	194.163.180.153

;; Query time: 55 msec
;; SERVER: 80.241.213.244#53(80.241.213.244) (UDP)
(...)
osiris@erazer ~ $ 

The interesting thing is: the glue record of the nameserver itself is a different one (194.163.180.153).. If you ask that IP address, you get a "REFUSED" reply?:

osiris@erazer ~ $ dig @194.163.180.153 dhis.dsnis.bi.
(...)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 28235
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
(...)
;; QUESTION SECTION:
;dhis.dsnis.bi.			IN	A

;; Query time: 17 msec
;; SERVER: 194.163.180.153#53(194.163.180.153) (UDP)
(...)
osiris@erazer ~ $ 

Only ns9.afriregister.co.ke. seems to be serving the correct IP address:

osiris@erazer ~ $ dig @ns9.afriregister.co.ke. dhis.dsnis.bi.
(...)
;; QUESTION SECTION:
;dhis.dsnis.bi.			IN	A

;; ANSWER SECTION:
dhis.dsnis.bi.		14400	IN	A	213.136.74.243

;; AUTHORITY SECTION:
dsnis.bi.		86400	IN	NS	ns3.afriregister.com.
dsnis.bi.		86400	IN	NS	ns9.afriregister.co.ke.

;; ADDITIONAL SECTION:
ns9.afriregister.co.ke.	14400	IN	A	5.189.141.132
ns3.afriregister.com.	14400	IN	A	194.163.180.153

;; Query time: 24 msec
;; SERVER: 5.189.141.132#53(ns9.afriregister.co.ke.) (UDP)
(...)
osiris@erazer ~ $ 

Also not only the .com. TLD nameservers are sending the "incorrect" IP address, one of the afriregister nameservers also sends that, possibly resulting in the .com. zone glue record error:

(...)
ns3.afriregister.com.	14400	IN	A	80.241.213.244
ns3.afriregister.com.	86400	IN	NS	ns02.afriregister.com.
ns3.afriregister.com.	86400	IN	NS	ns9.afriregister.co.ke.
ns3.afriregister.com.	86400	IN	NS	ns3.afriregister.com.
;; Received 194 bytes from 149.102.157.47#53(ns02.afriregister.com) in 20 ms
(...)

Anyway, the afriregister nameservers seem to be incorrectly configured, at least for your domain. Not something Let's Encrypt can do anything about.

By the way, UnboundTest.com sometimes gets it incorrect (https://unboundtest.com/m/A/dhis.dsnis.bi/MEPUKL6W) and sometimes gets it correct (https://unboundtest.com/m/A/dhis.dsnis.bi/7UQG6W32).. So if you try enough times, you might get lucky.