Latest UTM and Let's Encrypt Failures

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

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

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

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.

I have this:

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. 

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.