UTM has the proper certs installed via UTM admin but for some reason the creating of account fails as client can't get the TOS due to certificate errors. Odd thing is I have another UTM with same certs installed and have no issues accessing the pages and creating an account..
It produced this output:
WGET Output:
Connecting to acme-v02.api.letsencrypt.org|172.65.32.248|:443... connected.
ERROR: cannot verify acme-v02.api.letsencrypt.org's certificate, issued by `/C=US/O=Let's Encrypt/CN=R11':
unable to get issuer certificate
CURL Output:
Server certificate:
subject: CN=acme-v02.api.letsencrypt.org
start date: 2024-06-25 20:21:41 GMT
expire date: 2024-09-23 20:21:40 GMT
issuer: C=US; O=Let's Encrypt; CN=R10
SSL certificate verify result: unable to get issuer certificate (2), continuing anyway.
My web server is (include version): N/A
The operating system my web server runs on is (include version): UTM 9 - Latest Version
My hosting provider, if applicable, is: N/A
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): UTM 9 Administration Site
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A - Using built in client in UTM
These are the certs listed in the UTM certificate management page.
I have another UTM which lists the same certs and has no issues. I do have root access to terminal. Sophos UTM is based on a Sophos-hardened version of a SUSE Linux 11 kernel (SLES11).
Well, those E1/E2/R3/R4 intermediates shouldn't be used as trust anchors to begin with and they've been retired. Having ISRG Root X1 and ISRG Root X2 as trust anchors should be enough.
Having a cross-signed X2 as trust anchor is useless too.
I removed them and tried the wget for the URL and this is the error:
ERROR: cannot verify acme-v02.api.letsencrypt.org's certificate, issued by `/C=US/O=Let's Encrypt/CN=R10':
unable to get issuer certificate
SSL certificate problem: unable to get issuer certificate
Closing connection 0
curl: (60) SSL certificate problem: unable to get issuer certificate
More details here: curl - SSL CA Certificates
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
If I set random paths/files for --cacert and --capath (it's rather hard to mess up the verification actually), I'm getting a "unable to get local issuer certificate" error.. I find it kinda weird your error mesage misses the "local" part.
Did you run update-ca-certificates after you added the certs to /etc/ssl/certs/?
What does openssl s_client -connect acme-v02.api.letsencrypt.org:443 say?
This situation smells like how cPanel uses a repository of intermediate certificates rather than using the one that's provided by the CA for installation, but that's in the opposite direction.
Good question. Wonder if there is a "support pack" that contains all the certs required. I think we are sneaking up on this. Thanks for the experienced eye on this. Where can I get a .pem of this?
Digital Signature Trust Co., CN = DST Root CA X3
You don't want and you don't need that root, it has been deprecated and is going to expire soon anyway.
You need to figure out where the ISRG Root X1 cross-signed-by DST Root CA X3 is in your system. I'm guessing you've got it added somewhere and OpenSSL is trying to use it for some reason. I don't know why it would be in OpenSSLs output otherwise, as it is not used by Let's Encrypt.
