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-
Hi FreeIPA,
We have some replication messages in our slapd errors log which look very
like the ones discussed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1574602
I took a look and we do have the MemberOf plugin, but our version of 389-ds
newer:
*389-ds-base-1.3.10.2-10.el7_9.x86_64*
Ho
Did you install the LE Root CA's first?
CERTS=("isrgrootx1.pem" "isrg-root-x2.pem" "lets-encrypt-r3.pem"
"lets-encrypt-e1.pem" "lets-encrypt-r4.pem" "lets-encrypt-e2.pem")
for CERT in "${CERTS[@]}"
do
wget -O "/etc/ssl/$CERT" "https://letsencrypt.org/certs/$CERT";
ipa-cacert-manage install
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
Chris Moody via FreeIPA-users wrote:
> Just found some additional possible clues in the ap
Hi,
to conclude this issue: I eventually reinstalled the server. So no real
solution but this was better to calculate in terms of how much time we needed.
Thanks for the help here!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
