From: "Jan C." on
Actually, this step is not needed to reproduce it :
> Now I set:
> ~ $ postconf -e smtp_tls_CApath=/etc/ssl/certs/
> and reload postfix
>

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.

regards,
Jan

From: Wietse Venema on
Jan C.:
> Actually, this step is not needed to reproduce it :
> > Now I set:
> > ~ $ postconf -e smtp_tls_CApath=/etc/ssl/certs/
> > and reload postfix
> >
>
> 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.

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);
}
}

Unfortunately OpenSSL has no documentation for the
SSL_CTX_set_default_verify_paths() function, so it is hard to be
sure that the function is used in a correct manner.

The change above is based on a patch for the s_client program:
http://rt.openssl.org/Ticket/Display.html?id=2203&user=guest&pass=guest

Wietse

From: Victor Duchovni on
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>".

> Unfortunately OpenSSL has no documentation for the
> SSL_CTX_set_default_verify_paths() function, so it is hard to be
> sure that the function is used in a correct manner.

The function is used correctly, and sadly a large part of the OpenSSL
API that is not internal, and ought to be documented, is not.

> The change above is based on a patch for the s_client program:
> http://rt.openssl.org/Ticket/Display.html?id=2203&user=guest&pass=guest

This largely explains how Postfix came to have the code it does. Since
OpenSSL is both complex and incompletely documented, many OpenSSL client
applications are cargo-cult copies of example code in the OpenSSL apps/
directory, with SSL apps typically borrowing code snippets from s_client
and s_server.

The patch whose URL is above has not yet been adopted into OpenSSL, the
1.0.0a release still has the original code:

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
{
/* BIO_printf(bio_err,"error setting default verify locations\n"); */
ERR_print_errors(bio_err);
/* goto end; */
}

--
Viktor.

From: "Jan C." on
Hello,
ok then t least I know what's the origin of the behavior I had.

On Wed, Jun 9, 2010 at 6:12 PM, Victor Duchovni
<Victor.Duchovni(a)morganstanley.com> wrote:
> 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>".

so what I should do is to suppose that only the certs from
smtp_tls_CApath are trusted and that's all. If I need the system CAs,
I should copy them to my smtp_tls_CApath directory .. correct ?

Thanks for your support,
Jan

From: Victor Duchovni on
On Wed, Jun 09, 2010 at 06:30:59PM +0200, Jan C. wrote:

> Hello,
> ok then t least I know what's the origin of the behavior I had.
>
> On Wed, Jun 9, 2010 at 6:12 PM, Victor Duchovni
> <Victor.Duchovni(a)morganstanley.com> wrote:
> > 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>".
>
> so what I should do is to suppose that only the certs from
> smtp_tls_CApath are trusted and that's all. If I need the system CAs,
> I should copy them to my smtp_tls_CApath directory .. correct ?

Probably, although I don't think we've reached a final decision yet...
My preference is to not trust some random list of CAs that came with the
O/S OpenSSL package when the user specifies an explicit CAfile/CApath,
but this would be an incompatible change.

In my case, the OpenSSL package I use is built by me, and has an empty
default list of trusted CAs, so I never notice the extra default certs.

--
Viktor.