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