From tomek at pipebreaker.pl Sat Oct 2 14:38:48 2021 Content-Type: multipart/mixed; boundary="===============3294552516011927422==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_RA_Agent_certificate_authorisation_fails_?= =?utf-8?q?=E2=80=93_how_to_debug=3F?= Date: Sat, 02 Oct 2021 16:38:34 +0200 Message-ID: --===============3294552516011927422== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I've encountered some authentication problems with my FreeIPA installation, which I've traced to RA Agent certification auth problems. I've done typical steps to verify certs in LDAP and hit a wall. Please suggest further steps. My setup is 2 masters on Fedora 34: freeipa-server-4.9.6-2.fc34.x86_64 pki-base-10.10.6-1.fc34.noarch Steps I've done: First I noticed problems when enabling ACME: $ ipa-acme-manage enable Failed to authenticate to CA REST API The ipa-acme-manage command failed. This is caused by authentication failure (401 return code), which I confirmed using curl: $ curl -X POST https://kaitain.pipebreaker.pl:8443/acme/enable --cert /var/= lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key = HTTP Status 401 =E2=80=93 Una= uthorized

= HTTP Status 401 =E2=80=93 Unauthorized

Type S= tatus Report

Description The request has not been applied beca= use it lacks valid authentication credentials for the target resource.

Apache Tomcat/9.0.52

Errors from catalina.out: 02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: aut= hType: null 02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: pri= ncipal: null 02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Authentic= ate with client certificate authentication 02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.ProxyRealm.authenticate Authenticating certificate chain: 02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.ProxyRealm.authenticate - CN=3DIPA RA,O=3DPIPEBREAKER.PL 02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.ProxyRealm.authenticate - CN=3DCertificate Authority,O=3DPIPEBREAKE= R.PL 02-Oct-2021 16:29:39.624 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms= .tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Result: f= alse I've made sure that /var/lib/ipa/ra-agent.pem is the same as in LDAP. $ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -text | grep Serial Serial Number: 105 (0x69) $ ldapsearch -o ldif_wrap=3Dno -D "cn=3Ddirectory manager" -W -b o=3Dipaca = "(uid=3Dipara)" = Enter LDAP Password: = # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=3Dipara) # requesting: ALL # # ipara, people, ipaca dn: uid=3Dipara,ou=3Dpeople,o=3Dipaca description: 2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA R= A,O=3DPIPEBREAKER.PL userCertificate;binary:: cn: ipara objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser usertype: agentType sn: ipara uid: ipara userstate: 1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. This is the same certificate; serial number matches, too. Certificate is NOT expired: $ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -dates notBefore=3DJun 16 04:34:42 2021 GMT notAfter=3DJun 6 04:34:42 2023 GMT What should I do next to resolve this authentication issue? -- = Tomasz Torcz Morality must always be based on practicality. tomek(a)pipebreaker.pl =E2=80=94 Baron Vladimir Harkonnen --===============3294552516011927422==-- From tomek at pipebreaker.pl Tue Oct 12 08:15:00 2021 Content-Type: multipart/mixed; boundary="===============1409427861533240712==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Tue, 12 Oct 2021 10:14:43 +0200 Message-ID: In-Reply-To: YVhu6mhITP/YbS1x@mother.pipebreaker.pl --===============1409427861533240712== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-users wr= ote: > $ ipa-acme-manage enable > Failed to authenticate to CA REST API > The ipa-acme-manage command failed. > = = > Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. > This is the same certificate; serial number matches, too. = > What should I do next to resolve this authentication issue? No ideas how to proceed? Most troubleshooting guides end at comparing certs on the filesystem and in LDAP. What's the next step? -- = Tomasz Torcz Morality must always be based on practicality. tomek(a)pipebreaker.pl =E2=80=94 Baron Vladimir Harkonnen --===============1409427861533240712==-- From rcritten at redhat.com Tue Oct 12 18:33:15 2021 Content-Type: multipart/mixed; boundary="===============7744182585707285625==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Tue, 12 Oct 2021 14:33:01 -0400 Message-ID: <0daf5851-083a-8905-786c-a2e52aed12df@redhat.com> In-Reply-To: YWVD82bqgo56YXcB@mother.pipebreaker.pl --===============7744182585707285625== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-users = wrote: >> $ ipa-acme-manage enable >> Failed to authenticate to CA REST API >> The ipa-acme-manage command failed. >> > = >> Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. >> This is the same certificate; serial number matches, too. > = >> What should I do next to resolve this authentication issue? > = > No ideas how to proceed? > Most troubleshooting guides end at comparing certs on the filesystem and > in LDAP. What's the next step? > = I'd suggest trying ipa-healthcheck. It does these comparisons and more. Does the RA cert work in other contexts? Does ipa cert-find work? Can you request a test certificate? rob --===============7744182585707285625==-- From tomek at pipebreaker.pl Thu Oct 14 12:18:13 2021 Content-Type: multipart/mixed; boundary="===============6421883941966420599==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 14 Oct 2021 14:17:58 +0200 Message-ID: In-Reply-To: 0daf5851-083a-8905-786c-a2e52aed12df@redhat.com --===============6421883941966420599== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-users = wrote: > Tomasz Torcz via FreeIPA-users wrote: > > On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-user= s wrote: > >> $ ipa-acme-manage enable > >> Failed to authenticate to CA REST API > >> The ipa-acme-manage command failed. > >> > > = > >> Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. > >> This is the same certificate; serial number matches, too. > > = > >> What should I do next to resolve this authentication issue? > > = > > No ideas how to proceed? > > Most troubleshooting guides end at comparing certs on the filesystem and > > in LDAP. What's the next step? > > = > = > I'd suggest trying ipa-healthcheck. It does these comparisons and more. Run that, some minor warnings, but nothing about RA cert. "source": "ipahealthcheck.ds.replication", "check": "ReplicationCheck", "result": "WARNING", "uuid": "10a0ad23-dc7a-4f43-a5f5-fac08c55a7b9", "when": "20211014120305Z", "duration": "0.392689", "kw": { "key": "DSREPLLE0002", "items": [ "Replication", "Conflict Entries" ], "msg": "There were 1 conflict entries found under the replication suf= fix \"dc=3Dpipebreaker,dc=3Dpl\"." } Not much actionable info here. { "source": "ipahealthcheck.ipa.certs", "check": "IPACertTracking", "result": "WARNING", "uuid": "e4a545a3-ad22-4b8e-b4f0-70287eae98a9", "when": "20211014120309Z", "duration": "2.828753", "kw": { "key": "20141107202922", "msg": "certmonger tracking request {key} found and is not expected o= n an IPA master." } }, $ getcert list -i 20141107202922 Number of certificates and requests being tracked: 10. Request ID '20141107202922': status: MONITORING stuck: no key pair storage: type=3DFILE,location=3D'/etc/pki/tls/private/kaitain.pip= ebreaker.pl.key' certificate: type=3DFILE,location=3D'/etc/pki/tls/certs/kaitain.pipebreake= r.pl.crt' CA: IPA issuer: CN=3DCertificate Authority,O=3DPIPEBREAKER.PL subject: CN=3Dkaitain.pipebreaker.pl,O=3DPIPEBREAKER.PL issued: 2020-08-24 06:23:58 CEST expires: 2022-08-25 06:23:58 CEST dns: kaitain.pipebreaker.pl principal name: host/kaitain.pipebreaker.pl(a)PIPEBREAKER.PL key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: = post-save command: = track: yes auto-renew: yes Looks fine, I have this cert/key configured in systemd-journal-upload servi= ce, this is not a part of FreeIPA. { "source": "ipahealthcheck.ipa.certs", "check": "IPACertDNSSAN", "result": "ERROR", "uuid": "87699232-f56d-47e4-802b-afab4f1d1b9b", "when": "20211014120312Z", "duration": "2.300274", "kw": { "key": "20200624045303", "hostname": "kaitain.pipebreaker.pl", "san": [], "ca": "IPA", "profile": "caIPAserviceCert", "msg": "Certificate request id {key} with profile {profile} for CA {c= a} does not have a DNS SAN {san} matching name {hostname}" } } ] $ getcert list -i 20200624045303 Number of certificates and requests being tracked: 10. Request ID '20200624045303': status: MONITORING stuck: no key pair storage: type=3DNSSDB,location=3D'/etc/dirsrv/slapd-PIPEBREAKER-P= L',nickname=3D'Server-Cert',token=3D'NSS Certificate DB',pinfile=3D'/etc/di= rsrv/slapd-PIPEBREAKER-PL/pwdfile.txt' certificate: type=3DNSSDB,location=3D'/etc/dirsrv/slapd-PIPEBREAKER-PL',ni= ckname=3D'Server-Cert',token=3D'NSS Certificate DB' CA: IPA issuer: CN=3DCertificate Authority,O=3DPIPEBREAKER.PL subject: CN=3Dkaitain.pipebreaker.pl,O=3DPIPEBREAKER.PL issued: 2021-08-18 14:27:32 CEST expires: 2023-08-19 14:27:32 CEST principal name: ldap/kaitain.pipebreaker.pl(a)PIPEBREAKER.PL key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth profile: caIPAserviceCert pre-save command: = post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv PIPEBREAKER-= PL track: yes auto-renew: y Also looks fine, SAN requirement in certificates only appeared few years ag= o, after this particular server was installed. I doubt it is even used in context o= f LDAP connection. > Does the RA cert work in other contexts? Does ipa cert-find work? Can > you request a test certificate? It looks so: root(a)kaitain ~$ ipa cert-find ipa: ERROR: did not receive Kerberos credentials root(a)kaitain ~$ kinit admin Password for admin(a)PIPEBREAKER.PL: = root(a)kaitain ~$ ipa cert-find ipa: WARNING: Search result has been truncated: Configured size limit excee= ded ------------------------ 100 certificates matched ------------------------ [ =E2=80=A6 hundred certificates listed =E2=80=A6 ] When I check in WebUI I see that latest certificate was Issued On Tue Oct 05 20:27:05 2021 UTC So it worked last week. What would be next step? -- = Tomasz Torcz Only gods can safely risk perfection, tomek(a)pipebreaker.pl it's a dangerous thing for a man. =E2=80=94 Alia --===============6421883941966420599==-- From rcritten at redhat.com Fri Oct 15 18:05:17 2021 Content-Type: multipart/mixed; boundary="===============6134741517445722082==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Fri, 15 Oct 2021 14:04:42 -0400 Message-ID: In-Reply-To: YWgf9rSw6wKslFJt@mother.pipebreaker.pl --===============6134741517445722082== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-user= s wrote: >> Tomasz Torcz via FreeIPA-users wrote: >>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-user= s wrote: >>>> $ ipa-acme-manage enable >>>> Failed to authenticate to CA REST API >>>> The ipa-acme-manage command failed. >>>> >>> = >>>> Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. >>>> This is the same certificate; serial number matches, too. >>> = >>>> What should I do next to resolve this authentication issue? >>> >>> No ideas how to proceed? >>> Most troubleshooting guides end at comparing certs on the filesystem and >>> in LDAP. What's the next step? >>> >> >> I'd suggest trying ipa-healthcheck. It does these comparisons and more. > = > Run that, some minor warnings, but nothing about RA cert. > = > "source": "ipahealthcheck.ds.replication", > "check": "ReplicationCheck", > "result": "WARNING", > "uuid": "10a0ad23-dc7a-4f43-a5f5-fac08c55a7b9", > "when": "20211014120305Z", > "duration": "0.392689", > "kw": { > "key": "DSREPLLE0002", > "items": [ > "Replication", > "Conflict Entries" > ], > "msg": "There were 1 conflict entries found under the replication s= uffix \"dc=3Dpipebreaker,dc=3Dpl\"." > } > = > Not much actionable info here. > = > = > = > { > "source": "ipahealthcheck.ipa.certs", > "check": "IPACertTracking", > "result": "WARNING", > "uuid": "e4a545a3-ad22-4b8e-b4f0-70287eae98a9", > "when": "20211014120309Z", > "duration": "2.828753", > "kw": { > "key": "20141107202922", > "msg": "certmonger tracking request {key} found and is not expected= on an IPA master." > } > }, > = > = > $ getcert list -i 20141107202922 > Number of certificates and requests being tracked: 10. > Request ID '20141107202922': > status: MONITORING > stuck: no > key pair storage: type=3DFILE,location=3D'/etc/pki/tls/private/kaitain.p= ipebreaker.pl.key' > certificate: type=3DFILE,location=3D'/etc/pki/tls/certs/kaitain.pipebrea= ker.pl.crt' > CA: IPA > issuer: CN=3DCertificate Authority,O=3DPIPEBREAKER.PL > subject: CN=3Dkaitain.pipebreaker.pl,O=3DPIPEBREAKER.PL > issued: 2020-08-24 06:23:58 CEST > expires: 2022-08-25 06:23:58 CEST > dns: kaitain.pipebreaker.pl > principal name: host/kaitain.pipebreaker.pl(a)PIPEBREAKER.PL > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherm= ent > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: = > post-save command: = > track: yes > auto-renew: yes > = > Looks fine, I have this cert/key configured in systemd-journal-upload ser= vice, > this is not a part of FreeIPA. > = > = > = > = > { > "source": "ipahealthcheck.ipa.certs", > "check": "IPACertDNSSAN", > "result": "ERROR", > "uuid": "87699232-f56d-47e4-802b-afab4f1d1b9b", > "when": "20211014120312Z", > "duration": "2.300274", > "kw": { > "key": "20200624045303", > "hostname": "kaitain.pipebreaker.pl", > "san": [], > "ca": "IPA", > "profile": "caIPAserviceCert", > "msg": "Certificate request id {key} with profile {profile} for CA = {ca} does not have a DNS SAN {san} matching name {hostname}" > } > } > ] > = > = > $ getcert list -i 20200624045303 > Number of certificates and requests being tracked: 10. > Request ID '20200624045303': > status: MONITORING > stuck: no > key pair storage: type=3DNSSDB,location=3D'/etc/dirsrv/slapd-PIPEBREAKER= -PL',nickname=3D'Server-Cert',token=3D'NSS Certificate DB',pinfile=3D'/etc/= dirsrv/slapd-PIPEBREAKER-PL/pwdfile.txt' > certificate: type=3DNSSDB,location=3D'/etc/dirsrv/slapd-PIPEBREAKER-PL',= nickname=3D'Server-Cert',token=3D'NSS Certificate DB' > CA: IPA > issuer: CN=3DCertificate Authority,O=3DPIPEBREAKER.PL > subject: CN=3Dkaitain.pipebreaker.pl,O=3DPIPEBREAKER.PL > issued: 2021-08-18 14:27:32 CEST > expires: 2023-08-19 14:27:32 CEST > principal name: ldap/kaitain.pipebreaker.pl(a)PIPEBREAKER.PL > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherm= ent > eku: id-kp-serverAuth,id-kp-clientAuth > profile: caIPAserviceCert > pre-save command: = > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv PIPEBREAKE= R-PL > track: yes > auto-renew: y > = > Also looks fine, SAN requirement in certificates only appeared few years = ago, after > this particular server was installed. I doubt it is even used in context= of LDAP connection. > = >> Does the RA cert work in other contexts? Does ipa cert-find work? Can >> you request a test certificate? > = > It looks so: > = > root(a)kaitain ~$ ipa cert-find > ipa: ERROR: did not receive Kerberos credentials > = > root(a)kaitain ~$ kinit admin > Password for admin(a)PIPEBREAKER.PL: = > = > root(a)kaitain ~$ ipa cert-find > ipa: WARNING: Search result has been truncated: Configured size limit exc= eeded > ------------------------ > 100 certificates matched > ------------------------ > [ =E2=80=A6 hundred certificates listed =E2=80=A6 ] > = > When I check in WebUI I see that latest certificate was > Issued On > Tue Oct 05 20:27:05 2021 UTC > = > So it worked last week. > = > What would be next step? > = So this shows that the RA certificate is fine. It looks like a group permission issue within the CA that the RA is not allowed to perform ACME actions. Some things to check: - uid=3Dacme-,ou=3Dpeople,o=3Dipaca and uid=3Dipara,ou=3DPeople,o=3Dipaca are both uniqueMember attributes of cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca - the entry id=3Dacme-,ou=3Dpeople,o=3Dipaca exists - In cn=3DaclResources,o=3Dipaca there is the value: resourceACLS: certServer.ca.certs:execute:allow (execute) group=3D"Enterprise ACME Administrators":ACME Agents may execute cert operations rob --===============6134741517445722082==-- From tomek at pipebreaker.pl Wed Oct 20 13:12:36 2021 Content-Type: multipart/mixed; boundary="===============2798272730349625477==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Wed, 20 Oct 2021 15:12:17 +0200 Message-ID: In-Reply-To: be3a3c7b-652b-7938-6136-d59c07d69f27@redhat.com --===============2798272730349625477== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Oct 15, 2021 at 02:04:42PM -0400, Rob Crittenden via FreeIPA-users = wrote: > Tomasz Torcz via FreeIPA-users wrote: > > On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-us= ers wrote: > >> Tomasz Torcz via FreeIPA-users wrote: > >>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-us= ers wrote: > >>>> $ ipa-acme-manage enable > >>>> Failed to authenticate to CA REST API > >>>> The ipa-acme-manage command failed. > >>> = > >>> No ideas how to proceed? > >>> Most troubleshooting guides end at comparing certs on the filesystem = and > >>> in LDAP. What's the next step? > > = > = > So this shows that the RA certificate is fine. It looks like a group > permission issue within the CA that the RA is not allowed to perform > ACME actions. > = > Some things to check: > = All below seem to be correct: > - uid=3Dacme-,ou=3Dpeople,o=3Dipaca and > uid=3Dipara,ou=3DPeople,o=3Dipaca are both uniqueMember attributes of > cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca # base with sco= pe # subtree # filter: (objectclass=3D*) # requesting: uniqueMember = # # Enterprise ACME Administrators, groups, ipaca dn: cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca uniqueMember: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca uniqueMember: uid=3Dipara,ou=3Dpeople,o=3Dipaca uniqueMember: uid=3Dacme-okda.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > - the entry id=3Dacme-,ou=3Dpeople,o=3Dipaca exists There is no entry with id=3D, but there is one with uid=3D (I assume you made a typo): # acme-kaitain.pipebreaker.pl, people, ipaca dn: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser uid: acme-kaitain.pipebreaker.pl cn: acme-kaitain.pipebreaker.pl sn: acme-kaitain.pipebreaker.pl usertype: agentType userstate: 1 userPassword:: =E2=80=A6 > - In cn=3DaclResources,o=3Dipaca there is the value: > resourceACLS: certServer.ca.certs:execute:allow (execute) > group=3D"Enterprise ACME Administrators":ACME Agents may execute cert > operations $ ldapsrch -b cn=3DaclResources,o=3Dipaca resourceACLs | grep ACME Enter LDAP Password: resourceACLs: certServer.ca.certs:execute:allow (execute) group=3D"Enterpri= se ACME Administrators":ACME Agents may execute cert operations So everything looks to be in order. Maybe there is a way to increase logging in com.netscape.cms.tomcat.Abstr= actPKIAuthenticator.doAuthenticate PKIAuthenticator ? -- = Tomasz Torcz Once you've read the dictionary, @ttorcz:pipebreaker.pl every other book is just a remix. --===============2798272730349625477==-- From rcritten at redhat.com Wed Oct 20 14:27:28 2021 Content-Type: multipart/mixed; boundary="===============4970399414236401040==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Wed, 20 Oct 2021 10:27:04 -0400 Message-ID: <6c9141e4-ccb9-6715-be69-03c911593b0a@redhat.com> In-Reply-To: YXAVsRFtYj9CcdON@mother.pipebreaker.pl --===============4970399414236401040== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Fri, Oct 15, 2021 at 02:04:42PM -0400, Rob Crittenden via FreeIPA-user= s wrote: >> Tomasz Torcz via FreeIPA-users wrote: >>> On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via FreeIPA-us= ers wrote: >>>> Tomasz Torcz via FreeIPA-users wrote: >>>>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via FreeIPA-us= ers wrote: >>>>>> $ ipa-acme-manage enable >>>>>> Failed to authenticate to CA REST API >>>>>> The ipa-acme-manage command failed. >>>>> = >>>>> No ideas how to proceed? >>>>> Most troubleshooting guides end at comparing certs on the filesystem = and >>>>> in LDAP. What's the next step? >>> >> >> So this shows that the RA certificate is fine. It looks like a group >> permission issue within the CA that the RA is not allowed to perform >> ACME actions. >> >> Some things to check: >> > = > All below seem to be correct: > = >> - uid=3Dacme-,ou=3Dpeople,o=3Dipaca and >> uid=3Dipara,ou=3DPeople,o=3Dipaca are both uniqueMember attributes of >> cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca > = > # base with s= cope > # subtree > # filter: (objectclass=3D*) > # requesting: uniqueMember = > # > = > # Enterprise ACME Administrators, groups, ipaca > dn: cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca > uniqueMember: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > uniqueMember: uid=3Dipara,ou=3Dpeople,o=3Dipaca > uniqueMember: uid=3Dacme-okda.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > = > = > = >> - the entry id=3Dacme-,ou=3Dpeople,o=3Dipaca exists > = > There is no entry with id=3D, but there is one with uid=3D (I assume you > made a typo): > = > # acme-kaitain.pipebreaker.pl, people, ipaca > dn: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: cmsuser > uid: acme-kaitain.pipebreaker.pl > cn: acme-kaitain.pipebreaker.pl > sn: acme-kaitain.pipebreaker.pl > usertype: agentType > userstate: 1 > userPassword:: =E2=80=A6 > = > = >> - In cn=3DaclResources,o=3Dipaca there is the value: >> resourceACLS: certServer.ca.certs:execute:allow (execute) >> group=3D"Enterprise ACME Administrators":ACME Agents may execute cert >> operations > = > $ ldapsrch -b cn=3DaclResources,o=3Dipaca resourceACLs | grep ACME > Enter LDAP Password: > resourceACLs: certServer.ca.certs:execute:allow (execute) group=3D"Enterp= rise ACME Administrators":ACME Agents may execute cert operations > = > So everything looks to be in order. > Maybe there is a way to increase logging in com.netscape.cms.tomcat.Abs= tractPKIAuthenticator.doAuthenticate PKIAuthenticator ? > = I don't know. Endi, what would you suggest here? thanks rob --===============4970399414236401040==-- From edewata at redhat.com Thu Oct 21 01:41:01 2021 Content-Type: multipart/mixed; boundary="===============8519182019301895213==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Wed, 20 Oct 2021 20:40:30 -0500 Message-ID: In-Reply-To: 6c9141e4-ccb9-6715-be69-03c911593b0a@redhat.com --===============8519182019301895213== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I think error 401 means that the client cert could not be mapped to the user in DS. Could you check the uid=3Dipara,ou=3Dpeople,o=3Dipaca to make sure that the userCertificate and the description attributes contain the right certificate? You can also try setting the log level to INFO or FINE to see the authentication process on the server side: https://github.com/dogtagpki/pki/wiki/Configuring-Server-Logging -- = Endi S. Dewata On Wed, Oct 20, 2021 at 9:27 AM Rob Crittenden wrot= e: > Tomasz Torcz via FreeIPA-users wrote: > > On Fri, Oct 15, 2021 at 02:04:42PM -0400, Rob Crittenden via > FreeIPA-users wrote: > >> Tomasz Torcz via FreeIPA-users wrote: > >>> On Tue, Oct 12, 2021 at 02:33:01PM -0400, Rob Crittenden via > FreeIPA-users wrote: > >>>> Tomasz Torcz via FreeIPA-users wrote: > >>>>> On Sat, Oct 02, 2021 at 04:38:34PM +0200, Tomasz Torcz via > FreeIPA-users wrote: > >>>>>> $ ipa-acme-manage enable > >>>>>> Failed to authenticate to CA REST API > >>>>>> The ipa-acme-manage command failed. > >>>>> > >>>>> No ideas how to proceed? > >>>>> Most troubleshooting guides end at comparing certs on the filesystem > and > >>>>> in LDAP. What's the next step? > >>> > >> > >> So this shows that the RA certificate is fine. It looks like a group > >> permission issue within the CA that the RA is not allowed to perform > >> ACME actions. > >> > >> Some things to check: > >> > > > > All below seem to be correct: > > > >> - uid=3Dacme-,ou=3Dpeople,o=3Dipaca and > >> uid=3Dipara,ou=3DPeople,o=3Dipaca are both uniqueMember attributes of > >> cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca > > > > # base with= scope > > # subtree > > # filter: (objectclass=3D*) > > # requesting: uniqueMember > > # > > > > # Enterprise ACME Administrators, groups, ipaca > > dn: cn=3DEnterprise ACME Administrators,ou=3Dgroups,o=3Dipaca > > uniqueMember: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > > uniqueMember: uid=3Dipara,ou=3Dpeople,o=3Dipaca > > uniqueMember: uid=3Dacme-okda.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > > > > > > > >> - the entry id=3Dacme-,ou=3Dpeople,o=3Dipaca exis= ts > > > > There is no entry with id=3D, but there is one with uid=3D (I assume y= ou > > made a typo): > > > > # acme-kaitain.pipebreaker.pl, people, ipaca > > dn: uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeople,o=3Dipaca > > objectClass: top > > objectClass: person > > objectClass: organizationalPerson > > objectClass: inetOrgPerson > > objectClass: cmsuser > > uid: acme-kaitain.pipebreaker.pl > > cn: acme-kaitain.pipebreaker.pl > > sn: acme-kaitain.pipebreaker.pl > > usertype: agentType > > userstate: 1 > > userPassword:: =E2=80=A6 > > > > > >> - In cn=3DaclResources,o=3Dipaca there is the value: > >> resourceACLS: certServer.ca.certs:execute:allow (execute) > >> group=3D"Enterprise ACME Administrators":ACME Agents may execute cert > >> operations > > > > $ ldapsrch -b cn=3DaclResources,o=3Dipaca resourceACLs | grep ACME > > Enter LDAP Password: > > resourceACLs: certServer.ca.certs:execute:allow (execute) > group=3D"Enterprise ACME Administrators":ACME Agents may execute cert > operations > > > > So everything looks to be in order. > > Maybe there is a way to increase logging in > com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate > PKIAuthenticator ? > > > > I don't know. Endi, what would you suggest here? > > thanks > > rob > > --===============8519182019301895213== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdj5IaSw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgdGhpbmsg ZXJyb3IgNDAxIG1lYW5zIHRoYXQgdGhlIGNsaWVudCBjZXJ0IGNvdWxkIG5vdCBiZSBtYXBwZWQ8 L2Rpdj48ZGl2PnRvIHRoZSB1c2VyIGluIERTLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q291 bGQgeW91IGNoZWNrIHRoZSB1aWQ9aXBhcmEsb3U9cGVvcGxlLG89aXBhY2EgdG8gbWFrZSBzdXJl PC9kaXY+PGRpdj50aGF0IHRoZSB1c2VyQ2VydGlmaWNhdGUgYW5kIHRoZSBkZXNjcmlwdGlvbiBh dHRyaWJ1dGVzIGNvbnRhaW4gdGhlPC9kaXY+PGRpdj5yaWdodCBjZXJ0aWZpY2F0ZT88L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PllvdSBjYW4gYWxzbyB0cnkgc2V0dGluZyB0aGUgbG9nIGxldmVs IHRvIElORk8gb3IgRklORSB0byBzZWUgdGhlPC9kaXY+PGRpdj5hdXRoZW50aWNhdGlvbiBwcm9j ZXNzIG9uIHRoZSBzZXJ2ZXIgc2lkZTo8L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9kb2d0YWdwa2kvcGtpL3dpa2kvQ29uZmlndXJpbmctU2VydmVyLUxvZ2dpbmciPmh0dHBz Oi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL3dpa2kvQ29uZmlndXJpbmctU2VydmVyLUxvZ2dp bmc8L2E+PC9kaXY+PGJyPi0tIDxicj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0 dXJlIj48ZGl2IGRpcj0ibHRyIj48ZGl2PkVuZGkgUy4gRGV3YXRhPC9kaXY+PGRpdj48YnI+PC9k aXY+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBXZWQsIE9jdCAyMCwgMjAyMSBhdCA5OjI3IEFNIFJvYiBDcml0 dGVuZGVuICZsdDs8YSBocmVmPSJtYWlsdG86cmNyaXR0ZW5AcmVkaGF0LmNvbSI+cmNyaXR0ZW5A cmVkaGF0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+VG9tYXN6IFRvcmN6IHZp YSBGcmVlSVBBLXVzZXJzIHdyb3RlOjxicj4KJmd0OyBPbiBGcmksIE9jdCAxNSwgMjAyMSBhdCAw MjowNDo0MlBNIC0wNDAwLCBSb2IgQ3JpdHRlbmRlbiB2aWEgRnJlZUlQQS11c2VycyB3cm90ZTo8 YnI+CiZndDsmZ3Q7IFRvbWFzeiBUb3JjeiB2aWEgRnJlZUlQQS11c2VycyB3cm90ZTo8YnI+CiZn dDsmZ3Q7Jmd0OyBPbiBUdWUsIE9jdCAxMiwgMjAyMSBhdCAwMjozMzowMVBNIC0wNDAwLCBSb2Ig Q3JpdHRlbmRlbiB2aWEgRnJlZUlQQS11c2VycyB3cm90ZTo8YnI+CiZndDsmZ3Q7Jmd0OyZndDsg VG9tYXN6IFRvcmN6IHZpYSBGcmVlSVBBLXVzZXJzIHdyb3RlOjxicj4KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgT24gU2F0LCBPY3QgMDIsIDIwMjEgYXQgMDQ6Mzg6MzRQTSArMDIwMCwgVG9tYXN6IFRv cmN6IHZpYSBGcmVlSVBBLXVzZXJzIHdyb3RlOjxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICQgaXBhLWFjbWUtbWFuYWdlIGVuYWJsZTxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZh aWxlZCB0byBhdXRoZW50aWNhdGUgdG8gQ0EgUkVTVCBBUEk8YnI+CiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUaGUgaXBhLWFjbWUtbWFuYWdlIGNvbW1hbmQgZmFpbGVkLjxicj4KJmd0OyZndDsm Z3Q7Jmd0OyZndDvCoCA8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqBObyBpZGVhcyBob3cg dG8gcHJvY2VlZD88YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1vc3QgdHJvdWJsZXNob290aW5n IGd1aWRlcyBlbmQgYXQgY29tcGFyaW5nIGNlcnRzIG9uIHRoZSBmaWxlc3lzdGVtIGFuZDxicj4K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gTERBUC4gV2hhdCYjMzk7cyB0aGUgbmV4dCBzdGVwPzxi cj4KJmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgU28gdGhpcyBzaG93cyB0 aGF0IHRoZSBSQSBjZXJ0aWZpY2F0ZSBpcyBmaW5lLiBJdCBsb29rcyBsaWtlIGEgZ3JvdXA8YnI+ CiZndDsmZ3Q7IHBlcm1pc3Npb24gaXNzdWUgd2l0aGluIHRoZSBDQSB0aGF0IHRoZSBSQSBpcyBu b3QgYWxsb3dlZCB0byBwZXJmb3JtPGJyPgomZ3Q7Jmd0OyBBQ01FIGFjdGlvbnMuPGJyPgomZ3Q7 Jmd0Ozxicj4KJmd0OyZndDsgU29tZSB0aGluZ3MgdG8gY2hlY2s6PGJyPgomZ3Q7Jmd0Ozxicj4K Jmd0OyA8YnI+CiZndDvCoCBBbGwgYmVsb3cgc2VlbSB0byBiZSBjb3JyZWN0Ojxicj4KJmd0OyA8 YnI+CiZndDsmZ3Q7IC0gdWlkPWFjbWUtJmx0O0lQQSBTRVJWRVIgSE9TVE5BTUUmZ3Q7LG91PXBl b3BsZSxvPWlwYWNhIGFuZDxicj4KJmd0OyZndDsgdWlkPWlwYXJhLG91PVBlb3BsZSxvPWlwYWNh IGFyZSBib3RoIHVuaXF1ZU1lbWJlciBhdHRyaWJ1dGVzIG9mPGJyPgomZ3Q7Jmd0OyBjbj1FbnRl cnByaXNlIEFDTUUgQWRtaW5pc3RyYXRvcnMsb3U9Z3JvdXBzLG89aXBhY2E8YnI+CiZndDsgPGJy PgomZ3Q7ICMgYmFzZSAmbHQ7Y249RW50ZXJwcmlzZSBBQ01FIEFkbWluaXN0cmF0b3JzLG91PWdy b3VwcyxvPWlwYWNhJmd0OyB3aXRoIHNjb3BlPGJyPgomZ3Q7ICMgc3VidHJlZTxicj4KJmd0OyAj IGZpbHRlcjogKG9iamVjdGNsYXNzPSopPGJyPgomZ3Q7ICMgcmVxdWVzdGluZzogdW5pcXVlTWVt YmVyIDxicj4KJmd0OyAjPGJyPgomZ3Q7IDxicj4KJmd0OyAjIEVudGVycHJpc2UgQUNNRSBBZG1p bmlzdHJhdG9ycywgZ3JvdXBzLCBpcGFjYTxicj4KJmd0OyBkbjogY249RW50ZXJwcmlzZSBBQ01F IEFkbWluaXN0cmF0b3JzLG91PWdyb3VwcyxvPWlwYWNhPGJyPgomZ3Q7IHVuaXF1ZU1lbWJlcjog dWlkPTxhIGhyZWY9Imh0dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbDwvYT4s b3U9cGVvcGxlLG89aXBhY2E8YnI+CiZndDsgdW5pcXVlTWVtYmVyOiB1aWQ9aXBhcmEsb3U9cGVv cGxlLG89aXBhY2E8YnI+CiZndDsgdW5pcXVlTWVtYmVyOiB1aWQ9PGEgaHJlZj0iaHR0cDovL2Fj bWUtb2tkYS5waXBlYnJlYWtlci5wbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ YWNtZS1va2RhLnBpcGVicmVha2VyLnBsPC9hPixvdT1wZW9wbGUsbz1pcGFjYTxicj4KJmd0OyA8 YnI+CiZndDsgPGJyPgomZ3Q7IDxicj4KJmd0OyZndDsgLSB0aGUgZW50cnkgaWQ9YWNtZS0mbHQ7 SVBBIFNFUlZFUiBIT1NUTkFNRSZndDssb3U9cGVvcGxlLG89aXBhY2EgZXhpc3RzPGJyPgomZ3Q7 IDxicj4KJmd0O8KgIFRoZXJlIGlzIG5vIGVudHJ5IHdpdGggaWQ9LCBidXQgdGhlcmUgaXMgb25l IHdpdGggdWlkPSAoSSBhc3N1bWUgeW91PGJyPgomZ3Q7IG1hZGUgYSB0eXBvKTo8YnI+CiZndDsg PGJyPgomZ3Q7ICMgPGEgaHJlZj0iaHR0cDovL2FjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbCIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+YWNtZS1rYWl0YWluLnBpcGVicmVha2Vy LnBsPC9hPiwgcGVvcGxlLCBpcGFjYTxicj4KJmd0OyBkbjogdWlkPTxhIGhyZWY9Imh0dHA6Ly9h Y21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbDwvYT4sb3U9cGVvcGxlLG89aXBhY2E8YnI+ CiZndDsgb2JqZWN0Q2xhc3M6IHRvcDxicj4KJmd0OyBvYmplY3RDbGFzczogcGVyc29uPGJyPgom Z3Q7IG9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFBlcnNvbjxicj4KJmd0OyBvYmplY3RDbGFz czogaW5ldE9yZ1BlcnNvbjxicj4KJmd0OyBvYmplY3RDbGFzczogY21zdXNlcjxicj4KJmd0OyB1 aWQ6IDxhIGhyZWY9Imh0dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbDwvYT48 YnI+CiZndDsgY246IDxhIGhyZWY9Imh0dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtl ci5wbDwvYT48YnI+CiZndDsgc246IDxhIGhyZWY9Imh0dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJy ZWFrZXIucGwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5w aXBlYnJlYWtlci5wbDwvYT48YnI+CiZndDsgdXNlcnR5cGU6IGFnZW50VHlwZTxicj4KJmd0OyB1 c2Vyc3RhdGU6IDE8YnI+CiZndDsgdXNlclBhc3N3b3JkOjog4oCmPGJyPgomZ3Q7IDxicj4KJmd0 OyA8YnI+CiZndDsmZ3Q7IC0gSW4gY249YWNsUmVzb3VyY2VzLG89aXBhY2EgdGhlcmUgaXMgdGhl IHZhbHVlOjxicj4KJmd0OyZndDsgcmVzb3VyY2VBQ0xTOiBjZXJ0U2VydmVyLmNhLmNlcnRzOmV4 ZWN1dGU6YWxsb3cgKGV4ZWN1dGUpPGJyPgomZ3Q7Jmd0OyBncm91cD0mcXVvdDtFbnRlcnByaXNl IEFDTUUgQWRtaW5pc3RyYXRvcnMmcXVvdDs6QUNNRSBBZ2VudHMgbWF5IGV4ZWN1dGUgY2VydDxi cj4KJmd0OyZndDsgb3BlcmF0aW9uczxicj4KJmd0OyA8YnI+CiZndDsgJCBsZGFwc3JjaCAtYiBj bj1hY2xSZXNvdXJjZXMsbz1pcGFjYSByZXNvdXJjZUFDTHMgfCBncmVwIEFDTUU8YnI+CiZndDsg RW50ZXIgTERBUCBQYXNzd29yZDo8YnI+CiZndDsgcmVzb3VyY2VBQ0xzOiBjZXJ0U2VydmVyLmNh LmNlcnRzOmV4ZWN1dGU6YWxsb3cgKGV4ZWN1dGUpIGdyb3VwPSZxdW90O0VudGVycHJpc2UgQUNN RSBBZG1pbmlzdHJhdG9ycyZxdW90OzpBQ01FIEFnZW50cyBtYXkgZXhlY3V0ZSBjZXJ0IG9wZXJh dGlvbnM8YnI+CiZndDsgPGJyPgomZ3Q7wqAgwqBTbyBldmVyeXRoaW5nIGxvb2tzIHRvIGJlIGlu IG9yZGVyLjxicj4KJmd0O8KgIMKgTWF5YmUgdGhlcmUgaXMgYSB3YXkgdG8gaW5jcmVhc2UgbG9n Z2luZyBpbiBjb20ubmV0c2NhcGUuY21zLnRvbWNhdC5BYnN0cmFjdFBLSUF1dGhlbnRpY2F0b3Iu ZG9BdXRoZW50aWNhdGUgUEtJQXV0aGVudGljYXRvciA/PGJyPgomZ3Q7IDxicj4KPGJyPgpJIGRv biYjMzk7dCBrbm93LiBFbmRpLCB3aGF0IHdvdWxkIHlvdSBzdWdnZXN0IGhlcmU/PGJyPgo8YnI+ CnRoYW5rczxicj4KPGJyPgpyb2I8YnI+Cjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2PjxiciBjbGVh cj0iYWxsIj48YnI+PC9kaXY+Cg== --===============8519182019301895213==-- From tomek at pipebreaker.pl Thu Oct 21 10:34:00 2021 Content-Type: multipart/mixed; boundary="===============2323558934633572960==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 21 Oct 2021 12:33:45 +0200 Message-ID: In-Reply-To: CAMv3Fb71FVkstKMLHH+pMHgAt0TMnQ2VfBfsBV6WPtHTdR689A@mail.gmail.com --===============2323558934633572960== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2021 at 08:40:30PM -0500, Endi Dewata via FreeIPA-users wro= te: > Hi, > = > I think error 401 means that the client cert could not be mapped > to the user in DS. > = > Could you check the uid=3Dipara,ou=3Dpeople,o=3Dipaca to make sure > that the userCertificate and the description attributes contain the > right certificate? That was the first thing I've checked. userCertificate:: (after base64 decoding) is the same as /var/lib/ipa/ra-agent.pem - the same description, fingerprint, etc. openssl x509 -serial return "69" for both, and LDAP contains: description: 2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA R= A,O=3DPIPEBREAKER.PL 105 (dec) =3D=3D 69 (hex) so this is correct, too. > = > You can also try setting the log level to INFO or FINE to see the > authentication process on the server side: > https://github.com/dogtagpki/pki/wiki/Configuring-Server-Logging This is something! There are new lines between starting certificate authentication and returning failure. First I thought there are libraries missing, but in the end all finish with "Loading class from parent": FINE: Calling authenticate() INFO: PKIAuthenticator: Authenticate with client certificate authentication INFO: Authenticating certificate chain: INFO: - CN=3DIPA RA,O=3DPIPEBREAKER.PL INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL FINE: loadClass(org.mozilla.jss.netscape.security.util.Cert, false) FINE: Searching local repositories FINE: findClass(org.mozilla.jss.netscape.security.util.Cert) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader(a)= 5fcfe4b2 FINE: Loading class from parent FINE: loadClass(netscape.ldap.LDAPSearchResults, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPSearchResults) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader(a)= 5fcfe4b2 FINE: Loading class from parent FINE: loadClass(netscape.ldap.LDAPEntry, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPEntry) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader(a)= 5fcfe4b2 FINE: Loading class from parent FINE: loadClass(com.netscape.cmscore.usrgrp.User, false) FINE: Searching local repositories FINE: findClass(com.netscape.cmscore.usrgrp.User) FINE: Loading class from local repository FINE: loadClass(netscape.ldap.LDAPAttribute, false) FINE: Searching local repositories FINE: findClass(netscape.ldap.LDAPAttribute) FINE: --> Returning ClassNotFoundException FINE: Delegating to parent classloader at end: java.net.URLClassLoader(a)= 5fcfe4b2 FINE: Loading class from parent INFO: PKIAuthenticator: Result: false FINE: Failed authenticate() test Second invocation of "pki-acme-manage status" do not generate those class = messages: FINE: Calling hasUserDataPermission() FINE: User data constraint already satisfied FINE: Calling authenticate() INFO: PKIAuthenticator: Authenticate with client certificate authentication INFO: Authenticating certificate chain: INFO: - CN=3DIPA RA,O=3DPIPEBREAKER.PL INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL INFO: PKIAuthenticator: Result: false FINE: Failed authenticate() test FINE: JSSEngine: wrap(ssl_fd=3Dorg.mozilla.jss.nss.SSLFDProxy[1522605810(a)= 00079ea974550000]) -- = Tomasz Torcz Once you've read the dictionary, @ttorcz:pipebreaker.pl every other book is just a remix. --===============2323558934633572960==-- From edewata at redhat.com Thu Oct 21 17:45:18 2021 Content-Type: multipart/mixed; boundary="===============6086613702021397200==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 21 Oct 2021 12:44:44 -0500 Message-ID: In-Reply-To: YXFCCd1gE2pPgXr1@mother.pipebreaker.pl --===============6086613702021397200== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2021 at 5:36 AM Tomasz Torcz via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > On Wed, Oct 20, 2021 at 08:40:30PM -0500, Endi Dewata via FreeIPA-users > wrote: > > Hi, > > > > I think error 401 means that the client cert could not be mapped > > to the user in DS. > > > > Could you check the uid=3Dipara,ou=3Dpeople,o=3Dipaca to make sure > > that the userCertificate and the description attributes contain the > > right certificate? > > That was the first thing I've checked. userCertificate:: (after base64 > decoding) is the same as /var/lib/ipa/ra-agent.pem - the same > description, fingerprint, etc. openssl x509 -serial return "69" for > both, and LDAP contains: > description: 2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA= RA,O=3D > PIPEBREAKER.PL > > 105 (dec) =3D=3D 69 (hex) so this is correct, too. > > > > > You can also try setting the log level to INFO or FINE to see the > > authentication process on the server side: > > https://github.com/dogtagpki/pki/wiki/Configuring-Server-Logging > > This is something! There are new lines between starting certificate > authentication and returning failure. First I thought there are libraries > missing, but in the end all finish with "Loading class from parent": > > FINE: Calling authenticate() > INFO: PKIAuthenticator: Authenticate with client certificate authenticati= on > INFO: Authenticating certificate chain: > INFO: - CN=3DIPA RA,O=3DPIPEBREAKER.PL > INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL > FINE: loadClass(org.mozilla.jss.netscape.security.util.Cert, false) > FINE: Searching local repositories > FINE: findClass(org.mozilla.jss.netscape.security.util.Cert) > FINE: --> Returning ClassNotFoundException > FINE: Delegating to parent classloader at end: > java.net.URLClassLoader(a)5fcfe4b2 > FINE: Loading class from parent > FINE: loadClass(netscape.ldap.LDAPSearchResults, false) > FINE: Searching local repositories > FINE: findClass(netscape.ldap.LDAPSearchResults) > FINE: --> Returning ClassNotFoundException > FINE: Delegating to parent classloader at end: > java.net.URLClassLoader(a)5fcfe4b2 > FINE: Loading class from parent > FINE: loadClass(netscape.ldap.LDAPEntry, false) > FINE: Searching local repositories > FINE: findClass(netscape.ldap.LDAPEntry) > FINE: --> Returning ClassNotFoundException > FINE: Delegating to parent classloader at end: > java.net.URLClassLoader(a)5fcfe4b2 > FINE: Loading class from parent > FINE: loadClass(com.netscape.cmscore.usrgrp.User, false) > FINE: Searching local repositories > FINE: findClass(com.netscape.cmscore.usrgrp.User) > FINE: Loading class from local repository > FINE: loadClass(netscape.ldap.LDAPAttribute, false) > FINE: Searching local repositories > FINE: findClass(netscape.ldap.LDAPAttribute) > FINE: --> Returning ClassNotFoundException > FINE: Delegating to parent classloader at end: > java.net.URLClassLoader(a)5fcfe4b2 > FINE: Loading class from parent > INFO: PKIAuthenticator: Result: false > FINE: Failed authenticate() test > > > Second invocation of "pki-acme-manage status" do not generate those class > messages: > > FINE: Calling hasUserDataPermission() > FINE: User data constraint already satisfied > FINE: Calling authenticate() > INFO: PKIAuthenticator: Authenticate with client certificate authenticati= on > INFO: Authenticating certificate chain: > INFO: - CN=3DIPA RA,O=3DPIPEBREAKER.PL > INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL > INFO: PKIAuthenticator: Result: false > FINE: Failed authenticate() test > FINE: JSSEngine: > wrap(ssl_fd=3Dorg.mozilla.jss.nss.SSLFDProxy[1522605810(a)00079ea97455000= 0]) > 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. -- = Endi S. Dewata --===============6086613702021397200== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIE9jdCAyMSwgMjAyMSBhdCA1OjM2IEFNIFRvbWFzeiBU b3JjeiB2aWEgRnJlZUlQQS11c2VycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWVpcGEtdXNlcnNA bGlzdHMuZmVkb3JhaG9zdGVkLm9yZyI+ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQu b3JnPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQg cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij5PbiBXZWQsIE9jdCAyMCwgMjAyMSBh dCAwODo0MDozMFBNIC0wNTAwLCBFbmRpIERld2F0YSB2aWEgRnJlZUlQQS11c2VycyB3cm90ZTo8 YnI+CiZndDsgSGksPGJyPgomZ3Q7IDxicj4KJmd0OyBJIHRoaW5rIGVycm9yIDQwMSBtZWFucyB0 aGF0IHRoZSBjbGllbnQgY2VydCBjb3VsZCBub3QgYmUgbWFwcGVkPGJyPgomZ3Q7IHRvIHRoZSB1 c2VyIGluIERTLjxicj4KJmd0OyA8YnI+CiZndDsgQ291bGQgeW91IGNoZWNrIHRoZSB1aWQ9aXBh cmEsb3U9cGVvcGxlLG89aXBhY2EgdG8gbWFrZSBzdXJlPGJyPgomZ3Q7IHRoYXQgdGhlIHVzZXJD ZXJ0aWZpY2F0ZSBhbmQgdGhlIGRlc2NyaXB0aW9uIGF0dHJpYnV0ZXMgY29udGFpbiB0aGU8YnI+ CiZndDsgcmlnaHQgY2VydGlmaWNhdGU/PGJyPgo8YnI+CsKgIFRoYXQgd2FzIHRoZSBmaXJzdCB0 aGluZyBJJiMzOTt2ZSBjaGVja2VkLiB1c2VyQ2VydGlmaWNhdGU6OiAoYWZ0ZXIgYmFzZTY0PGJy PgpkZWNvZGluZykgaXMgdGhlIHNhbWUgYXMgL3Zhci9saWIvaXBhL3JhLWFnZW50LnBlbSAtIHRo ZSBzYW1lPGJyPgpkZXNjcmlwdGlvbiwgZmluZ2VycHJpbnQsIGV0Yy4gb3BlbnNzbCB4NTA5IC1z ZXJpYWwgcmV0dXJuICZxdW90OzY5JnF1b3Q7IGZvcjxicj4KYm90aCwgYW5kIExEQVAgY29udGFp bnM6PGJyPgpkZXNjcmlwdGlvbjogMjsxMDU7Q049Q2VydGlmaWNhdGUgQXV0aG9yaXR5LE89PGEg aHJlZj0iaHR0cDovL1BJUEVCUkVBS0VSLlBMIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5QSVBFQlJFQUtFUi5QTDwvYT47Q049SVBBIFJBLE89PGEgaHJlZj0iaHR0cDovL1BJUEVC UkVBS0VSLlBMIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5QSVBFQlJFQUtFUi5Q TDwvYT48YnI+Cjxicj4KMTA1IChkZWMpID09IDY5IChoZXgpIHNvIHRoaXMgaXMgY29ycmVjdCwg dG9vLjxicj4KPGJyPgomZ3Q7IDxicj4KJmd0OyBZb3UgY2FuIGFsc28gdHJ5IHNldHRpbmcgdGhl IGxvZyBsZXZlbCB0byBJTkZPIG9yIEZJTkUgdG8gc2VlIHRoZTxicj4KJmd0OyBhdXRoZW50aWNh dGlvbiBwcm9jZXNzIG9uIHRoZSBzZXJ2ZXIgc2lkZTo8YnI+CiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvd2lraS9Db25maWd1cmluZy1TZXJ2ZXItTG9nZ2lu ZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2Rv Z3RhZ3BraS9wa2kvd2lraS9Db25maWd1cmluZy1TZXJ2ZXItTG9nZ2luZzwvYT48YnI+Cjxicj4K VGhpcyBpcyBzb21ldGhpbmchwqAgVGhlcmUgYXJlIG5ldyBsaW5lcyBiZXR3ZWVuIHN0YXJ0aW5n IGNlcnRpZmljYXRlPGJyPgphdXRoZW50aWNhdGlvbiBhbmQgcmV0dXJuaW5nIGZhaWx1cmUuIEZp cnN0IEkgdGhvdWdodCB0aGVyZSBhcmUgbGlicmFyaWVzPGJyPgptaXNzaW5nLCBidXQgaW4gdGhl IGVuZCBhbGwgZmluaXNoIHdpdGggJnF1b3Q7TG9hZGluZyBjbGFzcyBmcm9tIHBhcmVudCZxdW90 Ozo8YnI+Cjxicj4KRklORTogQ2FsbGluZyBhdXRoZW50aWNhdGUoKTxicj4KSU5GTzogUEtJQXV0 aGVudGljYXRvcjogQXV0aGVudGljYXRlIHdpdGggY2xpZW50IGNlcnRpZmljYXRlIGF1dGhlbnRp Y2F0aW9uPGJyPgpJTkZPOiBBdXRoZW50aWNhdGluZyBjZXJ0aWZpY2F0ZSBjaGFpbjo8YnI+CklO Rk86IC0gQ049SVBBIFJBLE89PGEgaHJlZj0iaHR0cDovL1BJUEVCUkVBS0VSLlBMIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5QSVBFQlJFQUtFUi5QTDwvYT48YnI+CklORk86IC0g Q049Q2VydGlmaWNhdGUgQXV0aG9yaXR5LE89PGEgaHJlZj0iaHR0cDovL1BJUEVCUkVBS0VSLlBM IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5QSVBFQlJFQUtFUi5QTDwvYT48YnI+ CkZJTkU6IGxvYWRDbGFzcyhvcmcubW96aWxsYS5qc3MubmV0c2NhcGUuc2VjdXJpdHkudXRpbC5D ZXJ0LCBmYWxzZSk8YnI+CkZJTkU6wqAgwqBTZWFyY2hpbmcgbG9jYWwgcmVwb3NpdG9yaWVzPGJy PgpGSU5FOsKgIMKgIMKgZmluZENsYXNzKG9yZy5tb3ppbGxhLmpzcy5uZXRzY2FwZS5zZWN1cml0 eS51dGlsLkNlcnQpPGJyPgpGSU5FOsKgIMKgIMKgLS0mZ3Q7IFJldHVybmluZyBDbGFzc05vdEZv dW5kRXhjZXB0aW9uPGJyPgpGSU5FOsKgIMKgRGVsZWdhdGluZyB0byBwYXJlbnQgY2xhc3Nsb2Fk ZXIgYXQgZW5kOiBqYXZhLm5ldC5VUkxDbGFzc0xvYWRlckA1ZmNmZTRiMjxicj4KRklORTrCoCDC oExvYWRpbmcgY2xhc3MgZnJvbSBwYXJlbnQ8YnI+CkZJTkU6IGxvYWRDbGFzcyhuZXRzY2FwZS5s ZGFwLkxEQVBTZWFyY2hSZXN1bHRzLCBmYWxzZSk8YnI+CkZJTkU6wqAgwqBTZWFyY2hpbmcgbG9j YWwgcmVwb3NpdG9yaWVzPGJyPgpGSU5FOsKgIMKgIMKgZmluZENsYXNzKG5ldHNjYXBlLmxkYXAu TERBUFNlYXJjaFJlc3VsdHMpPGJyPgpGSU5FOsKgIMKgIMKgLS0mZ3Q7IFJldHVybmluZyBDbGFz c05vdEZvdW5kRXhjZXB0aW9uPGJyPgpGSU5FOsKgIMKgRGVsZWdhdGluZyB0byBwYXJlbnQgY2xh c3Nsb2FkZXIgYXQgZW5kOiBqYXZhLm5ldC5VUkxDbGFzc0xvYWRlckA1ZmNmZTRiMjxicj4KRklO RTrCoCDCoExvYWRpbmcgY2xhc3MgZnJvbSBwYXJlbnQ8YnI+CkZJTkU6IGxvYWRDbGFzcyhuZXRz Y2FwZS5sZGFwLkxEQVBFbnRyeSwgZmFsc2UpPGJyPgpGSU5FOsKgIMKgU2VhcmNoaW5nIGxvY2Fs IHJlcG9zaXRvcmllczxicj4KRklORTrCoCDCoCDCoGZpbmRDbGFzcyhuZXRzY2FwZS5sZGFwLkxE QVBFbnRyeSk8YnI+CkZJTkU6wqAgwqAgwqAtLSZndDsgUmV0dXJuaW5nIENsYXNzTm90Rm91bmRF eGNlcHRpb248YnI+CkZJTkU6wqAgwqBEZWxlZ2F0aW5nIHRvIHBhcmVudCBjbGFzc2xvYWRlciBh dCBlbmQ6IGphdmEubmV0LlVSTENsYXNzTG9hZGVyQDVmY2ZlNGIyPGJyPgpGSU5FOsKgIMKgTG9h ZGluZyBjbGFzcyBmcm9tIHBhcmVudDxicj4KRklORTogbG9hZENsYXNzKGNvbS5uZXRzY2FwZS5j bXNjb3JlLnVzcmdycC5Vc2VyLCBmYWxzZSk8YnI+CkZJTkU6wqAgwqBTZWFyY2hpbmcgbG9jYWwg cmVwb3NpdG9yaWVzPGJyPgpGSU5FOsKgIMKgIMKgZmluZENsYXNzKGNvbS5uZXRzY2FwZS5jbXNj b3JlLnVzcmdycC5Vc2VyKTxicj4KRklORTrCoCDCoExvYWRpbmcgY2xhc3MgZnJvbSBsb2NhbCBy ZXBvc2l0b3J5PGJyPgpGSU5FOiBsb2FkQ2xhc3MobmV0c2NhcGUubGRhcC5MREFQQXR0cmlidXRl LCBmYWxzZSk8YnI+CkZJTkU6wqAgwqBTZWFyY2hpbmcgbG9jYWwgcmVwb3NpdG9yaWVzPGJyPgpG SU5FOsKgIMKgIMKgZmluZENsYXNzKG5ldHNjYXBlLmxkYXAuTERBUEF0dHJpYnV0ZSk8YnI+CkZJ TkU6wqAgwqAgwqAtLSZndDsgUmV0dXJuaW5nIENsYXNzTm90Rm91bmRFeGNlcHRpb248YnI+CkZJ TkU6wqAgwqBEZWxlZ2F0aW5nIHRvIHBhcmVudCBjbGFzc2xvYWRlciBhdCBlbmQ6IGphdmEubmV0 LlVSTENsYXNzTG9hZGVyQDVmY2ZlNGIyPGJyPgpGSU5FOsKgIMKgTG9hZGluZyBjbGFzcyBmcm9t IHBhcmVudDxicj4KSU5GTzogUEtJQXV0aGVudGljYXRvcjogUmVzdWx0OiBmYWxzZTxicj4KRklO RTogRmFpbGVkIGF1dGhlbnRpY2F0ZSgpIHRlc3Q8YnI+Cjxicj4KPGJyPgrCoFNlY29uZCBpbnZv Y2F0aW9uIG9mICZxdW90O3BraS1hY21lLW1hbmFnZSBzdGF0dXMmcXVvdDsgZG8gbm90IGdlbmVy YXRlIHRob3NlIGNsYXNzIG1lc3NhZ2VzOjxicj4KPGJyPgpGSU5FOiBDYWxsaW5nIGhhc1VzZXJE YXRhUGVybWlzc2lvbigpPGJyPgpGSU5FOsKgIMKgVXNlciBkYXRhIGNvbnN0cmFpbnQgYWxyZWFk eSBzYXRpc2ZpZWQ8YnI+CkZJTkU6IENhbGxpbmcgYXV0aGVudGljYXRlKCk8YnI+CklORk86IFBL SUF1dGhlbnRpY2F0b3I6IEF1dGhlbnRpY2F0ZSB3aXRoIGNsaWVudCBjZXJ0aWZpY2F0ZSBhdXRo ZW50aWNhdGlvbjxicj4KSU5GTzogQXV0aGVudGljYXRpbmcgY2VydGlmaWNhdGUgY2hhaW46PGJy PgpJTkZPOiAtIENOPUlQQSBSQSxPPTxhIGhyZWY9Imh0dHA6Ly9QSVBFQlJFQUtFUi5QTCIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+UElQRUJSRUFLRVIuUEw8L2E+PGJyPgpJTkZP OiAtIENOPUNlcnRpZmljYXRlIEF1dGhvcml0eSxPPTxhIGhyZWY9Imh0dHA6Ly9QSVBFQlJFQUtF Ui5QTCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+UElQRUJSRUFLRVIuUEw8L2E+ PGJyPgpJTkZPOiBQS0lBdXRoZW50aWNhdG9yOiBSZXN1bHQ6IGZhbHNlPGJyPgpGSU5FOiBGYWls ZWQgYXV0aGVudGljYXRlKCkgdGVzdDxicj4KRklORTogSlNTRW5naW5lOiB3cmFwKHNzbF9mZD1v cmcubW96aWxsYS5qc3MubnNzLlNTTEZEUHJveHlbMTUyMjYwNTgxMEAwMDA3OWVhOTc0NTUwMDAw XSk8YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgdGhpbmsgdGhl IGNsYXNzIGxvYWRpbmcgbWVzc2FnZXMgYWJvdmUgd2VyZSBnZW5lcmF0ZWQ8L2Rpdj48ZGl2PmJ5 IFRvbWNhdC4gVGhhdCYjMzk7cyBwcm9iYWJseSBob3cgaXQgcmVzb2x2ZXMgdGhlIGNsYXNzZXMs IHNvPC9kaXY+PGRpdj5JIGRvbiYjMzk7dCB0aGluayB0aGF0JiMzOTtzIGFuIGlzc3VlLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q291bGQgeW91IHJhaXNlIHRoZSBkZWJ1ZyBsZXZlbCBpbiB0 aGUgQ0Egc3Vic3lzdGVtIHRvbz88YnI+PC9kaXY+PGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vZG9ndGFncGtpL3BraS93aWtpL0NvbmZpZ3VyaW5nLVN1YnN5c3RlbS1EZWJ1Zy1Mb2ci Pmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL3dpa2kvQ29uZmlndXJpbmctU3Vic3lz dGVtLURlYnVnLUxvZzwvYT48L2Rpdj48ZGl2PjwvZGl2PjxkaXY+VGhlIGF1dGhlbnRpY2F0b3Ig dXNlcyB0aGUgTERBUCBjb25uZWN0aW9uIGluIHRoZSBDQSB0bzwvZGl2PjxkaXY+ZmluZCB0aGUg dXNlciBpbiBEUywgc28gdGhlcmUgbWlnaHQgYmUgYW4gaXNzdWUgdGhlcmUuPGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+LS0gPGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWdu YXR1cmUiPjxkaXYgZGlyPSJsdHIiPjxkaXY+RW5kaSBTLiBEZXdhdGE8YnI+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+Cg== --===============6086613702021397200==-- From edewata at redhat.com Thu Oct 21 18:25:37 2021 Content-Type: multipart/mixed; boundary="===============7210469224746569652==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 21 Oct 2021 13:25:09 -0500 Message-ID: In-Reply-To: CAMv3Fb7iq=KY_QxwuBfoCUpx5+NdvSBezGG0brkd3Y0fafRwsg@mail.gmail.com --===============7210469224746569652== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata 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? ACME also has a realm configuration: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configu= ring_ACME_Realm.md https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configu= ring-ACME-with-DS-Realm.adoc so there could be an issue there. -- = Endi S. Dewata --===============7210469224746569652== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIE9jdCAyMSwgMjAyMSBhdCAxMjo0NCBQTSBFbmRpIERl d2F0YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkZXdhdGFAcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmVkZXdhdGFAcmVkaGF0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRp diBkaXI9Imx0ciI+PGRpdj5JIHRoaW5rIHRoZSBjbGFzcyBsb2FkaW5nIG1lc3NhZ2VzIGFib3Zl IHdlcmUgZ2VuZXJhdGVkPC9kaXY+PGRpdj5ieSBUb21jYXQuIFRoYXQmIzM5O3MgcHJvYmFibHkg aG93IGl0IHJlc29sdmVzIHRoZSBjbGFzc2VzLCBzbzwvZGl2PjxkaXY+SSBkb24mIzM5O3QgdGhp bmsgdGhhdCYjMzk7cyBhbiBpc3N1ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNvdWxkIHlv dSByYWlzZSB0aGUgZGVidWcgbGV2ZWwgaW4gdGhlIENBIHN1YnN5c3RlbSB0b28/PGJyPjwvZGl2 PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvd2lraS9Db25m aWd1cmluZy1TdWJzeXN0ZW0tRGVidWctTG9nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRo dWIuY29tL2RvZ3RhZ3BraS9wa2kvd2lraS9Db25maWd1cmluZy1TdWJzeXN0ZW0tRGVidWctTG9n PC9hPjwvZGl2PjxkaXY+PC9kaXY+PGRpdj5UaGUgYXV0aGVudGljYXRvciB1c2VzIHRoZSBMREFQ IGNvbm5lY3Rpb24gaW4gdGhlIENBIHRvPC9kaXY+PGRpdj5maW5kIHRoZSB1c2VyIGluIERTLCBz byB0aGVyZSBtaWdodCBiZSBhbiBpc3N1ZSB0aGVyZS48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWN0dWFsbHkgaXQmIzM5O3MgYSBiaXQgZGlm ZmVyZW50IGZvciBBQ01FLiBJIGp1c3QgdXBkYXRlZCB0aGUgYWJvdmUgcGFnZS48L2Rpdj48ZGl2 PkNvdWxkIHlvdSByYWlzZSB0aGUgbG9nZ2luZyBsZXZlbCBpbiBBQ01FIHRvbz88L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PkFDTUUgYWxzbyBoYXMgYSByZWFsbSBjb25maWd1cmF0aW9uOjxicj48 L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2Iv bWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmdfQUNNRV9SZWFsbS5tZCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFz dGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmdfQUNNRV9SZWFsbS5tZDwvYT48 L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2Iv bWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJl YWxtLmFkb2MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtpL3Br aS9ibG9iL21hc3Rlci9kb2NzL2luc3RhbGxhdGlvbi9hY21lL0NvbmZpZ3VyaW5nLUFDTUUtd2l0 aC1EUy1SZWFsbS5hZG9jPC9hPjwvZGl2PjxkaXY+c28gdGhlcmUgY291bGQgYmUgYW4gaXNzdWUg dGhlcmUuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LS0gPC9kaXY+PGRpdiBkaXI9Imx0 ciI+PGRpdiBkaXI9Imx0ciI+PGRpdj5FbmRpIFMuIERld2F0YTxicj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj4K --===============7210469224746569652==-- From tomek at pipebreaker.pl Fri Oct 22 18:14:20 2021 Content-Type: multipart/mixed; boundary="===============0609551504886423958==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Fri, 22 Oct 2021 20:14:08 +0200 Message-ID: In-Reply-To: CAMv3Fb6s4TCbWxqfOD9He88=3_mhEWTdoxPLNx1cD65vnX7UfQ@mail.gmail.com --===============0609551504886423958== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2021 at 01:25:09PM -0500, Endi Dewata via FreeIPA-users wro= te: > On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata 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=3DIPA RA,O=3DPIPEBREAKER.PL INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL INFO: PKIAuthenticator: Result: false and in ca/debug-.log: 2021-10-22 19:55:32 [Timer-0] FINE: LdapBoundConnFactory: number of connect= ions: 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=3DIPA RA,O=3DP= IPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: parent: CN=3DCert= ificate Authority,O=3DPIPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=3DCertificate = Authority,O=3DPIPEBREAKER.PL 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: child: CN=3DIPA R= A,O=3DPIPEBREAKER.PL dirsrv log shows 1 certificate is being found: [22/Oct/2021:20:05:35.119328765 +0200] conn=3D4469 op=3D9 SRCH base=3D"ou= =3Dpeople,o=3Dipaca" scope=3D1 filter=3D"(description=3D2;105;CN=3DCertific= ate Authority,O=3DPIPEBREAKER.PL;CN=3DIP A RA,O=3DPIPEBREAKER.PL)" attrs=3DALL [22/Oct/2021:20:05:35.119963856 +0200] conn=3D4469 op=3D9 RESULT err=3D0 ta= g=3D101 nentries=3D1 wtime=3D0.000231485 optime=3D0.000638726 etime=3D0.000= 867770 [22/Oct/2021:20:05:35.277708077 +0200] conn=3D4508 op=3D3 UNBIND BUT in acme/debug.log: 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Looking up certific= ates 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=3Dpeop= le,o=3Dipaca 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - filter: descriptio= n=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O=3DPIP= EBREAKER.PL 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: User: uid=3Dipara,ou= =3Dpeople,o=3Dipaca 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/Confi= guring_ACME_Realm.md > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring-ACME-with-DS-Realm.adoc > so there could be an issue there. This look to be configured, but I found a possible discrepancy in "passwo= rd": $ cat /etc/pki/pki-tomcat/acme/realm.conf = # VERSION 2 - DO NOT REMOVE THIS LINE authType=3DBasicAuth class=3Dorg.dogtagpki.acme.realm.DSRealm groupsDN=3Dou=3Dgroups,o=3Dipaca usersDN=3Dou=3Dpeople,o=3Dipaca url=3Dldaps://kaitain.pipebreaker.pl:636 configFile=3D/etc/pki/pki-tomcat/ca/CS.cfg username=3Dacme-kaitain.pipebreaker.pl password=3D<40-character long text string> While userPassword:: field of uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpeop= le,o=3Dipaca 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? -- = Tomasz Torcz Once you've read the dictionary, @ttorcz:pipebreaker.pl every other book is just a remix. --===============0609551504886423958==-- From rcritten at redhat.com Mon Oct 25 12:40:27 2021 Content-Type: multipart/mixed; boundary="===============6734006888250221096==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Mon, 25 Oct 2021 08:40:07 -0400 Message-ID: In-Reply-To: YXL/cPzPDpE1zCYl@mother.pipebreaker.pl --===============6734006888250221096== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Thu, Oct 21, 2021 at 01:25:09PM -0500, Endi Dewata via FreeIPA-users w= rote: >> On Thu, Oct 21, 2021 at 12:44 PM Endi Dewata wrot= e: >> >>> 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=3DIPA RA,O=3DPIPEBREAKER.PL > INFO: - CN=3DCertificate Authority,O=3DPIPEBREAKER.PL > INFO: PKIAuthenticator: Result: false > = > and in ca/debug-.log: > = > 2021-10-22 19:55:32 [Timer-0] FINE: LdapBoundConnFactory: number of conne= ctions: 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=3DIPA RA,O= =3DPIPEBREAKER.PL > 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: parent: CN=3DCe= rtificate Authority,O=3DPIPEBREAKER.PL > 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: - CN=3DCertificat= e Authority,O=3DPIPEBREAKER.PL > 2021-10-22 19:59:16 [https-jsse-nio-8443-exec-3] FINE: child: CN=3DIPA= RA,O=3DPIPEBREAKER.PL > = > = > dirsrv log shows 1 certificate is being found: > [22/Oct/2021:20:05:35.119328765 +0200] conn=3D4469 op=3D9 SRCH base=3D"ou= =3Dpeople,o=3Dipaca" scope=3D1 filter=3D"(description=3D2;105;CN=3DCertific= ate Authority,O=3DPIPEBREAKER.PL;CN=3DIP > A RA,O=3DPIPEBREAKER.PL)" attrs=3DALL > [22/Oct/2021:20:05:35.119963856 +0200] conn=3D4469 op=3D9 RESULT err=3D0 = tag=3D101 nentries=3D1 wtime=3D0.000231485 optime=3D0.000638726 etime=3D0.0= 00867770 > [22/Oct/2021:20:05:35.277708077 +0200] conn=3D4508 op=3D3 UNBIND > = > = > = > BUT in acme/debug.log: > = > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] FINE: Looking up certif= icates > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Authenticating use= r with client certificate > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: Finding user by ce= rt: > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - base DN: ou=3Dpe= ople,o=3Dipaca > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: - filter: descript= ion=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O=3DP= IPEBREAKER.PL > 2021-10-22 20:01:12 [https-jsse-nio-8443-exec-4] INFO: User: uid=3Dipara,= ou=3Dpeople,o=3Dipaca > 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/Conf= iguring_ACME_Realm.md >> https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Conf= iguring-ACME-with-DS-Realm.adoc >> so there could be an issue there. > = > This look to be configured, but I found a possible discrepancy in "pass= word": > = > $ cat /etc/pki/pki-tomcat/acme/realm.conf = > # VERSION 2 - DO NOT REMOVE THIS LINE > authType=3DBasicAuth > class=3Dorg.dogtagpki.acme.realm.DSRealm > groupsDN=3Dou=3Dgroups,o=3Dipaca > usersDN=3Dou=3Dpeople,o=3Dipaca > url=3Dldaps://kaitain.pipebreaker.pl:636 > configFile=3D/etc/pki/pki-tomcat/ca/CS.cfg > username=3Dacme-kaitain.pipebreaker.pl > password=3D<40-character long text string> > = > While userPassword:: field of uid=3Dacme-kaitain.pipebreaker.pl,ou=3Dpe= ople,o=3Dipaca > 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 --===============6734006888250221096==-- From edewata at redhat.com Mon Oct 25 15:10:29 2021 Content-Type: multipart/mixed; boundary="===============7219978217722447237==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Mon, 25 Oct 2021 10:09:56 -0500 Message-ID: In-Reply-To: c0b177ed-056c-f608-3052-a7617001e0a2@redhat.com --===============7219978217722447237== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > Tomasz Torcz via FreeIPA-users wrote: > >> ACME also has a realm configuration: > >> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring_ACME_Realm.md > >> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring-ACME-with-DS-Realm.adoc > >> 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=3DBasicAuth > > class=3Dorg.dogtagpki.acme.realm.DSRealm > > groupsDN=3Dou=3Dgroups,o=3Dipaca > > usersDN=3Dou=3Dpeople,o=3Dipaca > > url=3Dldaps://kaitain.pipebreaker.pl:636 > > configFile=3D/etc/pki/pki-tomcat/ca/CS.cfg > > username=3Dacme-kaitain.pipebreaker.pl > > password=3D<40-character long text string> > > > > While userPassword:: field of uid=3Dacme-kaitain.pipebreaker.pl > ,ou=3Dpeople,o=3Dipaca > > 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 > Looks like the realm is configured with BasicAuth, so it should be using bindDN and bindPassword params as described here: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Configu= ring-ACME-with-DS-Realm.adoc If you want to use SslClientAuth, I think you would need to specify the nickname param: https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/do= gtagpki/acme/realm/LDAPRealm.java#L112 https://github.com/dogtagpki/pki/blob/master/base/server/src/main/java/com/= netscape/cmscore/ldapconn/LdapAuthInfo.java#L36 https://github.com/dogtagpki/pki/wiki/Configuring-Client-Certificate-Authen= tication-to-Internal-Database But IIRC in IPA case it's configured to reuse the internaldb connection defined in CS.cfg so these params don't need to be specified again. Is there a working IPA instance with ACME that can be compared against? -- = Endi S. Dewata --===============7219978217722447237== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIE9jdCAyNSwgMjAyMSBhdCA3OjQyIEFNIFJvYiBDcml0 dGVuZGVuIHZpYSBGcmVlSVBBLXVzZXJzICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZWlwYS11c2Vy c0BsaXN0cy5mZWRvcmFob3N0ZWQub3JnIj5mcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3Rl ZC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPlRvbWFzeiBUb3JjeiB2aWEgRnJl ZUlQQS11c2VycyB3cm90ZTo8YnI+Jmd0OyZndDsgQUNNRSBhbHNvIGhhcyBhIHJlYWxtIGNvbmZp Z3VyYXRpb246PGJyPgomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZG9ndGFn cGtpL3BraS9ibG9iL21hc3Rlci9kb2NzL2luc3RhbGxhdGlvbi9hY21lL0NvbmZpZ3VyaW5nX0FD TUVfUmVhbG0ubWQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0 aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUv Q29uZmlndXJpbmdfQUNNRV9SZWFsbS5tZDwvYT48YnI+CiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9u L2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJlYWxtLmFkb2MiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2Iv bWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJl YWxtLmFkb2M8L2E+PGJyPgomZ3Q7Jmd0OyBzbyB0aGVyZSBjb3VsZCBiZSBhbiBpc3N1ZSB0aGVy ZS48YnI+CiZndDsgPGJyPgomZ3Q7wqAgwqBUaGlzIGxvb2sgdG8gYmUgY29uZmlndXJlZCwgYnV0 IEkgZm91bmQgYSBwb3NzaWJsZSBkaXNjcmVwYW5jeSBpbiAmcXVvdDtwYXNzd29yZCZxdW90Ozo8 YnI+CiZndDsgPGJyPgomZ3Q7ICQgY2F0IC9ldGMvcGtpL3BraS10b21jYXQvYWNtZS9yZWFsbS5j b25mIDxicj4KJmd0OyAjIFZFUlNJT04gMiAtIERPIE5PVCBSRU1PVkUgVEhJUyBMSU5FPGJyPgom Z3Q7IGF1dGhUeXBlPUJhc2ljQXV0aDxicj4KJmd0OyBjbGFzcz1vcmcuZG9ndGFncGtpLmFjbWUu cmVhbG0uRFNSZWFsbTxicj4KJmd0OyBncm91cHNETj1vdT1ncm91cHMsbz1pcGFjYTxicj4KJmd0 OyB1c2Vyc0ROPW91PXBlb3BsZSxvPWlwYWNhPGJyPgomZ3Q7IHVybD1sZGFwczovLzxhIGhyZWY9 Imh0dHA6Ly9rYWl0YWluLnBpcGVicmVha2VyLnBsOjYzNiIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+a2FpdGFpbi5waXBlYnJlYWtlci5wbDo2MzY8L2E+PGJyPgomZ3Q7IGNvbmZp Z0ZpbGU9L2V0Yy9wa2kvcGtpLXRvbWNhdC9jYS9DUy5jZmc8YnI+CiZndDsgdXNlcm5hbWU9PGEg aHJlZj0iaHR0cDovL2FjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbCIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+YWNtZS1rYWl0YWluLnBpcGVicmVha2VyLnBsPC9hPjxicj4KJmd0 OyBwYXNzd29yZD0mbHQ7NDAtY2hhcmFjdGVyIGxvbmcgdGV4dCBzdHJpbmcmZ3Q7PGJyPgomZ3Q7 IDxicj4KJmd0O8KgIMKgV2hpbGUgdXNlclBhc3N3b3JkOjogZmllbGQgb2YgdWlkPTxhIGhyZWY9 Imh0dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbDwvYT4sb3U9cGVvcGxlLG89 aXBhY2E8YnI+CiZndDsgY29udGFpbnMgdmVyeSBsb25nIGJhc2U2NCBzdHJpbmcsIHdoaWNoIGRl Y29kZXMgdG8gNDQ3IHN0cmluZyBzdGFydGluZzxicj4KJmd0OyB3aXRoIHtQQktERjJfU0hBMjU2 fS4gSG93IHRvIG1ha2Ugc3VyZSBpdCYjMzk7cyBjb3JyZXNwb25kcyB0byB0aGUgc2FtZTxicj4K Jmd0OyB2YWx1ZT88YnI+CiZndDsgPGJyPgo8YnI+ClRoaXMgaXMgdGhlIHBhc3N3b3JkIGZvciB0 aGUgdXNlcm5hbWUgaW4gdGhlIGZpbGUuIEl0IGlzIGJhc2ljYWxseTxicj4KdW51c2VkIGJ5IElQ QSBhcyBJUEEgdXNlcyBjbGllbnQgYXV0aCB3aXRoIHRoZSBSQSBhZ2VudCBjZXJ0aWZpY2F0ZS48 YnI+Cjxicj4Kcm9iPGJyIGNsZWFyPSJhbGwiPjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2Pkxvb2tzIGxpa2UgdGhlIHJlYWxtIGlzIGNvbmZpZ3VyZWQgd2l0aCBCYXNpY0F1 dGgsIHNvIGl0IHNob3VsZCBiZTwvZGl2PjxkaXY+dXNpbmcgYmluZEROIGFuZCBiaW5kUGFzc3dv cmQgcGFyYW1zIGFzIGRlc2NyaWJlZCBoZXJlOjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvZG9jcy9pbnN0YWxsYXRpb24vYWNt ZS9Db25maWd1cmluZy1BQ01FLXdpdGgtRFMtUmVhbG0uYWRvYyI+aHR0cHM6Ly9naXRodWIuY29t L2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvZG9jcy9pbnN0YWxsYXRpb24vYWNtZS9Db25maWd1 cmluZy1BQ01FLXdpdGgtRFMtUmVhbG0uYWRvYzwvYT48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PklmIHlvdSB3YW50IHRvIHVzZSA8c3BhbiBjbGFzcz0iZ21haWwtcGwtcyI+PHNwYW4gY2xhc3M9 ImdtYWlsLXBsLXBkcyI+PC9zcGFuPlNzbENsaWVudEF1dGg8c3BhbiBjbGFzcz0iZ21haWwtcGwt cGRzIj4sPC9zcGFuPjwvc3Bhbj4gSSB0aGluayB5b3Ugd291bGQgbmVlZCB0bzwvZGl2PjxkaXY+ c3BlY2lmeSB0aGUgbmlja25hbWUgcGFyYW08c3BhbiBjbGFzcz0iZ21haWwtcGwtcyI+PHNwYW4g Y2xhc3M9ImdtYWlsLXBsLXBkcyI+Ojwvc3Bhbj48L3NwYW4+PC9kaXY+PGRpdj48YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtpL3BraS9ibG9iL21hc3Rlci9iYXNlL2FjbWUvc3Jj L21haW4vamF2YS9vcmcvZG9ndGFncGtpL2FjbWUvcmVhbG0vTERBUFJlYWxtLmphdmEjTDExMiI+ aHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvYmFzZS9hY21lL3Ny Yy9tYWluL2phdmEvb3JnL2RvZ3RhZ3BraS9hY21lL3JlYWxtL0xEQVBSZWFsbS5qYXZhI0wxMTI8 L2E+PC9kaXY+PGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtpL3BraS9i bG9iL21hc3Rlci9iYXNlL3NlcnZlci9zcmMvbWFpbi9qYXZhL2NvbS9uZXRzY2FwZS9jbXNjb3Jl L2xkYXBjb25uL0xkYXBBdXRoSW5mby5qYXZhI0wzNiI+aHR0cHM6Ly9naXRodWIuY29tL2RvZ3Rh Z3BraS9wa2kvYmxvYi9tYXN0ZXIvYmFzZS9zZXJ2ZXIvc3JjL21haW4vamF2YS9jb20vbmV0c2Nh cGUvY21zY29yZS9sZGFwY29ubi9MZGFwQXV0aEluZm8uamF2YSNMMzY8L2E+PC9kaXY+PGEgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvd2lraS9Db25maWd1cmluZy1DbGll bnQtQ2VydGlmaWNhdGUtQXV0aGVudGljYXRpb24tdG8tSW50ZXJuYWwtRGF0YWJhc2UiPmh0dHBz Oi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL3dpa2kvQ29uZmlndXJpbmctQ2xpZW50LUNlcnRp ZmljYXRlLUF1dGhlbnRpY2F0aW9uLXRvLUludGVybmFsLURhdGFiYXNlPC9hPjxkaXY+PGJyPjwv ZGl2PjxkaXY+QnV0IElJUkMgaW4gSVBBIGNhc2UgaXQmIzM5O3MgY29uZmlndXJlZCB0byByZXVz ZSB0aGUgaW50ZXJuYWxkYiBjb25uZWN0aW9uPC9kaXY+PGRpdj5kZWZpbmVkIGluIENTLmNmZyBz byB0aGVzZSBwYXJhbXMgZG9uJiMzOTt0IG5lZWQgdG8gYmUgc3BlY2lmaWVkIGFnYWluLjwvZGl2 PjxkaXY+SXMgdGhlcmUgYSB3b3JraW5nIElQQSBpbnN0YW5jZSB3aXRoIEFDTUUgdGhhdCBjYW4g YmUgY29tcGFyZWQ8L2Rpdj48ZGl2PmFnYWluc3Q/PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pi0t IDxicj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIj48ZGl2IGRpcj0ibHRy Ij48ZGl2PkVuZGkgUy4gRGV3YXRhPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pgo= --===============7219978217722447237==-- From edewata at redhat.com Mon Oct 25 15:17:19 2021 Content-Type: multipart/mixed; boundary="===============7566682712038930989==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Mon, 25 Oct 2021 10:16:38 -0500 Message-ID: In-Reply-To: CAMv3Fb5JhYDWiTv53zT47RiAk52sKpPT_i=vwSQpWWT3DAgBJg@mail.gmail.com --===============7566682712038930989== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2021 at 10:09 AM Endi Dewata wrote: > On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> wrote: > >> Tomasz Torcz via FreeIPA-users wrote: >> >> ACME also has a realm configuration: >> >> >> https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Conf= iguring_ACME_Realm.md >> >> >> https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Conf= iguring-ACME-with-DS-Realm.adoc >> >> 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=3DBasicAuth >> > class=3Dorg.dogtagpki.acme.realm.DSRealm >> > groupsDN=3Dou=3Dgroups,o=3Dipaca >> > usersDN=3Dou=3Dpeople,o=3Dipaca >> > url=3Dldaps://kaitain.pipebreaker.pl:636 >> > configFile=3D/etc/pki/pki-tomcat/ca/CS.cfg >> > username=3Dacme-kaitain.pipebreaker.pl >> > password=3D<40-character long text string> >> > >> > While userPassword:: field of uid=3Dacme-kaitain.pipebreaker.pl >> ,ou=3Dpeople,o=3Dipaca >> > 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 >> > > Looks like the realm is configured with BasicAuth, so it should be > using bindDN and bindPassword params as described here: > > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring-ACME-with-DS-Realm.adoc > > If you want to use SslClientAuth, I think you would need to > specify the nickname param: > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/= dogtagpki/acme/realm/LDAPRealm.java#L112 > > https://github.com/dogtagpki/pki/blob/master/base/server/src/main/java/co= m/netscape/cmscore/ldapconn/LdapAuthInfo.java#L36 > > https://github.com/dogtagpki/pki/wiki/Configuring-Client-Certificate-Auth= entication-to-Internal-Database > > But IIRC in IPA case it's configured to reuse the internaldb connection > defined in CS.cfg so these params don't need to be specified again. > Is there a working IPA instance with ACME that can be compared > against? > Yeah, the realm config has a configFile param, so it will ignore the other params above, and use the params from CS.cfg instead: https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/do= gtagpki/acme/realm/LDAPRealm.java#L61 https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/do= gtagpki/acme/realm/LDAPRealm.java#L147-L153 -- = Endi S. Dewata --===============7566682712038930989== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIE9jdCAyNSwgMjAyMSBhdCAxMDowOSBBTSBFbmRpIERl d2F0YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkZXdhdGFAcmVkaGF0LmNvbSI+ZWRld2F0YUByZWRo YXQuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29s aWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj48ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9u IE1vbiwgT2N0IDI1LCAyMDIxIGF0IDc6NDIgQU0gUm9iIENyaXR0ZW5kZW4gdmlhIEZyZWVJUEEt dXNlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3Rl ZC5vcmciIHRhcmdldD0iX2JsYW5rIj5mcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3RlZC5v cmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCBy Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPlRvbWFzeiBUb3JjeiB2aWEgRnJlZUlQ QS11c2VycyB3cm90ZTo8YnI+Jmd0OyZndDsgQUNNRSBhbHNvIGhhcyBhIHJlYWxtIGNvbmZpZ3Vy YXRpb246PGJyPgomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtp L3BraS9ibG9iL21hc3Rlci9kb2NzL2luc3RhbGxhdGlvbi9hY21lL0NvbmZpZ3VyaW5nX0FDTUVf UmVhbG0ubWQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHVi LmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29u ZmlndXJpbmdfQUNNRV9SZWFsbS5tZDwvYT48YnI+CiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2Fj bWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJlYWxtLmFkb2MiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFz dGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJlYWxt LmFkb2M8L2E+PGJyPgomZ3Q7Jmd0OyBzbyB0aGVyZSBjb3VsZCBiZSBhbiBpc3N1ZSB0aGVyZS48 YnI+CiZndDsgPGJyPgomZ3Q7wqAgwqBUaGlzIGxvb2sgdG8gYmUgY29uZmlndXJlZCwgYnV0IEkg Zm91bmQgYSBwb3NzaWJsZSBkaXNjcmVwYW5jeSBpbiAmcXVvdDtwYXNzd29yZCZxdW90Ozo8YnI+ CiZndDsgPGJyPgomZ3Q7ICQgY2F0IC9ldGMvcGtpL3BraS10b21jYXQvYWNtZS9yZWFsbS5jb25m IDxicj4KJmd0OyAjIFZFUlNJT04gMiAtIERPIE5PVCBSRU1PVkUgVEhJUyBMSU5FPGJyPgomZ3Q7 IGF1dGhUeXBlPUJhc2ljQXV0aDxicj4KJmd0OyBjbGFzcz1vcmcuZG9ndGFncGtpLmFjbWUucmVh bG0uRFNSZWFsbTxicj4KJmd0OyBncm91cHNETj1vdT1ncm91cHMsbz1pcGFjYTxicj4KJmd0OyB1 c2Vyc0ROPW91PXBlb3BsZSxvPWlwYWNhPGJyPgomZ3Q7IHVybD1sZGFwczovLzxhIGhyZWY9Imh0 dHA6Ly9rYWl0YWluLnBpcGVicmVha2VyLnBsOjYzNiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+a2FpdGFpbi5waXBlYnJlYWtlci5wbDo2MzY8L2E+PGJyPgomZ3Q7IGNvbmZpZ0Zp bGU9L2V0Yy9wa2kvcGtpLXRvbWNhdC9jYS9DUy5jZmc8YnI+CiZndDsgdXNlcm5hbWU9PGEgaHJl Zj0iaHR0cDovL2FjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbCIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+YWNtZS1rYWl0YWluLnBpcGVicmVha2VyLnBsPC9hPjxicj4KJmd0OyBw YXNzd29yZD0mbHQ7NDAtY2hhcmFjdGVyIGxvbmcgdGV4dCBzdHJpbmcmZ3Q7PGJyPgomZ3Q7IDxi cj4KJmd0O8KgIMKgV2hpbGUgdXNlclBhc3N3b3JkOjogZmllbGQgb2YgdWlkPTxhIGhyZWY9Imh0 dHA6Ly9hY21lLWthaXRhaW4ucGlwZWJyZWFrZXIucGwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPmFjbWUta2FpdGFpbi5waXBlYnJlYWtlci5wbDwvYT4sb3U9cGVvcGxlLG89aXBh Y2E8YnI+CiZndDsgY29udGFpbnMgdmVyeSBsb25nIGJhc2U2NCBzdHJpbmcsIHdoaWNoIGRlY29k ZXMgdG8gNDQ3IHN0cmluZyBzdGFydGluZzxicj4KJmd0OyB3aXRoIHtQQktERjJfU0hBMjU2fS4g SG93IHRvIG1ha2Ugc3VyZSBpdCYjMzk7cyBjb3JyZXNwb25kcyB0byB0aGUgc2FtZTxicj4KJmd0 OyB2YWx1ZT88YnI+CiZndDsgPGJyPgo8YnI+ClRoaXMgaXMgdGhlIHBhc3N3b3JkIGZvciB0aGUg dXNlcm5hbWUgaW4gdGhlIGZpbGUuIEl0IGlzIGJhc2ljYWxseTxicj4KdW51c2VkIGJ5IElQQSBh cyBJUEEgdXNlcyBjbGllbnQgYXV0aCB3aXRoIHRoZSBSQSBhZ2VudCBjZXJ0aWZpY2F0ZS48YnI+ Cjxicj4Kcm9iPGJyIGNsZWFyPSJhbGwiPjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pkxvb2tzIGxpa2UgdGhlIHJlYWxtIGlzIGNvbmZpZ3VyZWQgd2l0aCBCYXNpY0F1dGgs IHNvIGl0IHNob3VsZCBiZTwvZGl2PjxkaXY+dXNpbmcgYmluZEROIGFuZCBiaW5kUGFzc3dvcmQg cGFyYW1zIGFzIGRlc2NyaWJlZCBoZXJlOjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvZG9jcy9pbnN0YWxsYXRpb24vYWNtZS9D b25maWd1cmluZy1BQ01FLXdpdGgtRFMtUmVhbG0uYWRvYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9u L2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJlYWxtLmFkb2M8L2E+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5JZiB5b3Ugd2FudCB0byB1c2UgPHNwYW4+PHNwYW4+PC9zcGFuPlNzbENs aWVudEF1dGg8c3Bhbj4sPC9zcGFuPjwvc3Bhbj4gSSB0aGluayB5b3Ugd291bGQgbmVlZCB0bzwv ZGl2PjxkaXY+c3BlY2lmeSB0aGUgbmlja25hbWUgcGFyYW08c3Bhbj48c3Bhbj46PC9zcGFuPjwv c3Bhbj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtp L2Jsb2IvbWFzdGVyL2Jhc2UvYWNtZS9zcmMvbWFpbi9qYXZhL29yZy9kb2d0YWdwa2kvYWNtZS9y ZWFsbS9MREFQUmVhbG0uamF2YSNMMTEyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIu Y29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvYmFzZS9hY21lL3NyYy9tYWluL2phdmEvb3Jn L2RvZ3RhZ3BraS9hY21lL3JlYWxtL0xEQVBSZWFsbS5qYXZhI0wxMTI8L2E+PC9kaXY+PGRpdj48 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtpL3BraS9ibG9iL21hc3Rlci9iYXNl L3NlcnZlci9zcmMvbWFpbi9qYXZhL2NvbS9uZXRzY2FwZS9jbXNjb3JlL2xkYXBjb25uL0xkYXBB dXRoSW5mby5qYXZhI0wzNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0 YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2Jhc2Uvc2VydmVyL3NyYy9tYWluL2phdmEvY29tL25ldHNj YXBlL2Ntc2NvcmUvbGRhcGNvbm4vTGRhcEF1dGhJbmZvLmphdmEjTDM2PC9hPjwvZGl2PjxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL3dpa2kvQ29uZmlndXJpbmctQ2xp ZW50LUNlcnRpZmljYXRlLUF1dGhlbnRpY2F0aW9uLXRvLUludGVybmFsLURhdGFiYXNlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvd2lraS9Db25maWd1 cmluZy1DbGllbnQtQ2VydGlmaWNhdGUtQXV0aGVudGljYXRpb24tdG8tSW50ZXJuYWwtRGF0YWJh c2U8L2E+PGRpdj48YnI+PC9kaXY+PGRpdj5CdXQgSUlSQyBpbiBJUEEgY2FzZSBpdCYjMzk7cyBj b25maWd1cmVkIHRvIHJldXNlIHRoZSBpbnRlcm5hbGRiIGNvbm5lY3Rpb248L2Rpdj48ZGl2PmRl ZmluZWQgaW4gQ1MuY2ZnIHNvIHRoZXNlIHBhcmFtcyBkb24mIzM5O3QgbmVlZCB0byBiZSBzcGVj aWZpZWQgYWdhaW4uPC9kaXY+PGRpdj5JcyB0aGVyZSBhIHdvcmtpbmcgSVBBIGluc3RhbmNlIHdp dGggQUNNRSB0aGF0IGNhbiBiZSBjb21wYXJlZDwvZGl2PjxkaXY+YWdhaW5zdD88YnI+PC9kaXY+ PC9kaXY+CjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlllYWgsIHRoZSBy ZWFsbSBjb25maWcgaGFzIGEgPHNwYW4gY2xhc3M9ImdtYWlsLXBsLXMiPjxzcGFuIGNsYXNzPSJn bWFpbC1wbC1wZHMiPjwvc3Bhbj5jb25maWdGaWxlPHNwYW4gY2xhc3M9ImdtYWlsLXBsLXBkcyI+ IHBhcmFtLCBzbyBpdCB3aWxsIGlnbm9yZSB0aGU8L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXY+PHNw YW4gY2xhc3M9ImdtYWlsLXBsLXMiPjxzcGFuIGNsYXNzPSJnbWFpbC1wbC1wZHMiPm90aGVyIHBh cmFtcyBhYm92ZSwgYW5kIHVzZSB0aGUgcGFyYW1zIGZyb20gQ1MuY2ZnIGluc3RlYWQ6PGJyPjwv c3Bhbj48L3NwYW4+PC9kaXY+PGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZG9ndGFn cGtpL3BraS9ibG9iL21hc3Rlci9iYXNlL2FjbWUvc3JjL21haW4vamF2YS9vcmcvZG9ndGFncGtp L2FjbWUvcmVhbG0vTERBUFJlYWxtLmphdmEjTDYxIj5odHRwczovL2dpdGh1Yi5jb20vZG9ndGFn cGtpL3BraS9ibG9iL21hc3Rlci9iYXNlL2FjbWUvc3JjL21haW4vamF2YS9vcmcvZG9ndGFncGtp L2FjbWUvcmVhbG0vTERBUFJlYWxtLmphdmEjTDYxPC9hPjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvYmFzZS9hY21lL3NyYy9t YWluL2phdmEvb3JnL2RvZ3RhZ3BraS9hY21lL3JlYWxtL0xEQVBSZWFsbS5qYXZhI0wxNDctTDE1 MyI+aHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvYmFzZS9hY21l L3NyYy9tYWluL2phdmEvb3JnL2RvZ3RhZ3BraS9hY21lL3JlYWxtL0xEQVBSZWFsbS5qYXZhI0wx NDctTDE1MzwvYT48L2Rpdj48ZGl2Pjxicj48L2Rpdj4tLSA8YnI+PGRpdiBkaXI9Imx0ciIgY2xh c3M9ImdtYWlsX3NpZ25hdHVyZSI+PGRpdiBkaXI9Imx0ciI+PGRpdj5FbmRpIFMuIERld2F0YTxi cj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4K --===============7566682712038930989==-- From tomek at pipebreaker.pl Wed Nov 3 17:57:21 2021 Content-Type: multipart/mixed; boundary="===============5889037187149938040==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Wed, 03 Nov 2021 18:57:06 +0100 Message-ID: In-Reply-To: CAMv3Fb5JhYDWiTv53zT47RiAk52sKpPT_i=vwSQpWWT3DAgBJg@mail.gmail.com --===============5889037187149938040== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users wro= te: > On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> wrote: > = > > Tomasz Torcz via FreeIPA-users wrote: > > >> ACME also has a realm configuration: > > >> > > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Con= figuring_ACME_Realm.md > > >> > > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Con= figuring-ACME-with-DS-Realm.adoc > > >> so there could be an issue there. > > > > = > But IIRC in IPA case it's configured to reuse the internaldb connection > defined in CS.cfg so these params don't need to be specified again. > Is there a working IPA instance with ACME that can be compared > against? So I did a clean install of Fedora 34 and FreeIPA. Clean install works as expected. I did comparison between fresh and mine install, there were discrepancies I mostly fixed, but it didn't change my problem. Failure looks like that in logs (pki-tomcat/acme/debug-.log): 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by cer= t: 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: ou=3Dpeo= ple,o=3Dipaca 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: descripti= on=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O=3DPI= PEBREAKER.PL 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: uid=3Dipara,o= u=3Dpeople,o=3Dipaca 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: Realm.authenticat= e() returned false While on _fresh install_ correct log looks like: 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating user= with client certificate 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by cer= t: 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=3Dpeo= ple,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: descripti= on=3D2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN=3DIPA RA,O= =3DIPADEV.PIPEBREAKER.PL 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: uid=3Dipara,o= u=3Dpeople,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user roles: 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=3Dgro= ups,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: uniqueMem= ber=3Duid=3Dipara,ou=3Dpeople,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DCertificate = Manager Agents,ou=3Dgroups,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DRegistration= Manager Agents,ou=3Dgroups,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DEnterprise A= CME Administrators,ou=3Dgroups,o=3Dipaca 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing ACMEAp= plication 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: S= ession: 3DBCD2FB21ADFDD04ADC518C97AA07B4 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: P= rincipal: GenericPrincipal[ipara(Certificate Manager Agents,Enterprise ACME= Administrators,Registration Manager Agents,)] 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: P= rincipal: ipara 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: R= oles: 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: -= Certificate Manager Agents 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: -= Enterprise ACME Administrators 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService: -= Registration Manager Agents 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: searc= h ou=3Dconfig,ou=3Dacme,o=3Dipaca 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: ACMERequest= Filter: ACME service is disabled Things I've observed on fresh install, which I've implemented on my produ= ction (it changed nothing, provided here for documentation only): # in /etc/pki/pki-tomcat/ca/CS.cfg: - added lines: features.authority.description=3DLightweight CAs features.authority.enabled=3Dtrue features.authority.version=3D1.0 - 36 profile.* lines were missing; carefully added them, for example: profile.AdminCert.class_id=3DcaEnrollImpl profile.AdminCert.config=3D/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCer= t.cfg - also copied a long line starting with profile.listprofile.list=3D - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 files,= while fresh install had over 90. I've copied missing ones from /usr/share/pki/c= a/profiles/ca/ # in LDAP - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; adde= d on prod uniqueMember: uid=3Dpkidbuser,ou=3DPeople,o=3Dipaca - pkidbuser had 3 userCertificate: entries, two of them were expired; remov= ed those -- = Tomasz Torcz 72->| = 80->| tomek(a)pipebreaker.pl 72->| = 80->| --===============5889037187149938040==-- From rcritten at redhat.com Thu Nov 4 17:29:49 2021 Content-Type: multipart/mixed; boundary="===============0748244823270811025==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 04 Nov 2021 13:29:32 -0400 Message-ID: <01772f27-a8c6-551a-67ca-de3df68e61b5@redhat.com> In-Reply-To: YYLNcgfr4peYO7wq@mother.pipebreaker.pl --===============0748244823270811025== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users w= rote: >> On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: >> >>> Tomasz Torcz via FreeIPA-users wrote: >>>>> ACME also has a realm configuration: >>>>> >>> https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Con= figuring_ACME_Realm.md >>>>> >>> https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Con= figuring-ACME-with-DS-Realm.adoc >>>>> so there could be an issue there. >>>> >> >> But IIRC in IPA case it's configured to reuse the internaldb connection >> defined in CS.cfg so these params don't need to be specified again. >> Is there a working IPA instance with ACME that can be compared >> against? > = > So I did a clean install of Fedora 34 and FreeIPA. Clean install works > as expected. I did comparison between fresh and mine install, > there were discrepancies I mostly fixed, but it didn't change my > problem. > Failure looks like that in logs (pki-tomcat/acme/debug-.log): > = > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by c= ert: > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: ou=3Dp= eople,o=3Dipaca > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: descrip= tion=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O=3D= PIPEBREAKER.PL > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: uid=3Dipara= ,ou=3Dpeople,o=3Dipaca > 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: Realm.authentic= ate() returned false Yeah, I noticed this in your logs as well. I have no insight into what PKI does to authenticate beyond the things you've already checked. We know that this cert is ok because you can authenticate to the CA using it in other ways. It would be nice if they logged some reason for the failure to authenticate but I'm not sure how to get that. rob > = > = > While on _fresh install_ correct log looks like: > = > 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating us= er with client certificate > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by c= ert: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=3Dp= eople,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: descrip= tion=3D2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN=3DIPA RA= ,O=3DIPADEV.PIPEBREAKER.PL > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: uid=3Dipara= ,ou=3Dpeople,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user role= s: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: ou=3Dg= roups,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: uniqueM= ember=3Duid=3Dipara,ou=3Dpeople,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DCertificat= e Manager Agents,ou=3Dgroups,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DRegistrati= on Manager Agents,ou=3Dgroups,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DEnterprise= ACME Administrators,ou=3Dgroups,o=3Dipaca > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing ACME= Application > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= Session: 3DBCD2FB21ADFDD04ADC518C97AA07B4 > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= Principal: GenericPrincipal[ipara(Certificate Manager Agents,Enterprise AC= ME Administrators,Registration Manager Agents,)] > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= Principal: ipara > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= Roles: > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= - Certificate Manager Agents > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= - Enterprise ACME Administrators > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: ACMELoginService:= - Registration Manager Agents > 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: sea= rch ou=3Dconfig,ou=3Dacme,o=3Dipaca > 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: ACMEReque= stFilter: ACME service is disabled > = > = > Things I've observed on fresh install, which I've implemented on my pro= duction > (it changed nothing, provided here for documentation only): > = > # in /etc/pki/pki-tomcat/ca/CS.cfg: > - added lines: > features.authority.description=3DLightweight CAs > features.authority.enabled=3Dtrue > features.authority.version=3D1.0 > = > - 36 profile.* lines were missing; carefully added them, for example: > profile.AdminCert.class_id=3DcaEnrollImpl > profile.AdminCert.config=3D/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminC= ert.cfg > = > - also copied a long line starting with profile.listprofile.list=3D > = > - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 file= s, while > fresh install had over 90. I've copied missing ones from /usr/share/pki= /ca/profiles/ca/ > = > # in LDAP > - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; ad= ded on prod > uniqueMember: uid=3Dpkidbuser,ou=3DPeople,o=3Dipaca > - pkidbuser had 3 userCertificate: entries, two of them were expired; rem= oved those > = >=20 --===============0748244823270811025==-- From edewata at redhat.com Fri Nov 5 01:45:52 2021 Content-Type: multipart/mixed; boundary="===============5490608945445249941==" MIME-Version: 1.0 From: Endi Dewata To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Thu, 04 Nov 2021 20:45:17 -0500 Message-ID: In-Reply-To: 01772f27-a8c6-551a-67ca-de3df68e61b5@redhat.com --===============5490608945445249941== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 4, 2021 at 12:32 PM Rob Crittenden via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > Tomasz Torcz via FreeIPA-users wrote: > > On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users > wrote: > >> On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < > >> freeipa-users(a)lists.fedorahosted.org> wrote: > >> > >>> Tomasz Torcz via FreeIPA-users wrote: > >>>>> ACME also has a realm configuration: > >>>>> > >>> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring_ACME_Realm.md > >>>>> > >>> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring-ACME-with-DS-Realm.adoc > >>>>> so there could be an issue there. > >>>> > >> > >> But IIRC in IPA case it's configured to reuse the internaldb connection > >> defined in CS.cfg so these params don't need to be specified again. > >> Is there a working IPA instance with ACME that can be compared > >> against? > > > > So I did a clean install of Fedora 34 and FreeIPA. Clean install works > > as expected. I did comparison between fresh and mine install, > > there were discrepancies I mostly fixed, but it didn't change my > > problem. > > Failure looks like that in logs (pki-tomcat/acme/debug-.log): > > > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by > cert: > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: > ou=3Dpeople,o=3Dipaca > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: > description=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIP= A RA,O=3D > PIPEBREAKER.PL > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: > uid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: > Realm.authenticate() returned false > > Yeah, I noticed this in your logs as well. I have no insight into what > PKI does to authenticate beyond the things you've already checked. We > know that this cert is ok because you can authenticate to the CA using > it in other ways. It would be nice if they logged some reason for the > failure to authenticate but I'm not sure how to get that. > > rob > > > > > > > While on _fresh install_ correct log looks like: > > > > 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating > user with client certificate > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by > cert: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: > ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: > description=3D2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN= =3DIPA > RA,O=3DIPADEV.PIPEBREAKER.PL > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: > uid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user > roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: > ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: > uniqueMember=3Duid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DCertific= ate > Manager Agents,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - > cn=3DRegistration Manager Agents,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DEnterpri= se > ACME Administrators,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing > ACMEApplication > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Session: 3DBCD2FB21ADFDD04ADC518C97AA07B4 > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Principal: GenericPrincipal[ipara(Certificate Manager > Agents,Enterprise ACME Administrators,Registration Manager Agents,)] > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Principal: ipara > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Certificate Manager Agents > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Enterprise ACME Administrators > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Registration Manager Agents > > 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: > search ou=3Dconfig,ou=3Dacme,o=3Dipaca > > 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: > ACMERequestFilter: ACME service is disabled > > > > > > Things I've observed on fresh install, which I've implemented on my > production > > (it changed nothing, provided here for documentation only): > > > > # in /etc/pki/pki-tomcat/ca/CS.cfg: > > - added lines: > > features.authority.description=3DLightweight CAs > > features.authority.enabled=3Dtrue > > features.authority.version=3D1.0 > > > > - 36 profile.* lines were missing; carefully added them, for example: > > profile.AdminCert.class_id=3DcaEnrollImpl > > > profile.AdminCert.config=3D/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCe= rt.cfg > > > > - also copied a long line starting with profile.listprofile.list=3D > > > > - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 > files, while > > fresh install had over 90. I've copied missing ones from > /usr/share/pki/ca/profiles/ca/ > > > > # in LDAP > > - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; > added on prod > > uniqueMember: uid=3Dpkidbuser,ou=3DPeople,o=3Dipaca > > - pkidbuser had 3 userCertificate: entries, two of them were expired; > removed those > I added some log messages into this file if you want to try again: https://github.com/edewata/pki/blob/debug-v10.10/base/acme/src/main/java/or= g/dogtagpki/acme/realm/LDAPRealm.java The build is available from this repo: https://copr.fedorainfracloud.org/coprs/edewata/pki-10.10/builds/ -- = Endi S. Dewata On Thu, Nov 4, 2021 at 12:32 PM Rob Crittenden via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > Tomasz Torcz via FreeIPA-users wrote: > > On Mon, Oct 25, 2021 at 10:09:56AM -0500, Endi Dewata via FreeIPA-users > wrote: > >> On Mon, Oct 25, 2021 at 7:42 AM Rob Crittenden via FreeIPA-users < > >> freeipa-users(a)lists.fedorahosted.org> wrote: > >> > >>> Tomasz Torcz via FreeIPA-users wrote: > >>>>> ACME also has a realm configuration: > >>>>> > >>> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring_ACME_Realm.md > >>>>> > >>> > https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Confi= guring-ACME-with-DS-Realm.adoc > >>>>> so there could be an issue there. > >>>> > >> > >> But IIRC in IPA case it's configured to reuse the internaldb connection > >> defined in CS.cfg so these params don't need to be specified again. > >> Is there a working IPA instance with ACME that can be compared > >> against? > > > > So I did a clean install of Fedora 34 and FreeIPA. Clean install works > > as expected. I did comparison between fresh and mine install, > > there were discrepancies I mostly fixed, but it didn't change my > > problem. > > Failure looks like that in logs (pki-tomcat/acme/debug-.log): > > > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: Finding user by > cert: > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - base DN: > ou=3Dpeople,o=3Dipaca > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: - filter: > description=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIP= A RA,O=3D > PIPEBREAKER.PL > > 2021-11-03 18:43:07 [https-jsse-nio-8443-exec-12] INFO: User: > uid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-11-03 18:43:08 [https-jsse-nio-8443-exec-12] FINE: > Realm.authenticate() returned false > > Yeah, I noticed this in your logs as well. I have no insight into what > PKI does to authenticate beyond the things you've already checked. We > know that this cert is ok because you can authenticate to the CA using > it in other ways. It would be nice if they logged some reason for the > failure to authenticate but I'm not sure how to get that. > > rob > > > > > > > While on _fresh install_ correct log looks like: > > > > 2021-10-31 13:51:47 [https-jsse-nio-8443-exec-13] INFO: Authenticating > user with client certificate > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Finding user by > cert: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: > ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: > description=3D2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN= =3DIPA > RA,O=3DIPADEV.PIPEBREAKER.PL > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: User: > uid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Getting user > roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - base DN: > ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - filter: > uniqueMember=3Duid=3Dipara,ou=3Dpeople,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DCertific= ate > Manager Agents,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - > cn=3DRegistration Manager Agents,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: - cn=3DEnterpri= se > ACME Administrators,ou=3Dgroups,o=3Dipaca > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: Initializing > ACMEApplication > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Session: 3DBCD2FB21ADFDD04ADC518C97AA07B4 > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Principal: GenericPrincipal[ipara(Certificate Manager > Agents,Enterprise ACME Administrators,Registration Manager Agents,)] > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Principal: ipara > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: Roles: > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Certificate Manager Agents > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Enterprise ACME Administrators > > 2021-10-31 13:51:48 [https-jsse-nio-8443-exec-13] INFO: > ACMELoginService: - Registration Manager Agents > > 2021-10-31 13:51:48 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: LDAP: > search ou=3Dconfig,ou=3Dacme,o=3Dipaca > > 2021-10-31 13:51:49 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO: > ACMERequestFilter: ACME service is disabled > > > > > > Things I've observed on fresh install, which I've implemented on my > production > > (it changed nothing, provided here for documentation only): > > > > # in /etc/pki/pki-tomcat/ca/CS.cfg: > > - added lines: > > features.authority.description=3DLightweight CAs > > features.authority.enabled=3Dtrue > > features.authority.version=3D1.0 > > > > - 36 profile.* lines were missing; carefully added them, for example: > > profile.AdminCert.class_id=3DcaEnrollImpl > > > profile.AdminCert.config=3D/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCe= rt.cfg > > > > - also copied a long line starting with profile.listprofile.list=3D > > > > - /var/lib/pki/pki-tomcat/ca/profiles/ca on prod server contained 74 > files, while > > fresh install had over 90. I've copied missing ones from > /usr/share/pki/ca/profiles/ca/ > > > > # in LDAP > > - ipaca / groups / Certificate Manager Agents had entry for pkidbuser; > added on prod > > uniqueMember: uid=3Dpkidbuser,ou=3DPeople,o=3Dipaca > > - pkidbuser had 3 userCertificate: entries, two of them were expired; > removed those > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)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(a)lists.fedora= hosted.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- = Endi S. Dewata --===============5490608945445249941== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIE5vdiA0LCAyMDIxIGF0IDEyOjMyIFBNIFJvYiBDcml0 dGVuZGVuIHZpYSBGcmVlSVBBLXVzZXJzICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZWlwYS11c2Vy c0BsaXN0cy5mZWRvcmFob3N0ZWQub3JnIj5mcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3Rl ZC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPlRvbWFzeiBUb3JjeiB2aWEgRnJl ZUlQQS11c2VycyB3cm90ZTo8YnI+CiZndDsgT24gTW9uLCBPY3QgMjUsIDIwMjEgYXQgMTA6MDk6 NTZBTSAtMDUwMCwgRW5kaSBEZXdhdGEgdmlhIEZyZWVJUEEtdXNlcnMgd3JvdGU6PGJyPgomZ3Q7 Jmd0OyBPbiBNb24sIE9jdCAyNSwgMjAyMSBhdCA3OjQyIEFNIFJvYiBDcml0dGVuZGVuIHZpYSBG cmVlSVBBLXVzZXJzICZsdDs8YnI+CiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpmcmVlaXBhLXVz ZXJzQGxpc3RzLmZlZG9yYWhvc3RlZC5vcmciIHRhcmdldD0iX2JsYW5rIj5mcmVlaXBhLXVzZXJz QGxpc3RzLmZlZG9yYWhvc3RlZC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+CiZndDsmZ3Q7PGJyPgom Z3Q7Jmd0OyZndDsgVG9tYXN6IFRvcmN6IHZpYSBGcmVlSVBBLXVzZXJzIHdyb3RlOjxicj4KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQUNNRSBhbHNvIGhhcyBhIHJlYWxtIGNvbmZpZ3VyYXRpb246PGJy PgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2Fj bWUvQ29uZmlndXJpbmdfQUNNRV9SZWFsbS5tZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9tYXN0ZXIvZG9jcy9p bnN0YWxsYXRpb24vYWNtZS9Db25maWd1cmluZ19BQ01FX1JlYWxtLm1kPC9hPjxicj4KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vZG9ndGFncGtpL3BraS9ibG9iL21hc3Rlci9kb2NzL2luc3RhbGxhdGlvbi9hY21lL0NvbmZp Z3VyaW5nLUFDTUUtd2l0aC1EUy1SZWFsbS5hZG9jIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZG9ndGFncGtpL3BraS9ibG9iL21hc3Rlci9kb2Nz L2luc3RhbGxhdGlvbi9hY21lL0NvbmZpZ3VyaW5nLUFDTUUtd2l0aC1EUy1SZWFsbS5hZG9jPC9h Pjxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc28gdGhlcmUgY291bGQgYmUgYW4gaXNzdWUgdGhl cmUuPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgQnV0IElJ UkMgaW4gSVBBIGNhc2UgaXQmIzM5O3MgY29uZmlndXJlZCB0byByZXVzZSB0aGUgaW50ZXJuYWxk YiBjb25uZWN0aW9uPGJyPgomZ3Q7Jmd0OyBkZWZpbmVkIGluIENTLmNmZyBzbyB0aGVzZSBwYXJh bXMgZG9uJiMzOTt0IG5lZWQgdG8gYmUgc3BlY2lmaWVkIGFnYWluLjxicj4KJmd0OyZndDsgSXMg dGhlcmUgYSB3b3JraW5nIElQQSBpbnN0YW5jZSB3aXRoIEFDTUUgdGhhdCBjYW4gYmUgY29tcGFy ZWQ8YnI+CiZndDsmZ3Q7IGFnYWluc3Q/PGJyPgomZ3Q7IDxicj4KJmd0O8KgIMKgU28gSSBkaWQg YSBjbGVhbiBpbnN0YWxsIG9mIEZlZG9yYSAzNCBhbmQgRnJlZUlQQS4gQ2xlYW4gaW5zdGFsbCB3 b3Jrczxicj4KJmd0OyBhcyBleHBlY3RlZC7CoCBJIGRpZCBjb21wYXJpc29uIGJldHdlZW4gZnJl c2ggYW5kIG1pbmUgaW5zdGFsbCw8YnI+CiZndDsgdGhlcmUgd2VyZSBkaXNjcmVwYW5jaWVzIEkg bW9zdGx5IGZpeGVkLCBidXQgaXQgZGlkbiYjMzk7dCBjaGFuZ2UgbXk8YnI+CiZndDsgcHJvYmxl bS48YnI+CiZndDvCoCDCoEZhaWx1cmUgbG9va3MgbGlrZSB0aGF0IGluIGxvZ3MgKHBraS10b21j YXQvYWNtZS9kZWJ1Zy0mbHQ7ZGF0YSZndDsubG9nKTo8YnI+CiZndDsgPGJyPgomZ3Q7IDIwMjEt MTEtMDMgMTg6NDM6MDcgW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xMl0gSU5GTzogRmluZGlu ZyB1c2VyIGJ5IGNlcnQ6PGJyPgomZ3Q7IDIwMjEtMTEtMDMgMTg6NDM6MDcgW2h0dHBzLWpzc2Ut bmlvLTg0NDMtZXhlYy0xMl0gSU5GTzogLSBiYXNlIEROOiBvdT1wZW9wbGUsbz1pcGFjYTxicj4K Jmd0OyAyMDIxLTExLTAzIDE4OjQzOjA3IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTJdIElO Rk86IC0gZmlsdGVyOiBkZXNjcmlwdGlvbj0yOzEwNTtDTj1DZXJ0aWZpY2F0ZSBBdXRob3JpdHks Tz08YSBocmVmPSJodHRwOi8vUElQRUJSRUFLRVIuUEwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPlBJUEVCUkVBS0VSLlBMPC9hPjtDTj1JUEEgUkEsTz08YSBocmVmPSJodHRwOi8v UElQRUJSRUFLRVIuUEwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPlBJUEVCUkVB S0VSLlBMPC9hPjxicj4KJmd0OyAyMDIxLTExLTAzIDE4OjQzOjA3IFtodHRwcy1qc3NlLW5pby04 NDQzLWV4ZWMtMTJdIElORk86IFVzZXI6IHVpZD1pcGFyYSxvdT1wZW9wbGUsbz1pcGFjYTxicj4K Jmd0OyAyMDIxLTExLTAzIDE4OjQzOjA4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTJdIEZJ TkU6wqAgwqBSZWFsbS5hdXRoZW50aWNhdGUoKSByZXR1cm5lZCBmYWxzZTxicj4KPGJyPgpZZWFo LCBJIG5vdGljZWQgdGhpcyBpbiB5b3VyIGxvZ3MgYXMgd2VsbC4gSSBoYXZlIG5vIGluc2lnaHQg aW50byB3aGF0PGJyPgpQS0kgZG9lcyB0byBhdXRoZW50aWNhdGUgYmV5b25kIHRoZSB0aGluZ3Mg eW91JiMzOTt2ZSBhbHJlYWR5IGNoZWNrZWQuIFdlPGJyPgprbm93IHRoYXQgdGhpcyBjZXJ0IGlz IG9rIGJlY2F1c2UgeW91IGNhbiBhdXRoZW50aWNhdGUgdG8gdGhlIENBIHVzaW5nPGJyPgppdCBp biBvdGhlciB3YXlzLiBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZXkgbG9nZ2VkIHNvbWUgcmVhc29u IGZvciB0aGU8YnI+CmZhaWx1cmUgdG8gYXV0aGVudGljYXRlIGJ1dCBJJiMzOTttIG5vdCBzdXJl IGhvdyB0byBnZXQgdGhhdC48YnI+Cjxicj4Kcm9iPGJyPgo8YnI+CiZndDsgPGJyPgomZ3Q7IDxi cj4KJmd0OyBXaGlsZSBvbiBfZnJlc2ggaW5zdGFsbF8gY29ycmVjdCBsb2cgbG9va3MgbGlrZTo8 YnI+CiZndDsgPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDcgW2h0dHBzLWpzc2UtbmlvLTg0 NDMtZXhlYy0xM10gSU5GTzogQXV0aGVudGljYXRpbmcgdXNlciB3aXRoIGNsaWVudCBjZXJ0aWZp Y2F0ZTxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4 ZWMtMTNdIElORk86IEZpbmRpbmcgdXNlciBieSBjZXJ0Ojxicj4KJmd0OyAyMDIxLTEwLTMxIDEz OjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IC0gYmFzZSBETjogb3U9 cGVvcGxlLG89aXBhY2E8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1u aW8tODQ0My1leGVjLTEzXSBJTkZPOiAtIGZpbHRlcjogZGVzY3JpcHRpb249Mjs3O0NOPUNlcnRp ZmljYXRlIEF1dGhvcml0eSxPPTxhIGhyZWY9Imh0dHA6Ly9JUEFERVYuUElQRUJSRUFLRVIuUEwi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPklQQURFVi5QSVBFQlJFQUtFUi5QTDwv YT47Q049SVBBIFJBLE89PGEgaHJlZj0iaHR0cDovL0lQQURFVi5QSVBFQlJFQUtFUi5QTCIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+SVBBREVWLlBJUEVCUkVBS0VSLlBMPC9hPjxi cj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNd IElORk86IFVzZXI6IHVpZD1pcGFyYSxvdT1wZW9wbGUsbz1pcGFjYTxicj4KJmd0OyAyMDIxLTEw LTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IEdldHRpbmcg dXNlciByb2xlczo8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8t ODQ0My1leGVjLTEzXSBJTkZPOiAtIGJhc2UgRE46IG91PWdyb3VwcyxvPWlwYWNhPGJyPgomZ3Q7 IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzog LSBmaWx0ZXI6IHVuaXF1ZU1lbWJlcj11aWQ9aXBhcmEsb3U9cGVvcGxlLG89aXBhY2E8YnI+CiZn dDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVjLTEzXSBJTkZP OiBSb2xlczo8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8tODQ0 My1leGVjLTEzXSBJTkZPOiAtIGNuPUNlcnRpZmljYXRlIE1hbmFnZXIgQWdlbnRzLG91PWdyb3Vw cyxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0 NDMtZXhlYy0xM10gSU5GTzogLSBjbj1SZWdpc3RyYXRpb24gTWFuYWdlciBBZ2VudHMsb3U9Z3Jv dXBzLG89aXBhY2E8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8t ODQ0My1leGVjLTEzXSBJTkZPOiAtIGNuPUVudGVycHJpc2UgQUNNRSBBZG1pbmlzdHJhdG9ycyxv dT1ncm91cHMsbz1pcGFjYTxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3Nl LW5pby04NDQzLWV4ZWMtMTNdIElORk86IEluaXRpYWxpemluZyBBQ01FQXBwbGljYXRpb248YnI+ CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVjLTEzXSBJ TkZPOiBBQ01FTG9naW5TZXJ2aWNlOiBTZXNzaW9uOiAzREJDRDJGQjIxQURGREQwNEFEQzUxOEM5 N0FBMDdCNDxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQz LWV4ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IFByaW5jaXBhbDogR2VuZXJpY1ByaW5j aXBhbFtpcGFyYShDZXJ0aWZpY2F0ZSBNYW5hZ2VyIEFnZW50cyxFbnRlcnByaXNlIEFDTUUgQWRt aW5pc3RyYXRvcnMsUmVnaXN0cmF0aW9uIE1hbmFnZXIgQWdlbnRzLCldPGJyPgomZ3Q7IDIwMjEt MTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogQUNNRUxv Z2luU2VydmljZTogUHJpbmNpcGFsOiBpcGFyYTxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4 IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IFJv bGVzOjxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4 ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IC0gQ2VydGlmaWNhdGUgTWFuYWdlciBBZ2Vu dHM8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVj LTEzXSBJTkZPOiBBQ01FTG9naW5TZXJ2aWNlOiAtIEVudGVycHJpc2UgQUNNRSBBZG1pbmlzdHJh dG9yczxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4 ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IC0gUmVnaXN0cmF0aW9uIE1hbmFnZXIgQWdl bnRzPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2FqcC1uaW8tMDowOjA6MDowOjA6MDox LTgwMDktZXhlYy0xXSBJTkZPOiBMREFQOiBzZWFyY2ggb3U9Y29uZmlnLG91PWFjbWUsbz1pcGFj YTxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ5IFthanAtbmlvLTA6MDowOjA6MDowOjA6MS04 MDA5LWV4ZWMtMV0gSU5GTzogQUNNRVJlcXVlc3RGaWx0ZXI6IEFDTUUgc2VydmljZSBpcyBkaXNh YmxlZDxicj4KJmd0OyA8YnI+CiZndDsgPGJyPgomZ3Q7wqAgwqBUaGluZ3MgSSYjMzk7dmUgb2Jz ZXJ2ZWQgb24gZnJlc2ggaW5zdGFsbCwgd2hpY2ggSSYjMzk7dmUgaW1wbGVtZW50ZWQgb24gbXkg cHJvZHVjdGlvbjxicj4KJmd0OyAoaXQgY2hhbmdlZCBub3RoaW5nLCBwcm92aWRlZCBoZXJlIGZv ciBkb2N1bWVudGF0aW9uIG9ubHkpOjxicj4KJmd0OyA8YnI+CiZndDsgIyBpbiAvZXRjL3BraS9w a2ktdG9tY2F0L2NhL0NTLmNmZzo8YnI+CiZndDsgLSBhZGRlZCBsaW5lczo8YnI+CiZndDvCoCBm ZWF0dXJlcy5hdXRob3JpdHkuZGVzY3JpcHRpb249TGlnaHR3ZWlnaHQgQ0FzPGJyPgomZ3Q7wqAg ZmVhdHVyZXMuYXV0aG9yaXR5LmVuYWJsZWQ9dHJ1ZTxicj4KJmd0O8KgIGZlYXR1cmVzLmF1dGhv cml0eS52ZXJzaW9uPTEuMDxicj4KJmd0OyA8YnI+CiZndDsgLSAzNiBwcm9maWxlLiogbGluZXMg d2VyZSBtaXNzaW5nOyBjYXJlZnVsbHkgYWRkZWQgdGhlbSwgZm9yIGV4YW1wbGU6PGJyPgomZ3Q7 wqAgcHJvZmlsZS5BZG1pbkNlcnQuY2xhc3NfaWQ9Y2FFbnJvbGxJbXBsPGJyPgomZ3Q7wqAgcHJv ZmlsZS5BZG1pbkNlcnQuY29uZmlnPS92YXIvbGliL3BraS9wa2ktdG9tY2F0L2NhL3Byb2ZpbGVz L2NhL0FkbWluQ2VydC5jZmc8YnI+CiZndDsgPGJyPgomZ3Q7IC0gYWxzbyBjb3BpZWQgYSBsb25n IGxpbmUgc3RhcnRpbmcgd2l0aCBwcm9maWxlLmxpc3Rwcm9maWxlLmxpc3Q9PGJyPgomZ3Q7IDxi cj4KJmd0OyAtIC92YXIvbGliL3BraS9wa2ktdG9tY2F0L2NhL3Byb2ZpbGVzL2NhIG9uIHByb2Qg c2VydmVyIGNvbnRhaW5lZCA3NCBmaWxlcywgd2hpbGU8YnI+CiZndDvCoCDCoGZyZXNoIGluc3Rh bGwgaGFkIG92ZXIgOTAuIEkmIzM5O3ZlIGNvcGllZCBtaXNzaW5nIG9uZXMgZnJvbSAvdXNyL3No YXJlL3BraS9jYS9wcm9maWxlcy9jYS88YnI+CiZndDsgPGJyPgomZ3Q7ICMgaW4gTERBUDxicj4K Jmd0OyAtIGlwYWNhIC8gZ3JvdXBzIC8gQ2VydGlmaWNhdGUgTWFuYWdlciBBZ2VudHMgaGFkIGVu dHJ5IGZvciBwa2lkYnVzZXI7IGFkZGVkIG9uIHByb2Q8YnI+CiZndDvCoCDCoHVuaXF1ZU1lbWJl cjogdWlkPXBraWRidXNlcixvdT1QZW9wbGUsbz1pcGFjYTxicj4KJmd0OyAtIHBraWRidXNlciBo YWQgMyB1c2VyQ2VydGlmaWNhdGU6IGVudHJpZXMsIHR3byBvZiB0aGVtIHdlcmUgZXhwaXJlZDsg cmVtb3ZlZCB0aG9zZTxicj48L2Jsb2NrcXVvdGU+PGRpdj7CoDwvZGl2PjxkaXY+SSBhZGRlZCBz b21lIGxvZyBtZXNzYWdlcyBpbnRvIHRoaXMgZmlsZSBpZiB5b3Ugd2FudCB0byB0cnkgYWdhaW46 PGJyPjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2VkZXdhdGEvcGtpL2Js b2IvZGVidWctdjEwLjEwL2Jhc2UvYWNtZS9zcmMvbWFpbi9qYXZhL29yZy9kb2d0YWdwa2kvYWNt ZS9yZWFsbS9MREFQUmVhbG0uamF2YSI+aHR0cHM6Ly9naXRodWIuY29tL2VkZXdhdGEvcGtpL2Js b2IvZGVidWctdjEwLjEwL2Jhc2UvYWNtZS9zcmMvbWFpbi9qYXZhL29yZy9kb2d0YWdwa2kvYWNt ZS9yZWFsbS9MREFQUmVhbG0uamF2YTwvYT48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBi dWlsZCBpcyBhdmFpbGFibGUgZnJvbSB0aGlzIHJlcG86PGJyPjwvZGl2PjwvZGl2PjxhIGhyZWY9 Imh0dHBzOi8vY29wci5mZWRvcmFpbmZyYWNsb3VkLm9yZy9jb3Bycy9lZGV3YXRhL3BraS0xMC4x MC9idWlsZHMvIj5odHRwczovL2NvcHIuZmVkb3JhaW5mcmFjbG91ZC5vcmcvY29wcnMvZWRld2F0 YS9wa2ktMTAuMTAvYnVpbGRzLzwvYT48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj48ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIj48ZGl2IGRpcj0ibHRyIj48ZGl2PkVuZGkg Uy4gRGV3YXRhPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgTm92IDQs IDIwMjEgYXQgMTI6MzIgUE0gUm9iIENyaXR0ZW5kZW4gdmlhIEZyZWVJUEEtdXNlcnMgJmx0Ozxh IGhyZWY9Im1haWx0bzpmcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3RlZC5vcmciPmZyZWVp cGEtdXNlcnNAbGlzdHMuZmVkb3JhaG9zdGVkLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+VG9tYXN6IFRvcmN6IHZpYSBGcmVlSVBBLXVzZXJzIHdyb3RlOjxicj4KJmd0OyBPbiBN b24sIE9jdCAyNSwgMjAyMSBhdCAxMDowOTo1NkFNIC0wNTAwLCBFbmRpIERld2F0YSB2aWEgRnJl ZUlQQS11c2VycyB3cm90ZTo8YnI+CiZndDsmZ3Q7IE9uIE1vbiwgT2N0IDI1LCAyMDIxIGF0IDc6 NDIgQU0gUm9iIENyaXR0ZW5kZW4gdmlhIEZyZWVJUEEtdXNlcnMgJmx0Ozxicj4KJmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOmZyZWVpcGEtdXNlcnNAbGlzdHMuZmVkb3JhaG9zdGVkLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmZyZWVpcGEtdXNlcnNAbGlzdHMuZmVkb3JhaG9zdGVkLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyBUb21hc3ogVG9yY3ogdmlhIEZy ZWVJUEEtdXNlcnMgd3JvdGU6PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBQ01FIGFsc28gaGFz IGEgcmVhbG0gY29uZmlndXJhdGlvbjo8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7 Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2RvZ3RhZ3BraS9wa2kvYmxvYi9t YXN0ZXIvZG9jcy9pbnN0YWxsYXRpb24vYWNtZS9Db25maWd1cmluZ19BQ01FX1JlYWxtLm1kIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZG9ndGFn cGtpL3BraS9ibG9iL21hc3Rlci9kb2NzL2luc3RhbGxhdGlvbi9hY21lL0NvbmZpZ3VyaW5nX0FD TUVfUmVhbG0ubWQ8L2E+PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2Rv Y3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmctQUNNRS13aXRoLURTLVJlYWxtLmFkb2Mi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb2d0 YWdwa2kvcGtpL2Jsb2IvbWFzdGVyL2RvY3MvaW5zdGFsbGF0aW9uL2FjbWUvQ29uZmlndXJpbmct QUNNRS13aXRoLURTLVJlYWxtLmFkb2M8L2E+PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzbyB0 aGVyZSBjb3VsZCBiZSBhbiBpc3N1ZSB0aGVyZS48YnI+CiZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZn dDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBCdXQgSUlSQyBpbiBJUEEgY2FzZSBpdCYjMzk7cyBjb25maWd1 cmVkIHRvIHJldXNlIHRoZSBpbnRlcm5hbGRiIGNvbm5lY3Rpb248YnI+CiZndDsmZ3Q7IGRlZmlu ZWQgaW4gQ1MuY2ZnIHNvIHRoZXNlIHBhcmFtcyBkb24mIzM5O3QgbmVlZCB0byBiZSBzcGVjaWZp ZWQgYWdhaW4uPGJyPgomZ3Q7Jmd0OyBJcyB0aGVyZSBhIHdvcmtpbmcgSVBBIGluc3RhbmNlIHdp dGggQUNNRSB0aGF0IGNhbiBiZSBjb21wYXJlZDxicj4KJmd0OyZndDsgYWdhaW5zdD88YnI+CiZn dDsgPGJyPgomZ3Q7wqAgwqBTbyBJIGRpZCBhIGNsZWFuIGluc3RhbGwgb2YgRmVkb3JhIDM0IGFu ZCBGcmVlSVBBLiBDbGVhbiBpbnN0YWxsIHdvcmtzPGJyPgomZ3Q7IGFzIGV4cGVjdGVkLsKgIEkg ZGlkIGNvbXBhcmlzb24gYmV0d2VlbiBmcmVzaCBhbmQgbWluZSBpbnN0YWxsLDxicj4KJmd0OyB0 aGVyZSB3ZXJlIGRpc2NyZXBhbmNpZXMgSSBtb3N0bHkgZml4ZWQsIGJ1dCBpdCBkaWRuJiMzOTt0 IGNoYW5nZSBteTxicj4KJmd0OyBwcm9ibGVtLjxicj4KJmd0O8KgIMKgRmFpbHVyZSBsb29rcyBs aWtlIHRoYXQgaW4gbG9ncyAocGtpLXRvbWNhdC9hY21lL2RlYnVnLSZsdDtkYXRhJmd0Oy5sb2cp Ojxicj4KJmd0OyA8YnI+CiZndDsgMjAyMS0xMS0wMyAxODo0MzowNyBbaHR0cHMtanNzZS1uaW8t ODQ0My1leGVjLTEyXSBJTkZPOiBGaW5kaW5nIHVzZXIgYnkgY2VydDo8YnI+CiZndDsgMjAyMS0x MS0wMyAxODo0MzowNyBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVjLTEyXSBJTkZPOiAtIGJhc2Ug RE46IG91PXBlb3BsZSxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEtMTEtMDMgMTg6NDM6MDcgW2h0dHBz LWpzc2UtbmlvLTg0NDMtZXhlYy0xMl0gSU5GTzogLSBmaWx0ZXI6IGRlc2NyaXB0aW9uPTI7MTA1 O0NOPUNlcnRpZmljYXRlIEF1dGhvcml0eSxPPTxhIGhyZWY9Imh0dHA6Ly9QSVBFQlJFQUtFUi5Q TCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+UElQRUJSRUFLRVIuUEw8L2E+O0NO PUlQQSBSQSxPPTxhIGhyZWY9Imh0dHA6Ly9QSVBFQlJFQUtFUi5QTCIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+UElQRUJSRUFLRVIuUEw8L2E+PGJyPgomZ3Q7IDIwMjEtMTEtMDMg MTg6NDM6MDcgW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xMl0gSU5GTzogVXNlcjogdWlkPWlw YXJhLG91PXBlb3BsZSxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEtMTEtMDMgMTg6NDM6MDggW2h0dHBz LWpzc2UtbmlvLTg0NDMtZXhlYy0xMl0gRklORTrCoCDCoFJlYWxtLmF1dGhlbnRpY2F0ZSgpIHJl dHVybmVkIGZhbHNlPGJyPgo8YnI+ClllYWgsIEkgbm90aWNlZCB0aGlzIGluIHlvdXIgbG9ncyBh cyB3ZWxsLiBJIGhhdmUgbm8gaW5zaWdodCBpbnRvIHdoYXQ8YnI+ClBLSSBkb2VzIHRvIGF1dGhl bnRpY2F0ZSBiZXlvbmQgdGhlIHRoaW5ncyB5b3UmIzM5O3ZlIGFscmVhZHkgY2hlY2tlZC4gV2U8 YnI+Cmtub3cgdGhhdCB0aGlzIGNlcnQgaXMgb2sgYmVjYXVzZSB5b3UgY2FuIGF1dGhlbnRpY2F0 ZSB0byB0aGUgQ0EgdXNpbmc8YnI+Cml0IGluIG90aGVyIHdheXMuIEl0IHdvdWxkIGJlIG5pY2Ug aWYgdGhleSBsb2dnZWQgc29tZSByZWFzb24gZm9yIHRoZTxicj4KZmFpbHVyZSB0byBhdXRoZW50 aWNhdGUgYnV0IEkmIzM5O20gbm90IHN1cmUgaG93IHRvIGdldCB0aGF0Ljxicj4KPGJyPgpyb2I8 YnI+Cjxicj4KJmd0OyA8YnI+CiZndDsgPGJyPgomZ3Q7IFdoaWxlIG9uIF9mcmVzaCBpbnN0YWxs XyBjb3JyZWN0IGxvZyBsb29rcyBsaWtlOjxicj4KJmd0OyA8YnI+CiZndDsgMjAyMS0xMC0zMSAx Mzo1MTo0NyBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVjLTEzXSBJTkZPOiBBdXRoZW50aWNhdGlu ZyB1c2VyIHdpdGggY2xpZW50IGNlcnRpZmljYXRlPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6 NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogRmluZGluZyB1c2VyIGJ5IGNl cnQ6PGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhl Yy0xM10gSU5GTzogLSBiYXNlIEROOiBvdT1wZW9wbGUsbz1pcGFjYTxicj4KJmd0OyAyMDIxLTEw LTMxIDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IC0gZmlsdGVy OiBkZXNjcmlwdGlvbj0yOzc7Q049Q2VydGlmaWNhdGUgQXV0aG9yaXR5LE89PGEgaHJlZj0iaHR0 cDovL0lQQURFVi5QSVBFQlJFQUtFUi5QTCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+SVBBREVWLlBJUEVCUkVBS0VSLlBMPC9hPjtDTj1JUEEgUkEsTz08YSBocmVmPSJodHRwOi8v SVBBREVWLlBJUEVCUkVBS0VSLlBMIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5J UEFERVYuUElQRUJSRUFLRVIuUEw8L2E+PGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0 dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogVXNlcjogdWlkPWlwYXJhLG91PXBlb3Bs ZSxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0 NDMtZXhlYy0xM10gSU5GTzogR2V0dGluZyB1c2VyIHJvbGVzOjxicj4KJmd0OyAyMDIxLTEwLTMx IDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IC0gYmFzZSBETjog b3U9Z3JvdXBzLG89aXBhY2E8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNz ZS1uaW8tODQ0My1leGVjLTEzXSBJTkZPOiAtIGZpbHRlcjogdW5pcXVlTWVtYmVyPXVpZD1pcGFy YSxvdT1wZW9wbGUsbz1pcGFjYTxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRwcy1q c3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IFJvbGVzOjxicj4KJmd0OyAyMDIxLTEwLTMxIDEz OjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IC0gY249Q2VydGlmaWNh dGUgTWFuYWdlciBBZ2VudHMsb3U9Z3JvdXBzLG89aXBhY2E8YnI+CiZndDsgMjAyMS0xMC0zMSAx Mzo1MTo0OCBbaHR0cHMtanNzZS1uaW8tODQ0My1leGVjLTEzXSBJTkZPOiAtIGNuPVJlZ2lzdHJh dGlvbiBNYW5hZ2VyIEFnZW50cyxvdT1ncm91cHMsbz1pcGFjYTxicj4KJmd0OyAyMDIxLTEwLTMx IDEzOjUxOjQ4IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IC0gY249RW50ZXJw cmlzZSBBQ01FIEFkbWluaXN0cmF0b3JzLG91PWdyb3VwcyxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEt MTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogSW5pdGlh bGl6aW5nIEFDTUVBcHBsaWNhdGlvbjxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4IFtodHRw cy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IFNlc3Npb246 IDNEQkNEMkZCMjFBREZERDA0QURDNTE4Qzk3QUEwN0I0PGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6 NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogQUNNRUxvZ2luU2Vydmlj ZTogUHJpbmNpcGFsOiBHZW5lcmljUHJpbmNpcGFsW2lwYXJhKENlcnRpZmljYXRlIE1hbmFnZXIg QWdlbnRzLEVudGVycHJpc2UgQUNNRSBBZG1pbmlzdHJhdG9ycyxSZWdpc3RyYXRpb24gTWFuYWdl ciBBZ2VudHMsKV08YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0OCBbaHR0cHMtanNzZS1uaW8t ODQ0My1leGVjLTEzXSBJTkZPOiBBQ01FTG9naW5TZXJ2aWNlOiBQcmluY2lwYWw6IGlwYXJhPGJy PgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10g SU5GTzogQUNNRUxvZ2luU2VydmljZTogUm9sZXM6PGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6 NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogQUNNRUxvZ2luU2VydmljZTog LSBDZXJ0aWZpY2F0ZSBNYW5hZ2VyIEFnZW50czxicj4KJmd0OyAyMDIxLTEwLTMxIDEzOjUxOjQ4 IFtodHRwcy1qc3NlLW5pby04NDQzLWV4ZWMtMTNdIElORk86IEFDTUVMb2dpblNlcnZpY2U6IC0g RW50ZXJwcmlzZSBBQ01FIEFkbWluaXN0cmF0b3JzPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6 NDggW2h0dHBzLWpzc2UtbmlvLTg0NDMtZXhlYy0xM10gSU5GTzogQUNNRUxvZ2luU2VydmljZTog LSBSZWdpc3RyYXRpb24gTWFuYWdlciBBZ2VudHM8YnI+CiZndDsgMjAyMS0xMC0zMSAxMzo1MTo0 OCBbYWpwLW5pby0wOjA6MDowOjA6MDowOjEtODAwOS1leGVjLTFdIElORk86IExEQVA6IHNlYXJj aCBvdT1jb25maWcsb3U9YWNtZSxvPWlwYWNhPGJyPgomZ3Q7IDIwMjEtMTAtMzEgMTM6NTE6NDkg W2FqcC1uaW8tMDowOjA6MDowOjA6MDoxLTgwMDktZXhlYy0xXSBJTkZPOiBBQ01FUmVxdWVzdEZp bHRlcjogQUNNRSBzZXJ2aWNlIGlzIGRpc2FibGVkPGJyPgomZ3Q7IDxicj4KJmd0OyA8YnI+CiZn dDvCoCDCoFRoaW5ncyBJJiMzOTt2ZSBvYnNlcnZlZCBvbiBmcmVzaCBpbnN0YWxsLCB3aGljaCBJ JiMzOTt2ZSBpbXBsZW1lbnRlZCBvbiBteSBwcm9kdWN0aW9uPGJyPgomZ3Q7IChpdCBjaGFuZ2Vk IG5vdGhpbmcsIHByb3ZpZGVkIGhlcmUgZm9yIGRvY3VtZW50YXRpb24gb25seSk6PGJyPgomZ3Q7 IDxicj4KJmd0OyAjIGluIC9ldGMvcGtpL3BraS10b21jYXQvY2EvQ1MuY2ZnOjxicj4KJmd0OyAt IGFkZGVkIGxpbmVzOjxicj4KJmd0O8KgIGZlYXR1cmVzLmF1dGhvcml0eS5kZXNjcmlwdGlvbj1M aWdodHdlaWdodCBDQXM8YnI+CiZndDvCoCBmZWF0dXJlcy5hdXRob3JpdHkuZW5hYmxlZD10cnVl PGJyPgomZ3Q7wqAgZmVhdHVyZXMuYXV0aG9yaXR5LnZlcnNpb249MS4wPGJyPgomZ3Q7IDxicj4K Jmd0OyAtIDM2IHByb2ZpbGUuKiBsaW5lcyB3ZXJlIG1pc3Npbmc7IGNhcmVmdWxseSBhZGRlZCB0 aGVtLCBmb3IgZXhhbXBsZTo8YnI+CiZndDvCoCBwcm9maWxlLkFkbWluQ2VydC5jbGFzc19pZD1j YUVucm9sbEltcGw8YnI+CiZndDvCoCBwcm9maWxlLkFkbWluQ2VydC5jb25maWc9L3Zhci9saWIv cGtpL3BraS10b21jYXQvY2EvcHJvZmlsZXMvY2EvQWRtaW5DZXJ0LmNmZzxicj4KJmd0OyA8YnI+ CiZndDsgLSBhbHNvIGNvcGllZCBhIGxvbmcgbGluZSBzdGFydGluZyB3aXRoIHByb2ZpbGUubGlz dHByb2ZpbGUubGlzdD08YnI+CiZndDsgPGJyPgomZ3Q7IC0gL3Zhci9saWIvcGtpL3BraS10b21j YXQvY2EvcHJvZmlsZXMvY2Egb24gcHJvZCBzZXJ2ZXIgY29udGFpbmVkIDc0IGZpbGVzLCB3aGls ZTxicj4KJmd0O8KgIMKgZnJlc2ggaW5zdGFsbCBoYWQgb3ZlciA5MC4gSSYjMzk7dmUgY29waWVk IG1pc3Npbmcgb25lcyBmcm9tIC91c3Ivc2hhcmUvcGtpL2NhL3Byb2ZpbGVzL2NhLzxicj4KJmd0 OyA8YnI+CiZndDsgIyBpbiBMREFQPGJyPgomZ3Q7IC0gaXBhY2EgLyBncm91cHMgLyBDZXJ0aWZp Y2F0ZSBNYW5hZ2VyIEFnZW50cyBoYWQgZW50cnkgZm9yIHBraWRidXNlcjsgYWRkZWQgb24gcHJv ZDxicj4KJmd0O8KgIMKgdW5pcXVlTWVtYmVyOiB1aWQ9cGtpZGJ1c2VyLG91PVBlb3BsZSxvPWlw YWNhPGJyPgomZ3Q7IC0gcGtpZGJ1c2VyIGhhZCAzIHVzZXJDZXJ0aWZpY2F0ZTogZW50cmllcywg dHdvIG9mIHRoZW0gd2VyZSBleHBpcmVkOyByZW1vdmVkIHRob3NlPGJyPgomZ3Q7IDxicj4KJmd0 OyA8YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PgpGcmVlSVBBLXVzZXJzIG1haWxpbmcgbGlzdCAtLSA8YSBocmVmPSJtYWlsdG86ZnJlZWlwYS11 c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZnJlZWlwYS11c2Vy c0BsaXN0cy5mZWRvcmFob3N0ZWQub3JnPC9hPjxicj4KVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBl bWFpbCB0byA8YSBocmVmPSJtYWlsdG86ZnJlZWlwYS11c2Vycy1sZWF2ZUBsaXN0cy5mZWRvcmFo b3N0ZWQub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZnJlZWlwYS11c2Vycy1sZWF2ZUBsaXN0cy5mZWRv cmFob3N0ZWQub3JnPC9hPjxicj4KRmVkb3JhIENvZGUgb2YgQ29uZHVjdDogPGEgaHJlZj0iaHR0 cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVTL3Byb2plY3QvY29kZS1vZi1jb25kdWN0 LyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kb2NzLmZlZG9yYXBy b2plY3Qub3JnL2VuLVVTL3Byb2plY3QvY29kZS1vZi1jb25kdWN0LzwvYT48YnI+Ckxpc3QgR3Vp ZGVsaW5lczogPGEgaHJlZj0iaHR0cHM6Ly9mZWRvcmFwcm9qZWN0Lm9yZy93aWtpL01haWxpbmdf bGlzdF9ndWlkZWxpbmVzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2ZlZG9yYXByb2plY3Qub3JnL3dpa2kvTWFpbGluZ19saXN0X2d1aWRlbGluZXM8L2E+PGJyPgpM aXN0IEFyY2hpdmVzOiA8YSBocmVmPSJodHRwczovL2xpc3RzLmZlZG9yYWhvc3RlZC5vcmcvYXJj aGl2ZXMvbGlzdC9mcmVlaXBhLXVzZXJzQGxpc3RzLmZlZG9yYWhvc3RlZC5vcmciIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbGlzdHMuZmVkb3JhaG9zdGVkLm9yZy9h cmNoaXZlcy9saXN0L2ZyZWVpcGEtdXNlcnNAbGlzdHMuZmVkb3JhaG9zdGVkLm9yZzwvYT48YnI+ CkRvIG5vdCByZXBseSB0byBzcGFtIG9uIHRoZSBsaXN0LCByZXBvcnQgaXQ6IDxhIGhyZWY9Imh0 dHBzOi8vcGFndXJlLmlvL2ZlZG9yYS1pbmZyYXN0cnVjdHVyZSIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9wYWd1cmUuaW8vZmVkb3JhLWluZnJhc3RydWN0dXJlPC9h Pjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2PjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPjxkaXYgZGlyPSJsdHIiPjxkaXY+RW5k aSBTLiBEZXdhdGE8YnI+PC9kaXY+PC9kaXY+PC9kaXY+Cg== --===============5490608945445249941==-- From tomek at pipebreaker.pl Fri Nov 5 10:41:20 2021 Content-Type: multipart/mixed; boundary="===============3462671967605481583==" MIME-Version: 1.0 From: Tomasz Torcz To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Fri, 05 Nov 2021 11:38:41 +0100 Message-ID: In-Reply-To: CAMv3Fb7-xgSnfJo5-vFv9EudueF9umYkGef_y+y+OGit3jNubw@mail.gmail.com --===============3462671967605481583== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 04, 2021 at 08:45:17PM -0500, Endi Dewata via FreeIPA-users wro= te: > = > I added some log messages into this file if you want to try again: > https://github.com/edewata/pki/blob/debug-v10.10/base/acme/src/main/java/= org/dogtagpki/acme/realm/LDAPRealm.java > = > The build is available from this repo: > https://copr.fedorainfracloud.org/coprs/edewata/pki-10.10/builds/ Thanks=E2=80=A6 For most problems, the root cause is almost always DNS. For IPA, it's almost always certificate ;) Verbose builds produced following logs: 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: LDAP search: 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - base DN: ou=3Dpeo= ple,o=3Dipaca 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - filter: (descript= ion=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O=3DP= IPEBREAKER.PL) 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: User: uid=3Dipara,o= u=3Dpeople,o=3Dipaca 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: Validating cert dat= a in uid=3Dipara,ou=3Dpeople,o=3Dipaca 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] WARNING: User uid=3Dipara= ,ou=3Dpeople,o=3Dipaca has no certificates Impossible! I triple checked that. Let check again and compare with fresh= install: % ldapsearch -h kaitain.pipebreaker.pl -D cn=3Ddirectory\ manager -W -o ld= if-wrap=3Dno \ -b uid=3Dipara,ou=3Dpeople,o=3Dipaca [=E2=80=A6] dn: uid=3Dipara,ou=3Dpeople,o=3Dipaca description: 2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA R= A,O=3DPIPEBREAKER.PL userCertificate;binary:: MIIDajCCAlKgAw=E2=80=A6 [=E2=80=A6] While fresh install gives: dn: uid=3Dipara,ou=3Dpeople,o=3Dipaca description: 2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN=3D= IPA RA,O=3DIPADEV.PIPEBREAKER.PL userCertificate:: MIID/zCCAmegAwIBA=E2=80=A6 There's an additional ";binary" in certificate attribute on my prod serve= r. And I was comparing only base64 encoded part. And that was it. After removing ';binary' from attribute name, `pki-acme-= manage` can authenticate. Thank you very much for patience and assistance! It is always a certificate. -- = Tomasz Torcz =E2=80=9C(=E2=80=A6) today's high-end is tomorrow's = embedded processor.=E2=80=9D tomek(a)pipebreaker.pl =E2=80=94 Mitchell Blank on LKML --===============3462671967605481583==-- From rcritten at redhat.com Fri Nov 5 12:44:48 2021 Content-Type: multipart/mixed; boundary="===============3549921057514851802==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: =?utf-8?q?=5BFreeipa-users=5D_Re=3A_RA_Agent_certificate_authorisation_fa?= =?utf-8?q?ils_=E2=80=93_how_to_debug=3F?= Date: Fri, 05 Nov 2021 08:44:27 -0400 Message-ID: <93ec0888-4a09-d27b-16d6-5a8aec0ce83d@redhat.com> In-Reply-To: YYUJsdqXJ24IlRs0@mother.pipebreaker.pl --===============3549921057514851802== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tomasz Torcz via FreeIPA-users wrote: > On Thu, Nov 04, 2021 at 08:45:17PM -0500, Endi Dewata via FreeIPA-users w= rote: >> >> I added some log messages into this file if you want to try again: >> https://github.com/edewata/pki/blob/debug-v10.10/base/acme/src/main/java= /org/dogtagpki/acme/realm/LDAPRealm.java >> >> The build is available from this repo: >> https://copr.fedorainfracloud.org/coprs/edewata/pki-10.10/builds/ > = > Thanks=E2=80=A6 For most problems, the root cause is almost always DNS. > For IPA, it's almost always certificate ;) > = > Verbose builds produced following logs: > = > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: LDAP search: > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - base DN: ou=3Dp= eople,o=3Dipaca > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: - filter: (descri= ption=3D2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA RA,O= =3DPIPEBREAKER.PL) > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: User: uid=3Dipara= ,ou=3Dpeople,o=3Dipaca > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] INFO: Validating cert d= ata in uid=3Dipara,ou=3Dpeople,o=3Dipaca > 2021-11-05 11:15:14 [https-jsse-nio-8443-exec-26] WARNING: User uid=3Dipa= ra,ou=3Dpeople,o=3Dipaca has no certificates > = > Impossible! I triple checked that. Let check again and compare with fre= sh install: > = > % ldapsearch -h kaitain.pipebreaker.pl -D cn=3Ddirectory\ manager -W -o = ldif-wrap=3Dno \ > -b uid=3Dipara,ou=3Dpeople,o=3Dipaca > = > [=E2=80=A6] > dn: uid=3Dipara,ou=3Dpeople,o=3Dipaca > description: 2;105;CN=3DCertificate Authority,O=3DPIPEBREAKER.PL;CN=3DIPA= RA,O=3DPIPEBREAKER.PL > userCertificate;binary:: MIIDajCCAlKgAw=E2=80=A6 > [=E2=80=A6] > = > = > While fresh install gives: > = > dn: uid=3Dipara,ou=3Dpeople,o=3Dipaca > description: 2;7;CN=3DCertificate Authority,O=3DIPADEV.PIPEBREAKER.PL;CN= =3DIPA RA,O=3DIPADEV.PIPEBREAKER.PL > userCertificate:: MIID/zCCAmegAwIBA=E2=80=A6 > = > There's an additional ";binary" in certificate attribute on my prod ser= ver. And I was comparing > only base64 encoded part. > And that was it. After removing ';binary' from attribute name, `pki-acm= e-manage` can authenticate. > = > Thank you very much for patience and assistance! > = > It is always a certificate. > = That is quite unexpected as the same entry worked in other areas of dogtag. I'm not sure if I can detect this in ipa-healthcheck but I'll take a look. According to https://www.rfc-editor.org/rfc/rfc4522 they should be treated equivalently within the LDAP server since it isn't technically a subtype. Endi, thanks for improving the logging! I hope that can be incorporated into a future build. rob --===============3549921057514851802==--