On 01/28/2015 09:43 AM, Graham Leggett wrote:
On 28 Jan 2015, at 6:33 PM, Rich Megginson
>> 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
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
- 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
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?
389 users mailing list