[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: certificateExactMatch, why it doesn't work and how to fix it.


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
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
{"( NAME 'certificateExactMatch' "
- "SYNTAX 1.2.826.0.1.3344810.7.1 )",
+ "SYNTAX )",
SLAP_MR_EQUALITY | SLAP_MR_EXT, certificateExactMatchSyntaxes,
certificateExactConvert, NULL,

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. 

    ( NAME 'userCertificate'
      EQUALITY certificateExactMatch
      SYNTAX )
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:

    ( NAME 'certificateExactMatch'
    SYNTAX 1.2.826.0.1.3344810.7.1 )

The LDAP syntax definition of the above is:

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.