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:
Please see the attached patch of
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?
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
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
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
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: ad...@greyoak.com
SASL SSF: 56
SASL data security layer installed.
< .. snip .. >
That is exactly how I was reproducing this issue.
Added is the patch that adds error message and logs properly.
* 9a8c5c9dfd10ab1c0bb66b5f25bf815a43d45f2a host/service-show/find
shouldn't fail on invalid certificate
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code