Phillip Carroll <[email protected]> (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 ------------ -
signature.asc
Description: Digital signature
-- ## 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/
