On 01 Nov 2014, at 11:47 AM, Kaspar Brand <[email protected]> wrote:
> Feels like a fairly idiosyncratic solution to me (essentially sticking > multiple things together into a single environment variable, with the > [known] problems of how to separate them again / do proper matching in > the application). I would prefer these DNs being exported to the > environment in the same way as it is currently done with the > SSL_CLIENT_CERT_CHAIN_n variables. The trouble with doing that is that it makes life really difficult to match arbitrary certificate chains - you need to know in advance how many certs are in each chain, and you need to perform a lot of messing about to perform a match, and to ensure the subjects are in the right order. The use case this solves is that I want to uniquely identify a certificate and store that identity in an LDAP directory. The most obvious solution - just store the cert in the userCertificate attribute and do a direct binary match - doesn’t work in most directories, as direct certificate matching was forgotten in the specs that were involved (unfortunately). The format chosen is the subjects of the certs encoded as RFC2253, which are turned into a DN that is in turn RFC2253 encoded again. The result is therefore still a valid DN, and so can be stored in any DN formatted field in LDAP. This works nicely with 389ds. In terms of separating them, simply unpack the outer DN as per RFC2253, leaving you with the inner subject DNs. In practise you’re unlikely to want to separate them, instead you want to say “I want to trust this specific certificate issued by this specific CA”. Back in time matching the issuer was enough, but as soon as intermediate certs came along it became significantly more difficult to do. (Having said the above I don’t disagree that the _n variables could be useful, it’s just that they don’t solve the use case I am facing). Regards, Graham —
