Kurt,
Thanks for your fast response. We have tested your recommendations and
here is the outcome against an 'out of the box'
version of openldap-2.1.9 with an unmodified core.schema
After doing this i started slapd and tried the following (correct) search:
ldapsearch -h localhost -b dc=com -D cn=manager,dc=com -w mark -x usercertificate="56 $ email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl" dn
Instead, you should use the filter:
(userCertificate:certificateExactMatch:=56 $ email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl)
Ok, let's try and see.
#
# filter: (userCertificate:certificateExactMatch
:=
56 $
email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl
)
# requesting: ALL
#
ldapsearch: ldap_search_ext: Bad search filter (87)
Variations on the subject (maybe
:= is incorrect
):
#
# filter: (userCertificate:certificateExactMatch=56 $
email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl
)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
De ldapserver now logs both times:
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0x08156fd0 ptr=0x08156fed end=0x0815706b len=126
0000: a3 76 04 0f 75 73 65 72 63 65 72 74 69 66 69 63 .v..usercertific
----- cut -----
end get_filter 0
filter: (?=undefined)
Removing certificateExactMatch from core.schema also meens that the index
on
serial $ issuerdn is no longer created and that even when the search would
succeed it would
be very slow with 10K users with certs.
When I add EQUALITY certificateExactMatch to core.schema and reindex the
search you specified still doesn't work.
I do see that the index is created based upon cert $ issuerdn wich is correct.
I note that one generally shouldn't muck with standard track
schema elements.
Point taken..
Yes. The assertion syntax is not the same as the value syntax.
The expected value syntax should be listed in certificateExactMatchSyntaxes,
allowing it to be used with attributes of the appropriate syntax.
Ok, but then it seems that this mechanisme doesn't work. See the search result.
(I note that if this doesn't work, there may very well be a bug somewhere
in the code... I don't use this feature regularly, but I think I understand
how its intended to be used.)
This seems to be the case then...
To get certificateExactMatch to work i therefore changed schema_init.c as shown in the patch below:
diff -urN openldap-2.1.9/servers/slapd/schema_init.c openldap-2.1.9a/servers/slapd/schema_init.c
--- openldap-2.1.9/servers/slapd/schema_init.c Tue Nov 26 19:26:19 2002
+++ openldap-2.1.9a/servers/slapd/schema_init.c Tue Dec 10 13:13:12 2002
@@ -4711,7 +4711,7 @@
#ifdef HAVE_TLS
{"( 2.5.13.34 NAME 'certificateExactMatch' "
- "SYNTAX 1.2.826.0.1.3344810.7.1 )",
+ "SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )",
SLAP_MR_EQUALITY | SLAP_MR_EXT, certificateExactMatchSyntaxes,
certificateExactConvert, NULL,
certificateExactMatch,
That's wrong. See RFC 2252.
I don't agree. RFC 2252 doesn't specify how to match certificates.
certificateExactMatch is only specified in: draft-ietf-pkix-ldap-pki-schema-00.txt
The same draft also defines usercertificate as:
3.1 userCertificate Attribute
The userCertificate attribute type contains the public-key certificates
a user has obtained from one or more CAs. The LDAPspecific encoding for
values of this attribute is described in section 3.3.
( 2.5.4.36 NAME 'userCertificate'
EQUALITY certificateExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
The draft defines certificateExactMatch as:
4.1 Certificate Exact Match
Certificate exact match is defined in 11.3.1 of [9]. The string
description of the certificateExactMatch matching rule is:
( 2.5.13.34 NAME 'certificateExactMatch'
SYNTAX 1.2.826.0.1.3344810.7.1 )
The LDAP syntax definition of the above is:
(1.2.826.0.1.3344810.7.1
DESC 'Certificate Serial Number and Issuer Name' )
So I do agree however that the syntax is correct and that I shouldn't change
it.
But there seems to be a bug that prevents the assertion syntax from being
'mapped' with the value syntax.
If certificateExactMatch is implemented in openldap then this would suggest
that core.schema is incorrect and
that EQUALITY certificateExactMatch should be added.
Mark.