10:09 a.m.
Hi all,
After struggling to get a certificateExactMatch query to work, I’ve discovered that in
389ds the certificateExactMatch rule in the schema has been marked as commented out like
this:
# TODO - Add Certificate syntax
#attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
# DESC 'X.509 user certificate'
# EQUALITY certificateExactMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
DESC 'X.509 user certificate'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
X-ORIGIN 'RFC 4523’)
Does 389ds offer certificateExactMatch support as per the RFCs? Simply uncommenting out
the above results in startup failure below:
[28/Jan/2015:15:55:53 +0000] dse_read_one_file - The entry cn=schema in file
/etc/dirsrv/slapd-monica/schema/05rfc4523.ldif (lineno: 1) is invalid, error code 21
(Invalid syntax) - attribute type userCertificate: Unknown attribute syntax OID
“1.3.6.1.4.1.1466.115.121.1.8"
Regards,
Graham
—
10:33 a.m.
On 01/28/2015 09:09 AM, Graham Leggett wrote:
Hi all,
After struggling to get a certificateExactMatch query to work, I’ve discovered that in
389ds the certificateExactMatch rule in the schema has been marked as commented out like
this:
# TODO - Add Certificate syntax
#attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
# DESC 'X.509 user certificate'
# EQUALITY certificateExactMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
DESC 'X.509 user certificate'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
X-ORIGIN 'RFC 4523’)
Does 389ds offer certificateExactMatch support as per the RFCs?
No, that's why it is commented out. We do not have support for the
certificate* matching rules. That's why we just use octetString i.e. it
just does a memcmp().
Simply uncommenting out the above results in startup failure below:
[28/Jan/2015:15:55:53 +0000] dse_read_one_file - The entry cn=schema in file
/etc/dirsrv/slapd-monica/schema/05rfc4523.ldif (lineno: 1) is invalid, error code 21
(Invalid syntax) - attribute type userCertificate: Unknown attribute syntax OID
“1.3.6.1.4.1.1466.115.121.1.8"
Regards,
Graham
—
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
10:43 a.m.
On 28 Jan 2015, at 6:33 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> Does 389ds offer certificateExactMatch support as per the RFCs?
No, that's why it is commented out. We do not have support for the certificate*
matching rules. That's why we just use octetString i.e. it just does a memcmp().
I’ve been trying the option of using octetStringMatch with a filter that looks like this:
(userCertificate=#308203aa3082[snip])
The error I get back is:
LDAP: error code 11 - Administrative Limit Exceeded
A number of questions:
- The encoding was obtained from the java javax.naming.ldap.Rdn class, which seems to want
to encode the DER byte array of the certificate being searched for as a hash symbol
followed by hex digits, as opposed to \00\11\22 (etc) as seen in many examples online. Is
this encoding correct? (I assume it is).
- I noticed that no index existed for userCertificate, so I added an index on equality.
The searches still take a very long time (with Directory Manager) and Administrative limit
exceeded with normal users. Am I right in understanding that userCertificate searches are
not filtered?
Regards,
Graham
—
10:51 a.m.
On 01/28/2015 09:43 AM, Graham Leggett wrote:
On 28 Jan 2015, at 6:33 PM, Rich Megginson
<rmeggins(a)redhat.com> wrote:
>> Does 389ds offer certificateExactMatch support as per the RFCs?
> No, that's why it is commented out. We do not have support for the certificate*
matching rules. That's why we just use octetString i.e. it just does a memcmp().
I’ve been trying the option of using octetStringMatch with a filter that looks like
this:
(userCertificate=#308203aa3082[snip])
The error I get back is:
LDAP: error code 11 - Administrative Limit Exceeded
A number of questions:
- The encoding was obtained from the java javax.naming.ldap.Rdn class, which seems to
want to encode the DER byte array of the certificate being searched for as a hash symbol
followed by hex digits,
That might be ok for DN/RDN values - see http://tools.ietf.org/html/rfc4514
as opposed to \00\11\22 (etc) as seen in many examples online. Is
this encoding correct? (I assume it is).
No. In order to use the value in an LDAP search filter, you must use
http://tools.ietf.org/html/rfc4515 encoding.
- I noticed that no index existed for userCertificate, so I added an index on equality
What were the exact steps you performed? Because below sounds like
there is no index e.g. created by doing a db2index[.pl], and it is
falling back to looking through every entry, and you are hitting the
lookthrough limit.
The searches still take a very long time (with Directory Manager) and
Administrative limit exceeded with normal users. Am I right in understanding that
userCertificate searches are not filtered?
Regards,
Graham
—
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
3374
days inactive
3374
days old
389-users@lists.fedoraproject.org
3 comments
2 participants
participants (2)
-
Graham Leggett -
Rich Megginson