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

Re: CertificateExactMatch for the ldap HEAD branch (ITS#2719/ITS#2771).


I'll try to take at your patch in a bit.  I'm thinking it might be
useful to add userCertificate tests to the test suite.

Regarding characters special to the LDAP string representation of DNs, see
RFC 2253.  These characters need to be properly escaped.  That
should be done by X509_NAME_print_ex() with appropriate flags.
If not, then we need to work with the OpenSSL folks to fix
it.  Striping commas (or other characters) is a bad idea as it
will cause incorrect matching.


At 12:57 PM 10/16/2003, Mark Ruijter wrote:
>ITS#2771 contains a patch for ldap-head that implements
>Two types of queries are supported:
>   * 'userCertificate=0$email=ca@snakeoil.dom,cn=snake oil
>     ca,ou=certificate authority,o=snake oil, ltd,l=snake town,st=snake
>     desert,c=xy'
>   * userCertificate;binary=\30\82\03\ae.....
>For compatibility the 'old' syntax still works:
>userCertificate=0 $ email=ca@snakeoil.dom,cn=snake oil ca,ou=certificate
>authority,o=snake oil, ltd,l=snake town,st=snake desert,c=xy
>The queries below also work but are not recommended:
>userCertificate;binary=0$email=ca@snakeoil.dom,cn=snake oil
>ca,ou=certificate authority,o=snake oil, ltd,l=snake town,st=snake
>userCertificate=30\82\03\ae....   (mod_authz_ldap)
>For example:  mod_authz_ldap (apache ldap strong authentication module)
>uses the last query type so it's allowed for compatibility.
>Out of mod_authz_ldap:
>        /* build a filter for the certificate map
>        if (sec->certdirect) {
>                ap_snprintf(filter, MAX_STRING_LEN,
>                        "(&(userCertificate=%s)"
>                        "(objectClass=strongAuthenticationUser))",
>Internally certificates are normalized to the serial$issuerdn format
>and  then stored and retrieved with octetStringIndexer/OctetStringMatch
>Note: If the issuerdn contains a comma like the snake oil cert from the
>example above, then this comma is removed before indexing. dnNormalize
>not allow dn's with a comma. Are there any other characters that I
>should be aware of?
>A large part of the code has been changed and now uses standard openssl
>routines where possible. It has been tested with
>and a large data set with certificates from many different CA's.
>Please let me know if additional work is needed,
>Mark Ruijter