Tomasz Torcz via FreeIPA-users wrote:
On Thu, Oct 21, 2021 at 01:25:09PM -0500, Endi Dewata via FreeIPA-users wrote:
On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata edewata@redhat.com wrote:
I think the class loading messages above were generated by Tomcat. That's probably how it resolves the classes, so I don't think that's an issue.
Could you raise the debug level in the CA subsystem too? https://github.com/dogtagpki/pki/wiki/Configuring-Subsystem-Debug-Log The authenticator uses the LDAP connection in the CA to find the user in DS, so there might be an issue there.
Actually it's a bit different for ACME. I just updated the above page. Could you raise the logging level in ACME too?
I've increased all the loglevels to FINE, there are no additional logs: INFO: PKIAuthenticator: Authenticate with client certificate authentication INFO: Authenticating certificate chain: INFO: - CN=IPA RA,O=PIPEBREAKER.PL INFO: - CN=Certificate Authority,O=PIPEBREAKER.PL INFO: PKIAuthenticator: Result: false
and in ca/debug-<date>.log:
2021-10-22 19:55:32 [Timer-0] FINE: LdapBoundConnFactory: number of connections: 3 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: Certificates: 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=IPA RA,O=PIPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: parent: CN=Certificate Authority,O=PIPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=Certificate Authority,O=PIPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: child: CN=IPA RA,O=PIPEBREAKER.PL
dirsrv log shows 1 certificate is being found: [22/Oct/2021:20:05:35.119328765 +0200] conn=4469 op=9 SRCH base="ou=people,o=ipaca" scope=1 filter="(description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IP A RA,O=PIPEBREAKER.PL)" attrs=ALL [22/Oct/2021:20:05:35.119963856 +0200] conn=4469 op=9 RESULT err=0 tag=101 nentries=1 wtime=0.000231485 optime=0.000638726 etime=0.000867770 [22/Oct/2021:20:05:35.277708077 +0200] conn=4508 op=3 UNBIND
BUT in acme/debug.log:
2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Looking up certificates 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Authenticating user with client certificate 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Finding user by cert: 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - base DN: ou=people,o=ipaca 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - filter: description=2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: User: uid=ipara,ou=people,o=ipaca 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Realm.authenticate() returned false
So a problem with realm?
ACME also has a realm configuration: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configur... https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configur... so there could be an issue there.
This look to be configured, but I found a possible discrepancy in "password":
$ cat /etc/pki/pki-tomcat/acme/realm.conf # VERSION 2 - DO NOT REMOVE THIS LINE authType=BasicAuth class=org.dogtagpki.acme.realm.DSRealm groupsDN=ou=groups,o=ipaca usersDN=ou=people,o=ipaca url=ldaps://kaitain.pipebreaker.pl:636 configFile=/etc/pki/pki-tomcat/ca/CS.cfg username=acme-kaitain.pipebreaker.pl password=<40-character long text string>
While userPassword:: field of uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca contains very long base64 string, which decodes to 447 string starting with {PBKDF2_SHA256}. How to make sure it's corresponds to the same value?
This is the password for the username in the file. It is basically unused by IPA as IPA uses client auth with the RA agent certificate.
rob