On 06.11.2014 14:19, Dirk-Willem van Gulik wrote:
>
>> 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:
>>>>
>>>> (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
I beg to differ. It's X.509 in its purest sense. From clauses 11.1.1 and
11.2.1 of X.509:
> The PKI user object class is used in defining entries for objects
> that may be the subject of public-key certificates.
>
> pkiUser OBJECT-CLASS ::= {
> SUBCLASS OF {top}
> KIND auxiliary
> MAY CONTAIN {userCertificate}
> ID id-oc-pkiUser }
> A user may obtain one or more public-key certificates from one or more CAs.
> The userCertificate attribute type contains the public-key certificates
> a user has obtained from one or more CAs.
>
> userCertificate ATTRIBUTE ::= {
> WITH SYNTAX Certificate
> EQUALITY MATCHING RULE certificateExactMatch
> ID id-at-userCertificate}
The matching rules in RFC 4523 ("LDAP X.509 Schema") are those from
X.509, or as RFC 4523 says in section 1: "As the semantics of these
elements are as defined in X.509 and X.521, knowledge of X.509 and X.521
is necessary to make use of the LDAP schema definitions provided herein."
> - in a lot of practical cases it gets more complex; especially if the
> leave of the one but last intermediate is cross signed.
Sure, but trying to identify a certificate by its certification path
(and in particular, the "other" end of it, i.e. the root / trust
anchor), is an unworkable solution, as it ignores fundamental properties
of X.509.
>>> 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’.
Let me add that "follow the chain" (and use X509_verify_cert to get at
the trust anchor) may give inconsistent results depending on a) what
chain the client provides in the TLS handshake (RFC 5246 section 7.4.6)
and b) what intermediate CAs and trust anchors are configured
server-side (SSLCACertificate{File,Path}), and also on what OpenSSL
version is used - see e.g.
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d65b8b2162f33ac0d53dace588a0847ed827626c#patch1.
>>> 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.
It's pragmatic but incorrect, and is definitely not a "promise" which
mod_ssl can make. To repeat: I'm fine with adding support for
SSL_CLIENT_S_DN_n to mod_ssl, but am opposed to inventing custom schemes
for "uniquely" identifying a certificate and hardcode this into mod_ssl
(in the end, it would convey the message that SSL_CLIENT_CERT_SUBJECTS
is a sound solution for that problem, which it isn't).
> 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.
It seems that you're trying to solve an authorization issue with some
sort of certificate-to-identity mapping (strictly speaking, client
certificate authentication is about authenticating with a key, not with
an X.509 DN). Coming back to Graham's statement "In other words, you may
come in if a) your cert validates to any trusted anchor, and b) your
cert is issued by a specific pre-agreed trust anchor", the fallacy is
trying to rely on the path to the trust anchor. The proper thing is to
require the client certificate(s) to be issued by one or more specific
issuing CAs (which can be configured by means of an SSLRequire directive
which checks for specific SSL_CLIENT_I_DN or SSL_CLIENT_I_DN_x509
values, and optionally SSL_CLIENT_S_* things).
Kaspar
