Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 6 subscribers
  • Views 2956 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
  • 0 in reply to Harro Verton

    What is odd here is that I have added all the current certs to the system that Let's Encrypt has available and the system looks to be not using them during the client connection. The ACME client connection process appears to not have access to these installed certs or that process session has a corrupt cached certificate store. See my other posts that describe this behavior. 

Reply
  • 0 in reply to Harro Verton

    What is odd here is that I have added all the current certs to the system that Let's Encrypt has available and the system looks to be not using them during the client connection. The ACME client connection process appears to not have access to these installed certs or that process session has a corrupt cached certificate store. See my other posts that describe this behavior. 

Children
No Data
Unfiltered HTML