Howard Chu wrote:
Michael Ströder wrote:
BTW:
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.
Ciao, Michael.