>>>>> Andreas Metzler <ametz...@downhill.at.eu.org> writes:
>>>>> Ivan Shmakov <i...@main.uusia.org> wrote:
[...]
>> It seems that the certificate verification fails when Exim connects
>> to the peer, while should the peer in question connect to Exim, it
>> succeeds.
[...]
>> Note the CV=yes vs. CV=no discrepancy.
> Hello, Afaict you have provided exim with a list of trusted
> certificates to check incoming connections (main configuration option
> tls_verify_certificates) against but you have not toggled the
> corresponding option for outgoing connections (the
> tls_verify_certificates private option of the smtp transport).
I've known that I've made some silly mistake! I've fixed that
and it works as expected now, thanks!
However, the documentation is somewhat unclear on that matter:
--cut: (exim4) Configuring an Exim client to use TLS --
The `tls_certificate' and `tls_privatekey' options of the `smtp'
transport provide the client with a certificate, which is passed to the
server if it requests it. If the server is Exim, it will request a
certificate only if `tls_verify_hosts' or `tls_try_verify_hosts'
matches the client. *Note*: These options must be set in the `smtp'
transport for Exim to use TLS when it is operating as a client. Exim
does not assume that a server certificate (set by the global options of
the same name) should also be used when operating as a client.
If `tls_verify_certificates' is set, it must name a file or, for
OpenSSL only (not GnuTLS), a directory, that contains a collection of
expected server certificates. The client verifies the server's
certificate against this collection, taking into account any revoked
certificates that are in the list defined by `tls_crl'.
--cut: (exim4) Configuring an Exim client to use TLS --
Since it's noted explicitly in the fragment above that the
`tls_certificate' and `tls_privatekey' options are to be set for
the transport, the lack of such a notice for
`tls_verify_certificates' made me assume that it's the global
option that's mentioned here.
Could this bug thus be reassigned to the documentation (or the
source?) with the severity downgraded (and probably retitled)?
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
