On 8/23/2016 7:06 AM, Viktor Dukhovni wrote:
> It is the private *key* file not the certificate file that is most likely
> read-protected. Repeat the test with the key file.
>
> Is Exim configured to read both the certificate and the key from the
> same file? Are both in the file you reported to be readable? Please
> do not obfuscate the file names ("/path/to/cert.pem" and the like).
Sorry for causing your confusion. The certificate and key are in
separate files. Both must be readable by the exim user, as I have
discovered.
I did not intend any obfuscation of the file names. I gave the actual
names of the files in the original post of this thread. In writing
"cert.pem" I meant "the file containing the certificate".
The names of the actual symlink files, the owner/group of the link
targets and their permissions are:
(1) bare certificate: cert.pem
root/root -rw-r--r--
(2) authority chain: chain.pem
root/root -rw-r--r--
(3) certificate combined with chain: fullchain.pem
root/root -rw-r--r--
(4) private key: privkey.pem
root/root -rw-r-----
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. (I later
switched to the fullchain.pem, although I believe that virtually no
sending hosts bother with authority checking.) This is one and the same
as the "cert.pem" referred to in "/path/to/cert.pem". I wrote it that
way for brevity, not obfuscation.
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. This is the reason for my
use of the word "weirdness" in titling the thread. 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.
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. 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.
A couple of the other responders raise the question of perhaps SELinux
being the reason for this. As it happens, the tests were conducted with
SELinux disabled, yet it is entirely possible that they are correct. It
is entirely possible that library versions written for use in SELinux
distributions have some behavior that isn't normal Linux behavior
despite SELinux being disabled.
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, and (b) it isn't world-readable (for obvious reasons). The
fact that "tls_privatekey" must be readable by exim I presume is for
using STARTTLS for sending messages, although the TLS error message
about the "tls_privatekey" path occurred on a received message. (I
questioned the need for access to the private key to receive a message,
not considering usage in the other direction.)
- Phil Carroll
