Hi,
Pretty much any vault-related calls in one of my environments result in the internal error, although the call seems to (partially) succeed. For example:
# ipa vault-add test --type standard ipa: ERROR: an internal error has occurred
But the vault is created:
# ipa vault-find --------------- 1 vault matched --------------- Vault name: test Type: standard Vault user: admin ---------------------------- Number of entries returned 1 ----------------------------
I'll get the same erorr if I try "ipa vault-del", "vault-archive" or "vault-retrieve".
At the same time, the following is written in /var/log/messages:
Sep 19 23:54:39 t-idm-ber800-1 server: Invalid Credential. Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cmscore.authentication.CertUserDBAuthentication.authenticate(CertUserDBAuthentication.java:174) Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:112) Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:85) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:114) Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:47) Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:89) Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:59) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) Sep 19 23:54:39 t-idm-ber800-1 server: at java.lang.Thread.run(Thread.java:748)
Any idea what could go wrong here....? Thanks.
Info: ipa-server 4.6.4 on RHEL 7.6, and I am running these commands from the IPA server itself, on which CA and KRA are installed (in fact, it's the only active CA/KRA master in that environment).
--- Regards, Dmitry Perets
Hi,
After a bit more searching - my issue looks exactly like this one: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
I also have the same error in /var/log/pki/pki-tomcat/kra/system:
0.ajp-bio-127.0.0.1-8009-exec-1 - [20/Sep/2019:00:04:55 CEST] [6] [3] Cannot authenticate agent with certificate Serial 0x7 Subject DN CN=IPA RA,O=IMS.DCN.TELEKOM.DE. Error: User not found
And I checked the value stored under uid=ipara, it seems to match exactly the RA cert from /var/lib/ipa/ra-agent.pem. Any other place to check...?
--- Regards, Dmitry Perets
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
On ti, 01 loka 2019, Dmitry Perets via FreeIPA-users wrote:
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
This looks like actual IPA RA subject is fixed in the code in ipaserver/install/krainstance.py:
class KRAInstance(DogtagInstance): ..... def __create_kra_agent(self): ..... # create ipakra user with RA agent certificate user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn) entry = conn.make_entry( user_dn, objectClass=['top', 'person', 'organizationalPerson', 'inetOrgPerson', 'cmsuser'], uid=["ipakra"], sn=["IPA KRA User"], cn=["IPA KRA User"], usertype=["undefined"], userCertificate=[cert], description=['2;%s;%s;%s' % ( cert.serial_number, DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry)
I think it should be picked up from the cert. Time for a ticket?
On Tue, Oct 01, 2019 at 10:51:37AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 01 loka 2019, Dmitry Perets via FreeIPA-users wrote:
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
This looks like actual IPA RA subject is fixed in the code in ipaserver/install/krainstance.py:
class KRAInstance(DogtagInstance): ..... def __create_kra_agent(self): ..... # create ipakra user with RA agent certificate user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn) entry = conn.make_entry( user_dn, objectClass=['top', 'person', 'organizationalPerson', 'inetOrgPerson', 'cmsuser'], uid=["ipakra"], sn=["IPA KRA User"], cn=["IPA KRA User"], usertype=["undefined"], userCertificate=[cert], description=['2;%s;%s;%s' % ( cert.serial_number, DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry)
I think it should be picked up from the cert. Time for a ticket?
Time for a ticket, yes. But the above code looks ok. The problem is 'self.subject' (the issuer DN) contains the wrong value. I'll follow the reproducer steps to see what's going on. I suspect KRAInstance instance is not initialised properly for some operation.
Cheers, Fraser
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Tue, Oct 01, 2019 at 07:14:17PM +1000, Fraser Tweedale via FreeIPA-users wrote:
On Tue, Oct 01, 2019 at 10:51:37AM +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 01 loka 2019, Dmitry Perets via FreeIPA-users wrote:
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
This looks like actual IPA RA subject is fixed in the code in ipaserver/install/krainstance.py:
class KRAInstance(DogtagInstance): ..... def __create_kra_agent(self): ..... # create ipakra user with RA agent certificate user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn) entry = conn.make_entry( user_dn, objectClass=['top', 'person', 'organizationalPerson', 'inetOrgPerson', 'cmsuser'], uid=["ipakra"], sn=["IPA KRA User"], cn=["IPA KRA User"], usertype=["undefined"], userCertificate=[cert], description=['2;%s;%s;%s' % ( cert.serial_number, DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry)
I think it should be picked up from the cert. Time for a ticket?
Time for a ticket, yes. But the above code looks ok. The problem is 'self.subject' (the issuer DN) contains the wrong value. I'll follow the reproducer steps to see what's going on. I suspect KRAInstance instance is not initialised properly for some operation.
Ticket: https://pagure.io/freeipa/issue/8084
I will work on this in the next sprint (which starts in a couple of days).
Cheers, Fraser
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Dmitry Perets -
Fraser Tweedale