On Thu, Sep 30, 2021 at 02:28:11AM -0400, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> 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. Thanks for that. It's much appreciated. cheers, raf
