Michael Ströder wrote:
Luis Neves wrote:
but i want to specifie a raw filter to the userCertificate atribute: Ive uuencoded the original DER certificate and used the result as a search filter
Not sure whether you generated the search filter correctly at all. If you use uuencode the cert gets base64-encoded?
If you want to search for an octet string you have to use hex-escaping of the bytes in the search filter. See the escaping rules in RFC 4515.
ldapsearch -x -h 10.15.254.148 -p 389 -D "cn=root,dc=cm-lisboa,dc=pt" -w ***** -s sub -b "ou=AuthzLDAPCertmap,dc=cm-lisboa,dc=pt" '(&(userCertificate;binary=\30\82\07\38\30\82\06\20\a0\03\02\01\02\02\08\d9\33\e0\f2\f9\5d\0f\30\0d\06\09\2a\86\48\86 etc etc etc )(objectClass=strongAuthenticationUser))'
But userCertificate has certificateExactMatch (2.5.13.34) defined as equality matching rule. This is *not* the octetStringMatch (2.5.13.17) matching rule.
Searching certs with octetStringMatch will obviously not perform well though. I'd recommend to think about another method.
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
Probably the encoding of his filter value is just wrong. And of course, it would be simpler to just use a certificate assertion value instead.