Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
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.
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.
