Hi
I ve imported to my openldap directory a x509 user certificate to the usercertificate;binary attribute
(using and ldif and also using the import option from the GC ldap browser)
if i make a simple query like this 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=*)(objectClass=strongAuthenticationUser))'
i get all the data ok:
dn: uid=luisneves,ou=AuthzLDAPCertmap,dc=cm-lisboa,dc=pt objectClass: authzLDAPmap objectClass: top objectClass: account objectClass: strongAuthenticationUser uid: luisneves serialNumber: 1234567890 issuerDN: /C=Country/ST=Locality/L=Locality/O=COMPANY/OU=Department/CN=Compani es Root Certification Authority/emailAddress=mail@Company.com subjectDN: /C=Country/ST=Locality/L=Locality/O=Company/OU=Department/CN=uid@Co mpany.com/emailAddress=UID@Company.com owner: uid=luisneves,ou=people,dc=cm-lisboa,dc=pt userCertificate;binary:: MIIHODCCBiCgAwIBAgIIX9kz4PL5XQ8wDQYJKoZIhvcNAQEFBQAwf DELMAkGA1UEBhMCUFQxHDAaBgNVBAoME0NhcnTDo28gZGUgQ2lkYWTDo28xFDASBgNVBAsMC3N1Yk VDRXN0YWRvMTkwNwYDVQQDDDBFQyBkZSBBdXRlbnRpY2HDp8OjbyBkbyBDYXJ0w6NvIGRlIENpZGF etc etc
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
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))'
and nothing is returned, never
Ive tryied also to swap first and second bytes (eg, instead of \30\82 use instead \82\30) and still nothing returns.....
Why? Why a cant get any result on this query?... Best regards, Luis _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
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?
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.
Since you asked a similar question on openssl-users I assume you want to use this module. Right?
http://authzldap.othello.ch/configuration.html
Ciao, Michael.
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?
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. https://signup.live.com/signup.aspx?id=60969
Michael Ströder wrote:
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?
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.
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
Probably the encoding of his filter value is just wrong. And of course, it would be simpler to just use a certificate assertion value instead.
Hi
a) I have extracted the user certificate from the directory to a file using "ldapsearch -t .... " Ive encoded the result file with hexdump and added slashes (and double slashes and tested also with reversing the byte order) Iam using the result as a search filter against the directory, and no results
b) Ive copy/pasted all the values from apache error_log (which comes from the user browser) and used as a filter to ldapsearch and nothing userCertificate=\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
a) and b) filters are the same, so I think I am doing the right tests, without errors
I dont have any more ideas... :( help.....
c) I will make every test again next monday just to be sure i didnt copy/pasted any error
I am starting to think of making some smaller testcase with some other binary fields, like a jpg for example. What do you think? Add a image attribute to the user, load a very small (1x1) jpg, hexdump it to a file and try to feed it to ldapsearch until i get something This is the only idea I have so far that other users could test without too much effort and compare results with me....
Luis
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))'
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
Probably the encoding of his filter value is just wrong. And of course, it would be simpler to just use a certificate assertion value instead.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
_________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
Luis Neves wrote:
and used as a filter to ldapsearch and nothing userCertificate=\30\82\07\38\30\82\06\20\a0\03\02\01\02 [..]
The double slashes are wrong. Has to be one back-slash to indicate a hex-escaped byte-value. Or are the doubled back-slashes the result of another string representation? But I'm not sure whether it works even with a correct filter string.
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
But userCertificate has certificateExactMatch (2.5.13.34) defined as equality matching rule. This is *not* the octetStringMatch (2.5.13.17) matching rule.
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
It does not work for me with 2.4.22. It's a cert which was downloaded from the directory.
In syslog the following filter is logged:
(?userCertificate;binary=0\82\05M0\82\045\A0...)
The filter string seems right to me. It's a cert which was downloaded from one directory entry. But not results returned.
Searching certs with octetStringMatch will obviously not perform well though. I'd recommend to think about another method.
Probably the encoding of his filter value is just wrong. And of course, it would be simpler to just use a certificate assertion value instead.
Performance would be bad anyway. The approach to map certs to user entries by searching for the whole cert is flawed.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
But userCertificate has certificateExactMatch (2.5.13.34) defined as equality matching rule. This is *not* the octetStringMatch (2.5.13.17) matching rule.
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
It does not work for me with 2.4.22. It's a cert which was downloaded from the directory.
My mistake. See RFC4523. The filter must use a matching assertion value, it cannot use the actual certificate.
So how to do a ldapsearch against usercertificate using hexadecimal codes as filter ? Is not possible at all?
Luis
Date: Sat, 8 May 2010 07:54:40 -0700 From: hyc@symas.com To: michael@stroeder.com Subject: Re: Cannot search usercertificate binary data with raw data CC: openldap-software@openldap.org
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
But userCertificate has certificateExactMatch (2.5.13.34) defined as equality matching rule. This is *not* the octetStringMatch (2.5.13.17) matching rule.
It is legal to use an octet string for certificateExactMatch. In OpenLDAP the octet string is simply parsed and turned into a certificate assertion value and then matched as usual.
It does not work for me with 2.4.22. It's a cert which was downloaded from the directory.
My mistake. See RFC4523. The filter must use a matching assertion value, it cannot use the actual certificate.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
_________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
openldap-software@openldap.org
-
Howard Chu -
Luis Neves -
Michael Ströder