Hi,
Posting back here, in case someone gets this issue in the future...
The problem turned out to be that IPA put wrong CA cert subject in the LDAP entry under "uid=ipakra,ou=people,o=kra,o=ipaca". It looked like this:
dn: uid=ipakra,ou=people,o=kra,o=ipaca description: 2;7;CN=Certificate Authority,O=<my_realm>;CN=IPA RA,O=<my_realm> uid: ipakra sn: IPA KRA User usertype: undefined userCertificate:: <here cert comes> objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser cn: IPA KRA User
So there are a couple of requirements that this entry must satisfy, such as: - `userCertificate` must contain the cert from /var/lib/ipa/ra-agent.pem - `description` must contain cert serial number (it's the second integer, usually 7) - `description` must further contain the issuer of that the cert and its subject (CN=IPA RA...)
So in our case, the problem was with the wrong issuer. `CN=Certificate Authority` is the default issuer subject, but in my environment I actually use a custom one:
$ openssl x509 -noout -issuer -subject -in /var/lib/ipa/ra-agent.pem issuer= /CN=My CA/O=<my_realm> subject= /O=<my_realm>/CN=IPA RA
So the solution was to update that entry in LDAP. The right value for me was (note reversed elements of RDN):
description: 2;7;O=<my_realm>,CN=My CA;CN=IPA RA,O=<my_realm>
I believe it's a bug, and I am almost sure I know how to reproduce it. We had it in two different environments, and in both of them the following flow happened:
1. Deploy the very first IPA1 server, with CA and KRA, using custom CA subject ("--ca-subject" flag) 2. Deploy a replica IPA2, replicating CA and KRA 3. Destroy IPA1
It looks like maybe during the replication IPA puts the default CA subject instead of the custom one... IPA 4.6.4 on RHEL7.6.
Hope it helps someone.
--- Regards, Dmitry Perets