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 —
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 28 Jan 2015, at 6:33 PM, Rich Megginson rmeggins@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 —
On 01/28/2015 09:43 AM, Graham Leggett wrote:
On 28 Jan 2015, at 6:33 PM, Rich Megginson rmeggins@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Graham Leggett -
Rich Megginson