On 8/23/2016 7:34 AM, Chris Siebenmann wrote:
Note that in general there is no such thing as 'the primary cert/key of
a site' for normal TLS certificates. All certificates for a given name
are equivalent and are equally powerful to authenticate the site for any
TLS connection (Exim, website, whatever). The only way to have less and
more powerful/dangerous certificates is to use different hostnames, eg
'smtp.<domain>' for Exim versus 'www.<domain>' for the web server even
if everything runs on the same machine.
I agree, and I probably did no make myself very clear on that.
Private key ownership in general is a delicate issue, but it is not
intrinsically bad to have a private key owned by Exim (or readable by
its group) instead of by root. It's also required by how Exim operates;
Exim definitely must read the certificate and private key after it drops
privileges, because $tls_certificate and $tls_privatekey are not fixed
but are instead string expansions that are evaluated at the time of a
SMTP connection. Unlike eg Apache, Exim doesn't know for sure what TLS
keys it will be using and thus can't read them all before dropping root
permissions.
I understand the dilemma this poses.
I started the thread with the hope of gaining some understanding of the
nuances of TLS with exim. In some part, this arose from a less than
confidence-inspiring statement in 42.12 of the current doc: "In order to
understand fully how TLS works, you need to know about certificates,
certificate signing, and certificate authorities. This is not the place
to give a tutorial, especially as I do not know very much about it
myself..."
I think this thread has largely succeeded in providing enough
understanding for me at least to know what I want to accomplish and how
I might best proceed.
I am now convinced that exim, or possibly the 'email subsystem', as it
were, should have its own dedicated certificate and key. Among the many
reasons for not sharing the LE-backed Web certificate is its short
duration. As pointed out on another exim thread, this short duration can
create a logistical nightmare to support some email-related features.
I also now have security concerns about sharing a private key among some
amorphous group of unrelated software entitities. It seems to make more
sense to dedicate certificates for different purposes. Originally, my
idea was to take advantage of an automated cert-renewal process, but in
light of how things actually work, I no longer see that as a priority.
Exim TLS appears to work quite well with a self-signed cert, which
itself has an entirely automated renewal process. Although, because of
fallback to unencrypted mode, I admit I can't say for certain that it
"works" in the sense of all traffic being encrypted in both directions.
- Phil Carroll
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
