That was kinda my belief thus far as well that the hosts were not trusting themselves - not 100% sure how things got here though. I have a hunch it might be related to the initial deployment and the prior admin using an outdated method to install/manage/renew the LE-certificates.
=====
# ipa-cacert-manage list
IPA.REDACTED.COM IPA CA
IPA.REDACTED.COM IPA CA
DSTRootCAX3
letsencryptx3
isrgrootx1
lets-encrypt-r3-cross-signed
The ipa-cacert-manage command was successful
=====
How would I go about forcing re-installation of the host's own CA certificate to ensure it's trust?
Also, since these nodes are not running on an RPM-based distro, the typical cert-store locations I have seen on other systems are not in the same location(s) so I'm not sure totally sure every location to point certutil to be able to examine each cert-store in depth as well (if that might help diagnose further). I ask because I believe these were initially built and then had the "https://github.com/freeipa/freeipa-letsencrypt/" project used to initially deploy the LE-certs - prior to the ipa-cacert-manage command being the official path toward installing/managing these external certificates. I know because this code had been git-pulled onto these nodes, but it obviously doesn't work properly since this git project manipulates the paths below directly instead of managing via the ipa-cacert-manage command.
ex>
/etc/httpd/alias/ (<=== not on these systems)
/etc/pki/pki-tomcat/alias/
/etc/ipa/nssdb/
/etc/dirsrv/slapd-IPA-REDACTED-COM/
Checking that project's git page now though, I see their readme now mentions /var/lib/ipa/certs/, where I just noticed cacert.pem.
=====
/var/lib/ipa/certs# openssl x509 -text -noout -in cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = IPA.REDACTED.COM, CN = Certificate Authority
Validity
Not Before: Apr 16 20:45:46 2020 GMT
Not After : Apr 16 20:45:46 2040 GMT
Subject: O = IPA.REDACTED.COM, CN = Certificate Authority
...
=====
so I believe I might have just located the IPA CA cert in case I need to re-install it.
To the following question, I have the following LE-related certs installed. And yes, I did run into issues a couple months back when LE moved to the new certs on their end so had to import the new authority certs to get the LE host certs to update & import. The LE certificates are functioning and verify for both slapd and apache/tomcat.
=====
DSTRootCAX3.pem LetsEncryptAuthorityX3.pem isrgrootx1.pem lets-encrypt-r3-cross-signed.pem
=====
Thank you all so much for the assistance through all this.
-Chris
On 6/16/21 1:26 PM, Rob Crittenden via FreeIPA-users wrote:
The error suggests that your IPA server doesn't trust its own CA certificate. Does ipa-cacert-manage list include the IPA CA? BTW the new certificate steps are unrelated. This affects all CA requests. rob