> On Aug 23, 2016, at 3:03 PM, Phillip Carroll <domainmanager@???> wrote:
>
> (4) private key: privkey.pem
> root/root -rw-r-----
A TLS server needs access to both the public key certificate and the private
key in order to accept TLS connections from TLS clients. The certificate is
*public* information, when a client connects to a TLS server, it receives a
copy of the server's certificate, which it is free to use as it sees fit, but
that certificate is not sufficient to convince other clients that some party
is the server named in the certificate. For the latter, one also needs the
private key.
Similarly, a TLS client that wishes to use X.509 TLS client authentication
needs access to *both* its own certificate and the corresponding private key.
Since X.509 client authentication is rather rare, this is not typically
required. For Postfix users the documentation advises not configuring X.509
client certificates just because a keypair happens to be available, one should
do so only for specific destinations where such a certificate is needed.
Above you a private key that is not readable by the "exim" user, and therefore
the Exim SMTP server cannot make any meaningful use of the associated certificate.
> The tls error message quoted in the original post specifically quotes the full path and file name of the certificate file "cert.pem" exactly as I had specified in the exim "tls_certificate" option.
Mere access to the certificate is not enough.
> My original post pointed out that despite the fact that the "cert.pem" target file is world-readable, for some unknown reason, the file is not accessible via that mode for use by STARTTLS.
Most likely the error message is misleading and the problem file is in fact the
private key file. Otherwise, a parent directory of the problem file does not have
world execute (path access through the directory) permissions or some policy
framework or extended POSIX ACLs block access.
> This is the reason for my use of the word "weirdness" in titling the thread.
There is typically no weirdness. Everything is likely behaving just as one
would expect given all the relevant facts. Things are only weird when one
has but a portion of the story.
> Yet, as described in my second post, the file (with root/root ownership/group) is readable by the stat command when issued by "exim" as the user, as one would expect.
Well, "stat" is not enough, one has to be able to read the content. I requested
that you post the output of the pertinent commands to identify the problem. It
seems you have chosen to not follow though. :-( That limits the help that you
can get to resolve the issue.
> However, the failure message when the file is specified to exim for STARTTLS usage apparently comes from an openssl library function, not exim itself, and this function apparently does not honor the world-readable permission on the file.
That theory is not plausible. The OpenSSL library does not and cannot enforce
file access control, that's done by the O/S. The OpenSSL library does not
report which files it could not open, that's done by Exim (the application).
> Whereas, if the group of the file is changed to a group that exim is a member of (namely, "mail" in my case) then the error disappears.
Which file? The private key surely, since the certificate file is world-readable.
> A couple of the other responders raise the question of perhaps SELinux being the reason for this.
A reasonable guess, when not all the facts are at hand, and your problem description
skips over essential detail.
> On the other hand, the fact that "tls_privatekey" requires a group that exim is a member of derives from the fact that (a) the exim user needs read access,
That's unavoidable, as explained above.
> The fact that "tls_privatekey" must be readable by exim I presume is for using STARTTLS for sending messages,
NO! The private key is always needed by the legitimate holder of the public key
certificate. The direction of subsequent data flow is irrelevant. If either peer
wishes to authenticate itself with an X.509 public certificate it needs the corresponding
private key in order to do so.
> although the TLS error message about the "tls_privatekey" path occurred on a received message.
It is in fact typically the server that needs a public certificate/private key pair, because
X.509 server authentication is typically requested by clients, while X.509 client authentication
is not typically requested by servers.
> (I questioned the need for access to the private key to receive a message, not considering usage in the other direction.)
Unfortunately, that's based on an incomplete/naive mental model of the role of
certificates and private keys in TLS.
--
Viktor.
