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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:48 AM 12/10/2002, Mark Ruijter wrote:
>I've been trying to get certificateExactMatch to work but this proved to be more difficult then i expected.

Likely because you are not using the rule as expected.
It's intended to be used as an extensible matching rule.

>The first thing i did whas changing core.schema as show below: 
>
># Must be transferred using ;binary 
>attributetype ( 2.5.4.36 NAME 'userCertificate' 
>        DESC 'RFC2256: X.509 user certificate, use ;binary' 
>        EQUALITY certificateExactMatch 
>        SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 

I note that one generally shouldn't muck with standard track
schema elements.

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

(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 would result in a logfile entry like this: conn=4 op=1 SRCH base="dc=com" scope=2 filter="(?=undefined)" 
>After some digging in the source i found that filter.c whas unable to find a EQUALITY matchingrule for userCertificate. 
>
>The reason can be found in schema_init.c: 
>#ifdef HAVE_TLS 
>{"( 2.5.13.34 NAME 'certificateExactMatch' " 
>"SYNTAX 1.2.826.0.1.3344810.7.1 )", 
>SLAP_MR_EQUALITY | SLAP_MR_EXT, certificateExactMatchSyntaxes, 
>certif 
>icateExactConvert, NULL, 
>certificateExactMatch, 
>certificateExactIndexer, certificateExactFilter, 
>NULL}, 
>#endif 
>
>filter.c is unable to find certifiacteExactMatch because it looks for syntax 1.3.6.1.4.1.1466.115.121.1.8. The syntax for the matchrule is however 
>defined as 1.2.826.0.1.3344810.7.1. 

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.

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

>After recompiling openldap everything works.

Well, don't be surprised if you later find problems with the
approach you've taken.

>Question: Am i doing the right thing here, or am i missing something? 

Yes, Yes.  See above.

Kurt