[Date Prev][Date Next]
Antw: Re: OpenLDAP with ssl client certs
>>> Michael StrÃder<email@example.com> schrieb am 01.11.2013 um 19:26 in
> Howard Chu wrote:
>> Michael StrÃder wrote:
>>> In case of client certs the cert's subject-DN is the authc-DN which can
>>> directly used in authz-regexp which very much ties the mapping to
>>> conventions of the PKI.
>>> But in some cases it would be very handy to map a distinct client cert to
>>> authz-DN by issuer-DN/serial or even by fingerprint. One use-case is
>>> pinning of client certs and revocation checking done off-line.
>>> Should I file an ITS for that?
>> I would reject such an ITS. Cert-pinning is an issue for clients that have
>> very large collection of trusted CAs. The Admin Guide clearly states that
>> servers should only trust a single CA - the CA that signed its own certs
>> the certs of its clients. In that case, no one else can issue a valid cert
>> with the same subjectDN.
> Unfortunately it's not that easy:
> Consider a (somewhat broken) "official" CA, which you definitely cannot
> or fix and which issues client certs with non-unique subject-DNs. In this
> one has to choose a certain client cert e.g. by issuer-DN/serial for the
CAs either accept the subject name in the certification request, or they deny
it, but they never change it.
> Also consider that you want to off-load revocation checking of client certs
> a external process for better performance. In this case you also need to
> distinguish client certs by some more information than just a subject-DN.
"you" is the process that handles CRLs. That process should be able to do it
> Furthermore it's really not unusal to have several CAs which issue client
> certs for different purposes. So IMHO it should be possible to map client
> certs by a certain CA only to a certain subset of authz-DNs.
That's also wrong: You don't have to observe the issuing CA, but the
certificate's attributes, like "X509v3 Key Usage".
> Anyway I always felt that using directly the subject-DN is not consistent
> the usual "<pattern>,cn=external,cn=auth" used for SASL/EXTERNAL.
> Other server implementations implement client cert to authz-DN mappings by
> cert matching which is really handy in some cases.
> Ciao, Michael.