On Thu, Sep 30, 2021 at 03:50:41PM +1000, raf wrote:
> > No, because you don't get to choose which CA signed your certificates.
I meant to say "your *peer's* certificates".
> This is what I was expecting to be the case:
>
> That the following extensions are needed for certificates that
> are specified with smtpd_tls_CAfile:
> basicConstraints = CA:true
> keyUsage = digitalSignature, keyCertSign, cRLSign
> extendedKeyUsage = clientAuth
Most CAs don't specify extended key usage at all, and its treatment as a
constraint on the purposes of issued EE certificates lies outside RFC
5280, but is a de-facto practice in some popular implementations,
including OpenSSL. When the extension is not specified in a CA cert, it
is then implicitly unconstrained. If it is specified, it needs to
include at least "clientAuth" in order to be valid for signing client
certificates.
> And that the following extensions are needed for certificates that
> are specified with smtp_tls_CAfile (or lmtp_tls_CAfile):
> basicConstraints = CA:true
> keyUsage = digitalSignature, keyCertSign, cRLSign
> extendedKeyUsage = serverAuth
Converse of above.
> If that's not the case, then perhaps I can ask the question
> in a different way:
I am trying to say, that your trust store will have a bunch of trusted
root CA certs in it, generally none with EKUs set. And what matters is
which CA the peer got its certificate from, and it is *that* CA that
needs approriate certificate extensions, more than than the relying
party looking to check the extensions of the CAs in the trust store.
A small minority of expert users may be using OpenSSL's support for
explicit "TRUSTED CERTIFICATE" objects with the purpose OIDs wrapped
around the signed certificate, which override any EKU extension, but
that's a more advanced topic.
--
Viktor.
