On 09.11.2014 14:30, Graham Leggett wrote: > On 06 Nov 2014, at 8:05 AM, Kaspar Brand <[email protected]> wrote: > >>> 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. > > Imagine I trust two roots, A and X, where X has been compromised. > > I authorize the certificate chain A->B->C to perform a specific > action. What stops the root X from issuing an intermediate > certificate with subject “B” and a leaf certificate with subject “C” > to produce a chain that goes X->B->C, and the client provides both > the intermediate cert B and leaf certificate C during the SSL > handshake? > > In other words, if I only consider the serial number and issuer > during authorization, what stops a compromised-but-still-trusted CA > from issuing an intermediate cert that replaces another trusted > issuer?
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". For (2), which is about authorization, the certification path can be a suitable criterion (note that X.509 also defines a "CertificationPath" ASN.1 type in this context, though in a more complex/complete way than what you're proposing). For (1), however, it's not sufficient to pick the subjectDN from an end-entity certificate - even from a "trusted" issuing CA, you may expect multiple certificates with the same issuer (think of dual-keying e.g.). Or another case to take into account is that an end-endity certificate may have an empty subject DN (RFC 5280 section 4.1.2.6), in which case the concatenation of the subjectDNs (the proposed SSL_CLIENT_CERT_SUBJECTS string) wouldn't work at all. As pointed out by Tim Bannister meanwhile, comparing the complete certificate against a "userCertificate" LDAP attribute would be the most secure way to make sure that the user has indeed authenticated with the certificate you require. If mod_authnz_ldap's "Require ldap-attribute" could be extended to allow value definitions based on SSL_CLIENT_CERT, then you wouldn't depend on CertificateExactMatch support in the LDAP server (the PEM headers in SSL_CLIENT_CERT would have to be stripped before comparing to the LDAP attribute, perhaps an additional var like SSL_CLIENT_CERT_DER could be introduced if this makes things simpler in mod_authnz_ldap). Kaspar
