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:
--
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