I came across this thread and wanted to share my solution to use a letsencrypt certificate also for
postfix MTA / SMTP server and
Cyrus IMAPd - IMAP server
This is working fine with different IMAP e-mail clients like Thunderbird, K9 mail, outlook, Apple Mail etc. on port 993 / 465
webserver and mailserver for the domain are running on the same machine, this makes things easier. Postfix and Cyrus are therefore using the same certificate. I’ve set up a cronjob to renew the certificate regularly and make sure that Postfix and cyrus can access the certficate (by adding read rights for group mail).
Cronjob (to be executed once a month as recommended):
#!/bin/bash
#
OPTIONS=“certonly --renew-by-default --email name@domain.xx --agree-tos --text”
#
#
# Web & Mailserver
#
/etc/letsencrypt/letsencrypt-auto $OPTIONS --webroot -w /var/www/www.domain.xx/htdocs -d mail.domain.xx -d webmail.domain.xx
#
chgrp mail /etc/letsencrypt/archive /etc/letsencrypt/live
chmod g+rx /etc/letsencrypt/archive /etc/letsencrypt/live
# eventually restart web & mail servers to make sure the new certificates are used
…
The relevant cyrus config /etc/imapd.conf part looks like this:
tls_ca_file: /etc/letsencrypt/live/mail.domain.xx/fullchain.pem
tls_cert_file: /etc/letsencrypt/live/mail.domain.xx/cert.pem
tls_key_file: /etc/letsencrypt/live/mail.domain.xx/privkey.pem
I don’t know about Dovecot and/or Postfix … but I can confirm that my LE certificate + private key work just fine with qmail, using both the STARTTLS patch directly, and using stunnel for SMTPS in the usual way. It works for incoming mail and for outgoing (forwarded) mail. Also FWIW it works using stunnel for POP3S.
There’s nothing in the LE certificate that says “web site only” or “mail transport only” … so it really should just work.
For qmail-starttls and for stunnel, you need to concatenate the certificate and the private key into a single file.
because chain.pem is just LE’s intermediate signing CA certificate, and fullchain.pem is server cert + LE’s signing CA certificate.
Notes
I commented out smtpd_tls_CAfile because we don’t usually verify smtp client certificates, and it’s a waste of memory to load it if we don’t use it at all.
The K-9 Mail Android IMAP client fails to verify the server cert if we don’t load LE’s intermediate signing CA cert into cyrus-imapd. Re-enabling the above tls_ca_file parameter solves the problem.
References
postconf(5):
smtpd_tls_cert_file (default: empty)
... ...
To enable a remote SMTP client to verify the Postfix SMTP server cer‐
tificate, the issuing CA certificates must be made available to the
client. You should include the required certificates in the server cer‐
tificate file, the server certificate first, then the issuing CA(s)
(bottom-up order).
imapd.conf(5):
tls_ca_file: <none>
File containing one or more Certificate Authority (CA) certifi‐
cates.
tls_cert_file: <none>
File containing the certificate presented for server authentica‐
tion during STARTTLS. A value of "disabled" will disable SSL/TLS.
On CentOS systems, postfix and cyrus users are members of the mail group. So I granted cyrus-imapd and postfix access to the certificate files this way:
# cd /etc/letsencrypt
# chmod o-r archive/*/privkey*.pem
# chgrp mail archive/<DOMAIN>/privkey*.pem
# chmod go+x live archive
I’m new to LE, but currently I don’t see how to request a certificate for a mail server where there is no webserver running - it’s a mailserver, after all. My application would be to automatically request the certificate(s) from an entirely different machine, eg. while on the road, then wrap it all up and install the certificate(s) to target machine(s) using something like Ansible. I just want to get the certificate(s). Can I do it without writing my own client?
Addendum: I just figured that I can not do that at all, but need to install the software on my server(s) and let it run as root, too. I’m really NOT happy with that, but it looks like LE needs that to protect against fraudulent certificate requests.
You can run the official client in "standalone" mode, which doesn't require a running webserver. Actually, you should read through all the methods to make sure you understand the benefits and drawbacks of each.
That's not quite right. The official client requires root, but there are plenty of other clients that don't. I hear good things about NeilPang's acme.sh client - it will run on any machine with the standard unix shell, bash, or zsh (even the Win10 preview with bash!), will install certs anywhere you wish, and can run as any user you choose.
As long as you can demonstrate control of the domain, LE will provide you a certificate Don't be put off by the default client or options - they're in place to serve most people the best way. Fortunately the LE guys have made their system quite flexible for those of us that don't fit in a convenient box! (I'm using my certs with Apache, Postfix, and Dovecot, on FreeBSD.)
Not quite, it's very much possible to run the official client without root (excluding 'letsencrypt-auto' I guess), when all directories have the right settings and you're not using the apache or stand-alone plugins..
True, but it’s far easier to say “Then take a look at this other client that is quite powerful and doesn’t require root by default.”
While I use the official client, there’s no reason to deal with the complications of using it in a way the authors didn’t intend when there are perfectly good alternatives that better suit the user’s needs
The easiest way to achieve it is probably to use the DNS challenge method (currently a number of alternate clients support the DNS challenge - certainly all the bash ones do) It is planned that certbot will, but doesn't currently.
I am new to LE. Please spare me some time to evaluate my proposed deployment.
From what I have read so far vis-à-vis my desire to use LE to encrypt all logs coming from several Non-Web server to the OSSEC Manager server over port UDP 1514.
Is this attainable via LE? or which free stuff can be used for what I have described?
You can use the certificates from Let’s Encrypt for any application which is built on SSL or TLS. It appears to me that some parts of OSSEC use these protocols and if you are meet the criteria to get Let’s Encrypt certificates you could use them in those places.
It is not clear to me that this would result in encrypting logs transmitted over port 1514, you would need to consult OSSEC people about whether their software does that.
Let me re-frame my proposal. Please advise.
I intend to encrypt the logs right there on individual non-Web servers, the encryption will happen before logs are being transferred from non-Web servers to OSSEC Manager server.
Is this a streaming transmission (the other servers send log events in real time to the OSSEC Manager over some kind of constantly-open network connection) or is it a batch transmission (the other servers log to their own disks and then upload a copy of their logs once per day or something)?
The former case would probably be best served by TLS or DTLS, while the latter could use file encryption like PGP. I’m afraid that the reference to UDP might mean that it’s more like the former, at least in the current design.
"Thanks for taking time to reply.
This is the scenario I have, Other servers send log events in real time to the OSSEC Manager over constantly-open network connection.
How do I make use of TLS or DTLS in this case? Am asking because, there are lots of my application that are not internet facing (they do not have URL). I assume LE can only be used for applications that has URL.
Don't be put off by the default client or options - they're in place to serve most people the best way. Fortunately the LE guys have made their system quite flexible for those of us that don't fit in a convenient box! (I'm using my certs with Apache, Postfix, and Dovecot, on FreeBSD.)