Kevin Vargo wrote:

...

You don't need to tell back-sql if data is binary or not: it already knows how to deal with data based on their syntax. You need to tell the RDBMS that its' storing binary data, and store the certificate in the RDBMS as binary. If you store the certificate in base64, then back-sql (actually, the certificate's validator, back-sql yous passes octet strings around) doesn't know what to do with it.

Right; I am storing it DER(BER) in a BLOB field now:

mysql> desc user_certificates; +------------------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | person_id | int(11) | NO | | | | | certificate_data | blob | YES | | NULL | | +------------------+---------+------+-----+---------+----------------+ 3 rows in set (0.16 sec)

Still yields:

==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="userCertificate" keyval=4 backsql_get_attr_vals(): number of values in query: 1 backsql_get_attr_vals(): query="SELECT user_certificates.certificate_data AS userCertificate FROM persons,user_certificates WHERE persons.id=? AND persons.id=user_certificates.person_id ORDER BY userCertificate" keyval=4 ================>>> certificateValidate ================>>> certificateValidate: error:(218529960) error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag ================>>> certificateValidate: error:(218595386) error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error ================>>> certificateValidate: error:(0) error:00000000:lib(0):func(0):reason(0)

pulling the data directly out of the database via Perl, the file verifies just fine with: openssl x509 -noout -text -inform der -in ../tmp/tmpfile.tmp

pulling it out with SELECT ... INTO OUTFILE yeilds the same SSL errors; diff'ing shows \s in the file that's bad...?

based on what TIS#3113 indicated, it seemed like the guy had issues with how slapd was pulling it out of the database?

It also seemed like the following note was consistent with that interpretation?

[servers/slapd/back-sql/entry-id.c:744] /* * FIXME: what if a binary * is fetched? */ ber_str2bv( row.cols[ i ], 0, 0, &bv );

This is surely part of the problem. In this sense, back-sql knowns nothing about BLOBs, and a patch for this would be welcome.

...

...

Note that this is the OpenSSL invoked by the X.509 validator (assuming TLS was turned on), even though the certificate in question is not being used for TLS. However, the normalization still fails, even (as mentioned) if validation is disabled. I'm assuming the normalization failure would be related, although I haven't gotten there yet.

TLS has nothing to do with this. OpenLDAP just needs to be compiled with ssl to have certificate handling routines around.

It appears to choose the validator via TLS settings? I could certainly be missing something, but:

[servers/slapd/schema_init.c] #ifdef HAVE_TLS static int certificateValidate( Syntax *syntax, struct berval *in ) { ...... #else #define certificateValidate sequenceValidate #endif

or are you saying that HAVE_TLS is driven off of ssl compilation switches?

From your previous message, I inferred you said that TLS had to be __configured__ in slapd.conf to enable certificate validation. I understand you meant it had to be configured at compile time. The latter is correct, so if that's what you meant then you were right.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------