> Changing the group of the private key file to "mail" then resolved
> that issue. However, that raises the question: Why must the private
> key be readable by exim at all? I have always been under the
> impression that a private key should ALWAYS be readable only by root.
>
> I have now restored the group to "root" of the two files, and reverted
> back to the exim-owned cert for STARTTLS usage so that the primary
> private key of the site remains accessible only to root. That seems to
> me the safest scheme.
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.
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.
- cks
