Cannot search usercertificate binary data with raw data

[Luis Neves]

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=***@Company.com
subjectDN: /C=Country/ST=Locality/L=Locality/O=Company/OU=Department/CN=***@Co
mpany.com/emailAddress=***@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

[Michael Ströder]

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.

[Luis Neves]

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.
https://signup.live.com/signup.aspx?id=60969

[Howard Chu]

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.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

[Michael Ströder]

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.

[Michael Ströder]

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.

[Howard Chu]

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/

[Luis Neves]

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: ***@symas.com
> To: ***@stroeder.com
> Subject: Re: Cannot search usercertificate binary data with raw data
> CC: openldap-***@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

[Luis Neves]

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