21 Oct
2021
21 Oct
'21
2:40 a.m.
Hi,
I think error 401 means that the client cert could not be mapped to the user in DS.
Could you check the uid=ipara,ou=people,o=ipaca 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 rcritten@redhat.com wrote:
> 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=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca and
> >> uid=ipara,ou=People,o=ipaca are both uniqueMember attributes of
> >> cn=Enterprise ACME Administrators,ou=groups,o=ipaca
> >
> > # base <cn=Enterprise ACME Administrators,ou=groups,o=ipaca> with scope
> > # subtree
> > # filter: (objectclass=*)
> > # requesting: uniqueMember
> > #
> >
> > # Enterprise ACME Administrators, groups, ipaca
> > dn: cn=Enterprise ACME Administrators,ou=groups,o=ipaca
> > uniqueMember: uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca
> > uniqueMember: uid=ipara,ou=people,o=ipaca
> > uniqueMember: uid=acme-okda.pipebreaker.pl,ou=people,o=ipaca
> >
> >
> >
> >> - the entry id=acme-<IPA SERVER HOSTNAME>,ou=people,o=ipaca exists
> >
> > There is no entry with id=, but there is one with uid= (I assume you
> > made a typo):
> >
> > # acme-kaitain.pipebreaker.pl, people, ipaca
> > dn: uid=acme-kaitain.pipebreaker.pl,ou=people,o=ipaca
> > 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:: …
> >
> >
> >> - In cn=aclResources,o=ipaca there is the value:
> >> resourceACLS: certServer.ca.certs:execute:allow (execute)
> >> group="Enterprise ACME Administrators":ACME Agents may execute cert
> >> operations
> >
> > $ ldapsrch -b cn=aclResources,o=ipaca resourceACLs | grep ACME
> > Enter LDAP Password:
> > resourceACLs: certServer.ca.certs:execute:allow (execute)
> group="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
>
>