Phillip Carroll <domainmanager@???> (Mo 22 Aug 2016 01:01:38 CEST):
> 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.
Directories 0777? Sounds dangerous. I think, Exim doesn't do extensive
checks to ensure system security, but I'd remove the the group/world
write bits from the directories.
(For symlinks the perms do not matter, except the application checks it
(apache is known for this))
> 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
Try to use
sudo -iu <your exim user>
$ cat <your cert path>
$ cat <your key path>
and if this fails (hopefully) follow the chain from the root directory
down to the cert/keys
> 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".
For directories the readability isn't important for Exim, the
x-permission is neccessary, though.
For files the r-bit matters, of course, But not for the world. It's the
Exim user who want's to read the file. Depending on your other readers,
you may need to use o=r for the permissions.
For delivery it may be necessary to add init_groups to the options, I
think, if the cert read access is controlled via some 'ssl-cert' group).
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
