On 05.11.2014 14:26, Graham Leggett wrote:
> The problem I am trying to solve is to find a practical way to
> integrate an SSL client cert identity with LDAP, in such a way where
> I can say “we recognise this certificate is mapped to that
> capability”. I am struggling to find an accurate indicator of “this
> certificate” (as opposed to “this similar looking certificate with a
> different chain”). Annoyingly the simplest solution - a simple binary
> match on the cert - isn’t supported by certificateExactMatch in most
> LDAP servers.
certificateExactMatch isn't really a "binary" match (i.e., a binary
comparison of the certificate's DER encoding or such). As its
description in RFC 4523 section 3.1 says:
> The certificateExactMatch matching rule compares the presented
> certificate exact assertion value with an attribute value of the
> certificate syntax as described in clause 11.3.1 of [X.509].
And said clause from X.509 reads:
> 11.3.1 Certificate exact match
>
> The certificate exact match rule compares for equality a presented
> value with an attribute value of type Certificate. It uniquely selects
> a single certificate.
>
> certificateExactMatch MATCHING-RULE ::= {
> SYNTAX CertificateExactAssertion
> ID id-mr-certificateExactMatch }
>
> CertificateExactAssertion ::= SEQUENCE {
> serialNumber CertificateSerialNumber,
> issuer Name }
>
> This matching rule returns TRUE if the components in the attribute
> value match those in the presented value.
(i.e., we are again back at the point that uniqueness of an X.509
certificate is achieved by its issuer DN plus serial number)
> Is there another way to do this?
"Manually" performing what certificateExactMatch is specifying, I would
say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a
unique identifier for a specific client certificate.
Kaspar
