[Freeipa-devel] [PATCH 0046] Don't fail in find/show methods if userCertificate is invalid

[Martin Basti]

On 10.06.2016 13:25, Stanislav Laznicka wrote:
> On 06/09/2016 04:32 PM, Rob Crittenden wrote:
>> Fraser Tweedale wrote:
>>> On Thu, Jun 09, 2016 at 03:07:34PM +0200, Martin Basti wrote:
>>>> On 09.06.2016 15:03, Martin Basti wrote:
>>>>> On 09.06.2016 15:02, Stanislav Laznicka wrote:
>>>>>> On 06/09/2016 02:51 PM, Rob Crittenden wrote:
>>>>>>> Stanislav Laznicka wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please see the attached patch of
>>>>>>>> https://fedorahosted.org/freeipa/ticket/5797.
>>>>>>>>
>>>>>>>> Standa
>>>>>>>>
>>>>>>> Just wondering out loud but should usercertificate be excluded
>>>>>>> from the output if it is unparsable? Is there any value in
>>>>>>> showing that a bogus value is in there?
>>>>>>>
>>>>>>> rob
>>>>>> I think it is a good pointer that something has gone wrong with the
>>>>>> certificate. Another way would be to print 'Invalid certificate'
>>>>>> instead of it similar to what Apache LDAP Browser does.
>>>>> We can return a warning message that something with certificates is
>>>>> broken.
>>>>>
>>>>> Martin^2
>>>>>
>>>> And you should log it at error log level, because it is error
>>>>
>>> Is the data from LDAP actually invalid?  It should not be possible
>>> to store data that is not a syntactically valid X.509 cert in the
>>> userCertificate attribute (if it is, we should file a ticket against
>>> 389).
>>>
>>> Is there a full traceback for the original error of #5797? What is
>>> the datum that is the immediate cause of the error and what happens
>>> to it between the database and the function that throws?
>>>
>>> Could it be a python3 bytes/str problem originating in
>>> x509.normalize_certificate?
>>>
>>> Cheers,
>>> Fraser
>>>
>>
>> A cert can get in several different ways. IPA sure tries hard not to 
>> allow bad certs but I guess they can happen:
>>
>> $ ldapmodify -Y GSSAPI
>> SASL/GSSAPI authentication started
>> SASL username: admin at GREYOAK.COM
>> SASL SSF: 56
>> SASL data security layer installed.
>> dn: 
>> krbprincipalname=cert/slithy.greyoak.com at GREYOAK.COM,cn=services,cn=accounts,dc=greyoak,dc=com
>> changetype: modify
>> add: usercertificate
>> usercertificate: foo
>>
>> modifying entry 
>> "krbprincipalname=cert/slithy.greyoak.com at GREYOAK.COM,cn=services,cn=accounts,dc=greyoak,dc=com"
> < .. snip .. >
> That is exactly how I was reproducing this issue.
>
> Added is the patch that adds error message and logs properly.

ACK

master:
* 9a8c5c9dfd10ab1c0bb66b5f25bf815a43d45f2a host/service-show/find 
shouldn't fail on invalid certificate