Victor Duchovni:
> On Wed, Jun 09, 2010 at 11:25:50AM -0400, Wietse Venema wrote:
> 
> > > to sum it up, when smtp_tls_CApath is not empty, CAs from
> > > /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath.
> 
> This is done primarily by OpenSSL, but as Wietse observes:
> 
> > Victor will have to confirm or deny this, but we may have to update
> > the main code in function tls_set_ca_certificate_info():
> > 
> >     if (CAfile || CApath) {
> >         if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
> >             msg_info("cannot load Certificate Authority data: "
> >                      "disabling TLS support");
> >             tls_print_errors();
> >             return (-1);
> >         }
> > +   } else {
> >         if (!SSL_CTX_set_default_verify_paths(ctx)) {
> >             msg_info("cannot set certificate verification paths: "
> >                      "disabling TLS support");
> >             tls_print_errors();
> >             return (-1);
> >         }
> >     }
> 
> We could make this change, but it would be an incompatibility with past
> behaviour. This code dates back to the original TLS patch for Postfix
> releases prior to 2.1, and augments the default system CA paths, instead
> of replacing them.
>
> I guess our documentation has never promised the use of system CAs when
> CApath or CAfile are set, failing to override the system settings is
> counter-intuitive, so I can support this change. We'll also have to
> document the semantics of "CAfile == CApath == <empty>".

The empty setting would correspond with the default system-supplied
CA certificates.

There is at least one Postfix feature that relies on the ability
to override the default system-supplied CA certificates:

   permit_tls_all_clientcerts
          Permit  the  request  when the remote SMTP client certificate is
          verified successfully.  This option must be used only if a  spe-
          cial  CA  issues  the certificates and only this CA is listed as
          trusted CA, otherwise all clients with a recognized  certificate
          would  be allowed to relay. This feature is available with Post-
          fix version 2.2.

It would seem then that permit_tls_all_clientcerts is broken.

What else would be broken by the current practice of always including
the default CA certificates? If there is nothing else, then most
sites would not be affected, but a lot of sites could be at risk of
breaking when we change the CAfile/CApath behavior.

Therefore it would be desirable to provide a compatibility switch
that is "incompatible" for Postfix 2.8 and "compatible" for the
earlier releases.

        Wietse

Reply via email to