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 );
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?