On 12 Nov 2014, at 8:03 AM, Kaspar Brand <[email protected]> wrote:
> We seem to talk about two separate issues, I think: (1) "to uniquely
> identify a certificate and store that identity in an LDAP directory"
> (from your 1 Nov message), and (2) "that I trust both CA1 and CA2 to
> issue certificates, but I don’t trust CA2 not to (accidentally or
> purposefully) issue a certificate with the same issuer as CA1”.
This is the crux of the problem, yes.
What I’ve done is broken the problem into two sections, the first is to give a
unique handle on the certificate that can be used in LDAP queries. RFC4523
defines a CertificateExactAssertion, which is “{ serialNumber
<decimal-serial-number-string>, issuer <issuer-string> }”.
The attached patch provides an SSL_CLIENT_CERT_SNAI variable that gives the
above string, which in turn can be used for LDAP queries against the
userCertificate attribute (or another attribute for directories that don’t
support certificateExactMatch).
The second part of the problem is “is this certificate the one we’re looking
for”. The formal definition of certificateExactMatch doesn’t allow for binary
matches of a cert, and some directories allow it, and some don’t. What I have
in mind for this is to create a mechanism that allows mod_ssl to expose binary
data like the DER of the cert and allow other modules to query that data and
check it. In this case mod_authnz_ldap can then optionally verify that the cert
returned from the directory matches the cert returned by mod_ssl.
Regards,
Graham
—
httpd-mod_ssl-snai.patch
Description: Binary data
