> On 06 Nov 2014, at 07:05, Kaspar Brand <httpd-dev.2...@velox.ch> 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.
