certificateExactMatch discrepancies (a bit long)

[<szilva@szilva.uklinux.net>]

Dear All, 

Using OpenLDAP 2.1.22 I have some problems giving multiple certificates to 
a single user. Creating two files with different certificates like:

cert1:
dn: uid=szilva,ou=People,o=Bingo
changetype: modify
add: userCertificate;binary
userCertificate;binary::
[...some base64 stuff..]
-

cert2:
dn: uid=szilva,ou=People,o=Bingo
changetype: modify
add: userCertificate;binary
userCertificate;binary:: 
[...some base64 stuff..]
-                                                                                                                                            

and setting "certificateExactMatch" in core.scheme like:

attributetype ( 2.5.4.36 NAME 'userCertificate'
    EQUALITY certificateExactMatch
    DESC 'RFC2256: X.509 user certificate, use ;binary'
    SYNTAX 1... )

I attempted to add the first like:

$ ldapmodify -x -w mypass -D "cn=admin, o=Bingo" -f ./cert1
modifying entry "uid=szilva,ou=People,o=Bingo"

is apparently OK. Than giving the second:

$ ldapmodify -x -w mypass -D "cn=admin, o=Bingo" -f ./cert2
modifying entry "uid=szilva,ou=People,o=Bingo"
ldap_modify: Can't contact LDAP server

ldif_record() = 81

and sldap dumps core. Even worse after restarting slapd the database is in
inconsistent state and ldapsearch is stuck, slapd eating 99% cpu for a
while than dies. Apparently the problem is at certificateExactMatch(..) in
servers/slapd/schema_init.c (line 3816). Problems are ie that the return 
value of serial_and_issuer_parse() is not checked so it is assumed that 
the parsing is always OK. The "traceback" by gdb is like:

Core was generated by `/usr/sbin/slapd -h ldap://0.0.0.0:389/'.
Program terminated with signal 11, Segmentation fault.
#0  0x081aec66 in free ()
(gdb) bt
#0  0x081aec66 in free ()
#1  0x08070dc9 in certificateExactMatch (...) at schema_init.c:3893
#2  0x0806066c in value_match (...)    at value.c:356
#3  0x0807a062 in modify_add_values (...) at mods.c:410
#4  0x0807d8b7 in bdb_modify_internal (...) at modify.c:59
#5  0x0807dcfc in bdb_modify (...) at modify.c:430
#7  0x0804d1ca in connection_operation (...) at connection.c:942
#8  0x0809582c in ldap_int_thread_pool_wrapper (...) at tpool.c:426
#9  0x08194ff1 in pthread_start_thread ()

Seems there is a mismatch of octal and extracted representation of 
certificates. It also occurs if I am trying to delete a certificate with
a rather similar scenario (dying at free() in certificateExactMatch).

So is it a feature or (more likely) a bug? What would be the correct 
solution, I think checking the buffers (wether the cert is extracted or 
still in octal representation) would be handy to avoid these segfaults.

Cheers:
Szilva