On 05.02.2015 19:22, Graham Leggett wrote:
> 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>
> }”.
It's probably a rarely used format, but if the CertificateExactAssertion
thing is useful for LDAP querying, then fine with me. One caveat
to keep in mind is that GSER (the "Generic String Encoding Rules",
on which RFC 4523 relies) "do not define a canonical encoding",
as stated in RFC 3641 section 5. The following strings for identifying
the certificate from RFC 5280 appendix C.2 are equivalent according
to RFC 4523 (and RFC 4514), e.g.:
{serialNumber 18,issuer rdnSequence:"CN=Example CA,DC=example,DC=com"}
{ serialNumber 18, issuer
rdnSequence:"CN=#130A4578616D706C65204341,DC=#16076578616D706C65,DC=#1603636F6D"
}
> 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).
Implementation-wise, there's some room for improvement:
- "..._SNAI" sounds like fairly cryptic naming to me, I would prefer
an explicit RFC reference, e.g. SSL_CLIENT_CERT_RFC4523_CEA (searching
for "cea" in that RFC will quickly turn up its definition)
- the syntax of the value isn't correct yet: your code does not add
the "rdnSequence:" before the issuer DN, and it needs to be quoted,
- instead of adding another BIO_* dance to ssl_engine_vars.c,
relying on SSL_X509_NAME_to_string (and apr_pstrcat) allows saving
quite some code
- to also export the variable with "SSLOptions StdEnvVars", you need
to add it to ssl_hook_Fixup_vars[] in ssl_engine_kernel.c, too
> 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.
That's what I meant when suggesting something like SSL_CLIENT_CERT_DER
in my last message in the "Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS -
access to full client certificate chain" thread, yes. I would probably
go for Base64 encoded DER values, to avoid '\0'-byte issues when
shuffling things around (i.e., it would be "PEM without headers",
so to say).
Kaspar
