Let's encript issue - Connot resolve dns address

Support General Configuration
1

Since I updated to version 10.5.5 of axigen I cannot renew the Let’s Encrypt certificates and in the logs I get the following error:

HTTP-Client: Error performing request in connection to https://acme-v02.api.letsencrypt.org:443/directory:Couldn't resolve host name

I tried to access from the Debian console to the address http://acme-v02.api.letsencrypt.org using CURL and I accessed correctly. After different tests, the system seems to resolve DNS well.

Thanks a lot!

2

Hello David,

Could you please let us know the version from which you have updated from?

Also, could you please provide the entire JOBLOG lines related to the renewal of the LE certificate you are referring to?

Note: ideally please set jobLogging with logLevel 31 before retrying the renewal.

    jobLogging = {
        ...
        logLevel = 31
        ...
    }

HTH,
Ioan

3

Hello indreias,

I updated from version 10.4.18 to version 10.5.5 and already had this problem. Two days ago I updated from version 10.5.5 to version 10.5.6 to see if the problem was resolved, but the problem persists.

I have changed the loglevel value to 31 in the jobLogging section on axigen.cfg file and in the registry (edited) this appears:

JOBLOG:7000000F: HTTP-Client: Error performing request in connection to https://acme-v02.api.letsencrypt.org:443/directory:Couldn’t resolve host name
JOBLOG:7000000F: LetsE: connection error on GET when populating acme link directory
JOBLOG:7000000F: LetsE: Job step action => Connection-related error, re-attempting after 240 seconds
JOBLOG:70000010: LetsE: Acme job executing
JOBLOG:70000010: LetsE: AcmeInitState for domain.net executing

5

Hello David,

First of all I like to let you know that we are not aware of any changes between 10.4.18 and 10.5.5+ that could explain the reported behavior. This is why, my first suggestion is to review any local (on the system Axigen is running) changes that may explain the “Couldn’t resolve host name” error reported into the logs.

The strange part is that you do not have the same error when running the curl command from that system so we like to ask you to share the following outputs from the commands executed from that system:

$ cat /etc/resolv.conf
$ host -v acme-v02.api.letsencrypt.org
$ printenv
$ curl -v https://acme-v02.api.letsencrypt.org

Looking forward for your feedback.

Best regards,
Ioan

6

Hello indreias,

Command: cat /etc/resolv.conf
Results:
root@host:~# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Command: host -v acme-v02.api.letsencrypt.org
Results:
root@host:~# host -v acme-v02.api.letsencrypt.org
Trying “acme-v02.api.letsencrypt.org”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44093
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;acme-v02.api.letsencrypt.org. IN A

;; ANSWER SECTION:
acme-v02.api.letsencrypt.org. 7200 IN CNAME prod.api.letsencrypt.org.
prod.api.letsencrypt.org. 300 IN CNAME ca80a1adb12a4fbdac5ffcbc944e9a61 .pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. 300 IN A 172.65.32.248

Received 144 bytes from 8.8.8.8#53 in 15 ms
Trying “ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14205
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. IN AAAA

;; ANSWER SECTION:
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. 300 IN AAAA 2606:4700:60:0:f5 3d:5624:85c7:3a2c

Received 95 bytes from 8.8.8.8#53 in 3 ms
Trying “ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53530
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. IN MX

;; AUTHORITY SECTION:
pacloudflare.com. 1800 IN SOA brenda.ns.cloudflare.com. dns.cl oudflare.com. 2319567477 10000 2400 604800 1800

Received 128 bytes from 8.8.8.8#53 in 3 ms

Command: printenv
Result:
root@host:~# printenv
SHELL=/bin/bash
PWD=/root
LOGNAME=root
XDG_SESSION_TYPE=tty
MOTD_SHOWN=pam
HOME=/root
LANG=en_US.UTF-8
SSH_CONNECTION=67.218.248.9 39853 185.47.131.90 22
XDG_SESSION_CLASS=user
TERM=xterm
USER=root
SHLVL=1
XDG_SESSION_ID=293
XDG_RUNTIME_DIR=/run/user/0
SSH_CLIENT=67.218.248.9 39853 22
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SSH_TTY=/dev/pts/0
_=/usr/bin/printenv

Command: curl -v https://acme-v02.api.letsencrypt.org
Result:
root@host:~# curl -v https://acme-v02.api.letsencrypt.org

  • Trying 172.65.32.248:443…
  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=acme-v02.api.letsencrypt.org
  • start date: Aug 30 03:48:44 2023 GMT
  • expire date: Nov 28 03:48:43 2023 GMT
  • subjectAltName: host “acme-v02.api.letsencrypt.org” matched cert’s “acme-v02. api.letsencrypt.org”
  • issuer: C=US; O=Let’s Encrypt; CN=R3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • Using Stream ID: 1 (easy handle 0x55ff51dcbcc0)

GET / HTTP/2
Host: acme-v02.api.letsencrypt.org
user-agent: curl/7.74.0
accept: /

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • old SSL session ID is stale, removing
  • Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
    < HTTP/2 200
    < server: nginx
    < date: Thu, 07 Sep 2023 10:31:55 GMT
    < content-type: text/html
    < content-length: 1540
    < last-modified: Thu, 23 Jun 2022 21:26:20 GMT
    < etag: “62b4da7c-604”
    < x-frame-options: DENY
    < strict-transport-security: max-age=604800
    <
Boulder: The Let's Encrypt CA header { display: flex; max-height: 30vh; flex-wrap: wrap; margin-bottom: 10 vh; } header img { display: flex; max-height: 20vh; align-content: flex-end; margi n-right: 20px; }

Boulder
The Let's Encrypt CA

This is an ACME Certifi cate Authority running Boulder< /a>.

This is a programmatic endpoint, an API for a computer to talk t o. You should probably be using a specialized client to utilize the service, and not your web browser. See https://le tsencrypt.org/docs for help.

If you're trying to use this service, note that the starting point, t he directory, is available at this URL: https://acme-v02.api.letsencrypt.org/directory.

Service Status (l etsencrypt.status.io) | Let's Encrypt Twitter

* Connection #0 to host acme-v02.api.letsencrypt.org left intact ----

Best regards,
David

7

Hello David,

All looks fine so let’s see the output from the following commands:

$ /opt/axigen/bin/axigen --version
$ ps -ef  |  grep axigen
$ runuser -u axigen -g axigen host acme-v02.api.letsencrypt.org

BR,
Ioan

8

Hello indreias,

Command: /opt/axigen/bin/axigen --version
Output:
root@host:/var/opt# /opt/axigen/bin/axigen --version
Axigen server version: 10.5.6 (Linux/x86_64)

–

Command: ps -ef | grep axigen
Output:
root@host: /var/opt# ps -ef | grep axigen
root 57057 1 0 Sep06 ? 00:00:02 /opt/axigen/bin/axigen --max-respawns 3 -W /var/opt/axigen
axigen 57058 57057 0 Sep06 ? 00:01:22 /opt/axigen/bin/axigen --max-respawns 3 -W /var/opt/axigen
root 64955 64923 0 14:25 pts/0 00:00:00 grep axigen

–

Command: runuser -u axigen -g axigen host acme-v02.api.letsencrypt.org
Output:
root@host: /var/opt# runuser -u axigen -g axigen host acme-v02.api.letsencrypt.org
acme-v02.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address 172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address 2606:4700:60:0:f53d:5624:85c7:3a2c

–

Thanks a lot!

David

9

Hello David,

All looks fine as well - so we should continue our debugging session.

Let’s capture the traffic on both UDP and TCP port 53 when the renewal is executed so please start the following command:

$ tcpdump -i any -nn -s0 -w /var/tmp/dns.pcap port 53

and request a renewal for the LE certificate via WebAdmin (Security & Filtering > SSL Certificates > Renew button for the LE certificate).

After the failure is noticed into the Axigen log please stop the tcpdump session (with CTRL+C) and share with us:
i/ the Axigen log line saying “Couldn’t resolve host name …” (with the log timestamp)
ii/ the file generated by tcpdump (which is /var/tmp/dns.pcap)

HTH,
Ioan

1 Like
10

Hello Ioan,

I have attached the dns.pcap file in this message

Thanks!
dns_pcap.rar (192 Bytes)

11

Hello David,

Well, from the tcpdump capture we see that your system is receiving DNS requests from Internet as there was captured only one record:

source: 157.245.252.18, port 50901 | belonging to Digital Ocean | AS14061
destination: 185.47.131.90, port 53 | this seems to be your system
DNS query: A www.google.com

image
image2559×407 45.4 KB

As we do not see the expected DNS traffic to the configured DNS servers from /etc/resolv.conf (8.8.8.8 and 8.8.4.4) I could only suspect that you are using a more complicated setup.

As suggested, please double check what was changed on your system from the end of June (when the cert seems to be issued by LE) and today.

BR,
Ioan

12

Thanks, I will review all changes made since june.

13

Hi,

I made some tests (tcpdump -i all) and i have seen that webadmin don’t make any dns query.
Within webadmin i cannot serch for new updates, renew and add letsencrypt certificates and nothing related with system DNS queryes.

But DNR service works perfectly and i can receive amb send mails without problems. Only the admin (WebAdmin) section fails, even when I go to the main webadmin page it takes a long time to fully load.

Linux OS: Debian 11
Axigen ver.: 10.5.6

System only dedicated to Axigen server, nothing else is installed.

I will keep researching to find a solution.