with following log: tl-ldap-certalias: DEBUG: Found user xxyyzz tl-ldap-certalias: ERROR: Failed to load certificate... stderr from tl-certtool: ERROR: Could not read Novell subject from certificate (error code -2) This report arrived from a customer and we have also verified this at another customers site.
It appears only on certificates with SubjectAlternateName and we have reproduced the problem inhouse. What is failing is a special case handling in the certificate parser, the problem is pinned to an upgrade of libtasn, which have changed its interface when parsning internal types like IA5String. The new approach is to use asn1_decode_simple_der().
Commit 28161 fixes the problem related to initial error report, however there might be other places that uses the old approach which need to be fixed. A simple grep of IA5String does not reveal any other usage of IA5String usage but there are also other internal asn1 types that needs to be identified and fixed.
Additional, we should have autotests created to capture these kind of problems.
(In reply to comment #2) > Commit 28161 fixes the problem related to initial error report, however there > might be other places that uses the old approach which need to be fixed. > > A simple grep of IA5String does not reveal any other usage of IA5String usage > but there are also other internal asn1 types that needs to be identified and > fixed. A grep of asn1_create_element() and verify of types used no other internal asn1 types was found and used.
(In reply to comment #3) > Additional, we should have autotests created to capture these kind of problems. Initial autotest created for tl-certool in commit r28190.
Inspected commit. Tested tlclient. We have autotests, and the code has also been tested at customer site. That should be enough.
