On 09/04/2018 05:33 PM, Stuart McRobert wrote:
Hi,
I'm cc'ing the users mailing list, you may get more help there.
Thanks.
As the output of certutil -K correctly displays an entry for
subsystemCert cert-pki-ca, we can assume that the password is OK.
Okay, good.
I would try to check the next steps detailed in
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/
and ensure that uid=pkidbuser,ou=people,o=ipaca contains the same
certificate as /etc/pki/pki-tomcat/alias, as it is one of the most
frequent root causes for authentication issues between PKI and the
LDAP server after an upgrade.
That does indeed look very likely to be the problem, although the last
upgrade was I think about a year ago and we have only recently seen
issues. However a Fedora release upgrade to F28 is now overdue and on
our list to perform.
Comparing the certificate strings (removed below) from:
ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
...
and
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -a
-----BEGIN CERTIFICATE-----
they do appear to look different.
Next to checking the serial numbers to confirm:
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' | grep Serial
Serial Number: 17 (0x11)
and from
ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
description: 2;4;CN=Certificate Authority
which if I have understood correctly gives us the value 4 which clearly
doesn't match with 17.
I believe I should now take the "new" certificate as the one provided by:
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -a
and save that into an update file with it appearing as a very long
single line certificate, a minus, then update the serial number in the
description:
dn: uid=pkidbuser,ou=people,o=ipaca
changetype: modify
replace: usercertificate
usercertificate::MIIDhjCC.............
-
replace: description
description: 2;17;CN=Certificate Authority,O=XXX;CN=CA Subsystem,O=XXX
Then I update with:
ldapmodify -D "cn=directory manager" -W -f my_update_file
If this all looks fine to everybody I will go ahead and try this update.
Yes, this looks correct. Make sure that 17 is the serial of your new
certificate (it may differ from my example), and don't forget to replace
O=XXX with the correct domain for your deployment.
I also note your end comment:
This could be described in another blog post (for the impatients, the
automatic renewal of the certificate failed to update the LDAP server
entry…)
I suspect this may well be the case, I note
ipa-getcert list
reports one that expires: 2018-09-09 18:00:20 BST which I would have
thought all being well would have been automatically renewed by now?
Hopefully it will just happen once back up and running?
Yes, the cert should have been automatically renewed. We had a SELinux
issue (https://bugzilla.redhat.com/show_bug.cgi?id=1475528) that was
preventing the renewal and can explain why subsystemCert cert-pki-ca was
not copied to LDAP.
Which cert is now nearing its expiration date? When the PKI instance on
your system is able to start, please closely monitor its renewal or keep
the mailing list in the loop if it does not renew automatically.
HTH,
flo
Best wishes
Stuart
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
