Kevin Vargo wrote:

On Wed, 2006-06-07 at 17:31 +0200, Pierangelo Masarati wrote:

...

Store the certificate in the RDBMS in the form that is appropriate for its value. In fact, back-sql doesn't do any mucking on the value of your certificate; if you base64-encode it, back-sql cannot know. Moreover, back-sql is very poor at dealing with binary objects, so you might be off even if you succeed in storing the certificate in binary form.

I guess a reasonable approach would be to use BLOB data type and make sure back-sql can handle it accordingly.

p.

Has anyone else had success using userCertificates? I've placed the Base-64 encoded certificate data in the database. However upon attempted retrieval, I get an error attempting to validate the attribute: unable to validate value #0 of AttributeDescription userCertificate

What the above message says is that it's pointless to store the certificate in the database in base64, because back-sql returns the value as is, and slapd expects it to be an octet string containing the certificate, not its base64 representation.

So I #undef'd the pretty/validate directive in back-sql.h (BACKSQL_PRETTY_VALIDATE) but this only resulted in getting the normalization error: unable to normalize value #0 of AttributeDescription userCertificate

Same as above. Validators for certificates are already present in slapd, and, of course, they expect valid certificates.

Any ideas? As well, is there any documentation on writing validators? I wasn't able to locate any so far.

Write the certificate to the database as is, not base64 encoded, using a BLOB. And, there's no guarantee it works. As usual, if you succeed, patches are welcome.

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 ------------------------------------------