httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain
Date Thu, 06 Nov 2014 13:19:46 GMT

> On 06 Nov 2014, at 14:14, Andreas B. <register@progandy.de> wrote:
> 
> Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
>>> On 06 Nov 2014, at 07:05, Kaspar Brand <httpd-dev.2014@velox.ch> <mailto:httpd-dev.2014@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.
> 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.
Mime
View raw message