Hi, Phil -
It's probably not the cause of the error you're seeing, but just in case…
I'm not sure about the wisdom of having all the directories on the paths
protected with 777 (rwx) permissions; that gives anyone on your system the
ability to delete any file or directory within those directories or create
files/directories in them. (Having the certificate file protected 644
merely stops someone changing the data in situ within an existing file, not
form deleting the whole file if memory serves.)
Might be worth checking, just in case something is deciding that having a
777 protected directory in the path is unsafe so can't trust its contents,
although I'd have thought you'd have been given a different error message.
I'm not familiar with Centos but remember going crackers once on some
flavour of Linux with trying to access a file that looked as though it
should be accessible but I was being denied. Turned out to be some sort of
security in Linux and I needed to to add the path to a file somewhere. I
can't remember what the security system was called so can't search for it
for you.
Cheers,
Mike B-)
On 22 August 2016 at 00:01, Phillip Carroll <
domainmanager@???> wrote:
> I am running exim 4.84 on CENTOS 7, with several web domains on the same
> server. I recently converted all domains on the server to use TLS for all
> web traffic, regardless of content, using a common Letsencrypt issued
> certificate. Everything is on a single server, with a single IP.
>
> Because the MX domain matches one of the web domains, it seemed logical to
> reconfigure exim to use the new cert for TLS. However, I cannot get exim to
> use the new cert "in situ" because of a permissions issue.
>
> For those unfamiliar with letsencrypt:
>
> The Letsencrypt "certbot" script installs certificate files and key files
> (in Centos at least) using the following symlinks:
> /etc/letsencrypt/live/<domain>/cert.pem
> /etc/letsencrypt/live/<domain>/chain.pem
> /etc/letsencrypt/live/<domain>/fullchain.pem (cert+chain)
> /etc/letsencrypt/live/<domain>/privkey.pem
> (where <domain> is the principal domain of the certificate)
>
> The actual files are stored at:
> /etc/letsencrypt/archive/<domain>/cert<n>.pem
> Where <n> is a serial that indicates the nth renewal.
>
> All directories on both paths are root owned, with 777 permissions, as are
> the symlinks. The cert and chain files are also root owned and world
> readable with 644 permissions.
>
> If I use:
> tls_certificate = /etc/letsencrypt/live/<domain>/fullchain.pem
> tls_privatekey = /etc/letsencrypt/live/<domain>/privkey.pem
>
> The result for a client host using STARTTLS is:
> TLS error on connection ...
> (SSL_CTX_use_certificate_chain_file file=<path>): error:0200100D:system
> library:fopen:Permission denied
>
> Given that the certificate and all paths are world-readable shouldn't exim
> be able to read it? If I switch back to the self-signed files that were
> generated by an exim startup script, all is well. The difference appears to
> be that those files are owned by the user "exim".
>
> Am I missing some configuration option to tell exim to follow symlinks, or
> is it required that exim own the file specified in the tls_certificate
> option? Or is this some other kind of error?
>
> - 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/
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
