Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 6 subscribers
  • Views 3202 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Latest UTM and Let's Encrypt Failures

Exrace

Having issues recently with renewing LE certificates.
For some time, I had a _acme-challenge. TXT record in my UTM firewall domain name.
I don't recall how I got the token, but LE was working fine until this year. Possibly the April changes broke validation using this token as the notes talk about requiring a way to automate adding a challenge record to DNS.

What are others doing to fix this?

Need see if there is a way to create this token at Lets' Encrypt.

The LE log is a bit useless for this:
2024:07:04-00:46:02 xxx letsencrypt[31867]: I Renew certificate: execution failed
2024:07:04-08:47:01 xxx letsencrypt[13531]: E Renew certificate: Incorrect response code from ACME server: 500
2024:07:04-08:47:01 xxx letsencrypt[13531]: E Renew certificate: URL was: acme-v02.api.letsencrypt.org/directory
2024:07:04-08:47:01 xxx letsencrypt[13531]: I Renew certificate: handling CSR REF_CaCsrYellowExt12 for domain set [xxx.domain.com]
2024:07:04-08:47:01 xxx letsencrypt[13531]: E Renew certificate: TOS_UNAVAILABLE: Could not obtain the current version of the Let's Encrypt Terms of Service



This thread was automatically locked due to age.
Parents
  • 0

    You can get this error if you have IPv6 configured, but there is a connectivity issue. Most tools fall back to IPv4 without problems, but the ACME client on the UTM doesn't.

    If you have this issue, get it fixed, or as a workaround, edit /var/storage/chroot-reverseproxy/usr/dehydrated/conf/config, and set

    IP_VERSION=4

    to force a connection using IPv4.

  • 0 in reply to Harro Verton

    I tried this edit and rebooted system. Same error message.

  • 0 in reply to Exrace

    Reboot reset file back to default, so I tried the edit and no reboot. Still fails.

  • 0 in reply to Exrace

    Sorry, now see your response about wget complaining.

    Can you check if you have this:

    esx-fw:/etc/ssl/certs # ls -l /etc/ssl/certs/ | grep ISRG
lrwxrwxrwx 1 root root   16 Jul  7 14:20 0b9bc432.0 -> ISRG_Root_X2.pem
lrwxrwxrwx 1 root root   16 Jul  7 14:20 4042bcee.0 -> ISRG_Root_X1.pem
lrwxrwxrwx 1 root root   16 Jul  7 14:20 6187b673.0 -> ISRG_Root_X1.pem
lrwxrwxrwx 1 root root   16 Jul  7 14:20 8794b4e3.0 -> ISRG_Root_X2.pem
-rw-r--r-- 1 root root 1982 Aug  8 08:05 ISRG_Root_X1.pem
-rw-r--r-- 1 root root  835 Aug  8 08:05 ISRG_Root_X2.pem

    If I see those timestamps, there must be something running that updates them.

  • 0 in reply to Harro Verton

    I have this:

    yellowjacket-19:/etc/ssl/certs # ls -l /etc/ssl/certs/ | grep ISRG
    lrwxrwxrwx 1 root root 16 Aug 8 08:21 0b9bc432.0 -> ISRG_Root_X2.pem
    lrwxrwxrwx 1 root root 16 Aug 8 08:21 8794b4e3.0 -> ISRG_Root_X2.pem
    -rw-r--r-- 1 root root 1982 Aug 8 09:20 ISRG_Root_X1.pem
    -rw-r--r-- 1 root root 835 Aug 8 09:20 ISRG_Root_X2.pem
Reply
  • 0 in reply to Harro Verton

    I have this:

    yellowjacket-19:/etc/ssl/certs # ls -l /etc/ssl/certs/ | grep ISRG
    lrwxrwxrwx 1 root root 16 Aug 8 08:21 0b9bc432.0 -> ISRG_Root_X2.pem
    lrwxrwxrwx 1 root root 16 Aug 8 08:21 8794b4e3.0 -> ISRG_Root_X2.pem
    -rw-r--r-- 1 root root 1982 Aug 8 09:20 ISRG_Root_X1.pem
    -rw-r--r-- 1 root root 835 Aug 8 09:20 ISRG_Root_X2.pem
Children
No Data
Unfiltered HTML