|
Hi Michael, once again, thank you for your valuable tips and interest on helping me > 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? Sorry, i made a typo, Ive used Hexdump to get an hexadecimal representation of the DER file, and used that as the "raw" binary search filter, after putting slashes (tried also with bouble slashes, and as I said, also reversing the bytes order) before each hexadecimal value. I ve used uuencode to turn the DER certificate on a list of base64 ascii characters for using on the ldif file. (its the same output as the PEM representation of the certificate, but without the ---- begin certificate ---- header and footers) > > 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. > sorry my dumb question, but this means that an octetstring like the one I am using cannot be matched on a ldapsearch against the usercertificate attribute? so how will mod_auhtz_ldap be able to ever work? (see below why) > Since you asked a similar question on openssl-users I assume you want to use > this module. Right? > > http://authzldap.othello.ch/configuration.html correct. I have configured this module to use the whole certificate as the matching attribute against the same data stored on the ldap server (after a lot of problems with UTF8 when trying to use subjectDN and issuesDN atributes). I am seeing in the apache logs that the module is trying a ldapsearch using the hexadecimal raw data and returning an error: ssl_error_log: [client 10.15.1.119] [11624] filter: (&(userCertificate=\\30\\82\\07\\38\\30 etc etc etc etc \\91\\ee\\e9\\7d)(objectClass=strongAuthenticationUser)) base: ou=AuthzLDAPCertmap,dc=cm-lisboa,dc=pt, no such user (Iam seeing now that "binary" option is not used on this query, but I think Ive tried with and without this option as well) so, to try to find out why I am getting the "no such user" error I started making tests with ldapsearch and a filter equal to the hexadecimal representation of the cert that is stored on the directory, just like what it seems mod_authz_ldap is trying to do But the truth is that I am not being able to find nothing using this technique.... so, how could mod_authz_ldap ever work??.... Just for sure next monday I will try again all the tests Ive made today (ldapserach with and without "binary", with bytes reversed and not, with single and double slahes), anyway, what you said above about the octetstringmatch is ringing problems in my head.... Luis Hotmail: Powerful Free email with security by Microsoft. Get it now. |