Howard Chu wrote:
Michael Ströder wrote:
> In case of client certs the cert's subject-DN is the authc-DN which can be
> directly used in authz-regexp which very much ties the mapping to subject-DN
> conventions of the PKI.
> But in some cases it would be very handy to map a distinct client cert to a
> authz-DN by issuer-DN/serial or even by fingerprint. One use-case is cert
> 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 a
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 and
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 avoid
or fix and which issues client certs with non-unique subject-DNs. In this case
one has to choose a certain client cert e.g. by issuer-DN/serial for the mapping.
Also consider that you want to off-load revocation checking of client certs to
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.
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.
Anyway I always felt that using directly the subject-DN is not consistent with
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.