Hi,
Jeremy Harris <jgh@???> (Di 25 Nov 2014 10:49:47 CET):
…
> As you probably also saw, I added in 4.next a way of
> saying "just use the system default bundle". I've
> not changed the current behaviour with OpenSSL on
> loading both the default and the specified CAs though;
> do you think there is a need for that?
>
> The OpenSSL and GnuTLS implementations behave differently
> in this respect.
tls_verify_certificates seems to cause some trouble. I'm talking about
the main config option, but I assume that everything holds for the smtp
driver option of the same name too.
There are two (probably only loosely related issues):
- The inconsistent results of not setting this option at all,
having a forced failure, and setting it to an empty value.
This could be talked about in another thread.
- The confusing influence on loading a default trust store.
This I'm talking about here and now …
The situation seems to be confusing. Let me repeat the spec (I'm
referring to the recent documents from the git master branch.)
As soon as tls_verify_certificates is set to a non empty value,
Exim loads the system default trust store (openssl version -d).
|With OpenSSL the certificates specified explicitly either by file or directory
|are added to those given by the system default location.
That means, I can't exclude CAs that I have in my system default
location. I can only *add* certificates. What's so bad with this?
There are use cases where a peer certificate has to be verified against
a small set of trusted CAs, and never ever against just any of the CAs
found in the system default location… And for several reasons it is not
an option to modify the system default trust store.
IMHO we need to add an option like 'tls_load_default_certificates'. This
option should be bool and expandable.
[new]
+-----------------------------+---------+-----------+--------------+
|tls_load_default_certificates|Use: main|Type: bool*|Default: ?????|
+-----------------------------+---------+-----------+--------------+
The value of this option is expanded and must then be a bool value.
With being a true value, the certificates specified explicitly in
tls_verify_certificates are added to those given by the system default
location.
[/new]
+-----------------------+---------+-------------+--------------+
|tls_verify_certificates|Use: main|Type: string*|Default: unset|
+-----------------------+---------+-------------+--------------+
The value of this option is expanded, and must then be the absolute
path to a file containing permitted certificates for clients that
match tls_verify_hosts or tls_try_verify_hosts. Alternatively, if
you are using either GnuTLS version 3.3.6 (or later) or OpenSSL, you
can set tls_verify_certificates to the name of a directory
containing certificate files. For earlier versions of GnuTLS the
option must be set to the name of a single file.
[changed]
A forced expansion failure or leaving it unset means no certificates
at all are loaded, not even the system default location. Setting it
to an empty string may result in loading the system default
(depending on tls_load_default_certificates).
[/changed]
The question arises about the default value of
tls_load_default_certificates. The natural value should be 'no',
because then tls_verify_certificates follows the principle of least
astonishment.
Unfortunately this could break existing installations on upgrade. But it
breaks OpenSSL based installations only. For GnuTLS based installations
we would break existing installations with defaulting
tls_load_default_certificates to 'yes'.
(BTW: is GnuTLS capable of loading a system default location
additionally, or don't they have that concept?)
Any suggestions?
I'm biased to what I call the "natural" approach, even it breaks some
configurations. The broken configurations can be fixed easily, and exim
might even issue a warning on '-bV' when OpenSSL is in use and the
tls_verify_certificates is set. Packaged versions of Exim might check
the configuration and suggest the necessary change.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
