> On 06 Nov 2014, at 14:14, Andreas B. <[email protected]> wrote: > > Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik: >>> On 06 Nov 2014, at 07:05, Kaspar Brand <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>>> 11.3.1 Certificate exact match >>>> … >>>> CertificateExactAssertion ::= SEQUENCE { >>>> serialNumber CertificateSerialNumber, >>>> issuer Name } >> ... >>> (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) >> And even that is LDAPs take on it - in a lot of practical cases it gets more >> complex; especially if the leave of the one but last intermediate is cross >> signed. >> >> Making above more of an LDAP thing than a ‘protocol’ thing. >> >> So therefore: >> >>>> 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. >> I would argue that the ‘best’ thing we can do is first on the SSL >> termination side — follow the chain; and if there we *conclude* that all is >> well - and we present the evidence of that conclusion ’to what is behind’. >> >> And ideally make that as hard to mis-interpret. So Graham his idea of >> providing a single ‘unique' string which gives the DN’s in order (along with >> the usual SSL_CLIENT.. env vars; including the full ANS.1 if you are so >> inclined) is quite pragmatic. As that string is ‘unique’ within the promise >> the web frontend with its current settings is making. >> >> And it cuts out a lot of easy to make errors. And those who want to do >> better can simply use SSL_CLIENT_CERT and SSL_CLIENT_CERT_0…N — with >> sufficient code to understand things like cross signing and funny order >> issues. As parsing that is not trivial when there are multiple >> selfsigned/roots in a chain ‘up’. >> >> Dw. > If you want to identify a specific certificate, wouldn't it be possible to > use sha1/256 fingerprints created with X509_digest? Or is that something LDAP > doesn't support? That could be exported with SSL_CLIENT_CERT_THUMB and > SSL_CLIENT_CERT_THUMB_ALG for the algorithm used.
One could. The issue is that in some systems (e.g. a medical one I am currently trying to come to terms with) the certs ar renewed very often; and the fingerprint does not stay stable. This is also an issue with using the serial and the issuer DN. Dw.
