Use on non-web servers?

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):
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

Postfix config /etc/postfix/main.cfg:

It’s working fine, but I’m not sure about the CA-File part, maybe someone can comment about that?

best regards


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.


It is highly “possible” to run the LE client via cron (I do on my server, and did a write-up on my blog, here:

Wolfman, the following postfix and cyrus-imapd configurations should work better:


# smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem


tls_ca_file: /etc/letsencrypt/live/DOMAIN/chain.pem
tls_cert_file: /etc/letsencrypt/live/DOMAIN/cert.pem
tls_key_file: /etc/letsencrypt/live/DOMAIN/privkey.pem

because chain.pem is just LE’s intermediate signing CA certificate, and fullchain.pem is server cert + LE’s signing CA certificate.


  1. 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.

  2. 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.



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).


   tls_ca_file: <none>
        File  containing  one  or more Certificate Authority (CA) certifi‐

   tls_cert_file: <none>
        File  containing  the certificate presented for server authentica‐
        tion during STARTTLS.  A value of "disabled" will disable SSL/TLS.

What did you do about the permissions of /etc/letsencrypt/archive/ though? On my system here it’s:

drwx------. 5 root root 1024 Apr 15 17:48 /etc/letsencrypt/archive/

which of course prevents imapd from being able to read the certs.

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. :frowning:

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 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 :slight_smile: 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.)

Good luck!


Thank you! I’m looking into it.

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 :wink:

The "ACME server on non-HTTPS ports" issue is one that's been extensively discussed on GitHub.

I'd rather not rehash that discussion here because I think the GitHub issue is the best place for it, but you can find that discussion at [...]

Unfortunately that doesn't necessarily cover everything you'd need for mail. has web (i.e. + A/AAAA records) hosted on one machine, and mail (i.e. + MX, + MX/A/AAAA) hosted on another machine. Given this, I believe there is no way to obtain a single certificate valid for all four addresses (,,, we would need to serve SMTP/TLS, as there is no provision for ACME chasing non-A/AAAA records.

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.

You can't use TLS on UDP at all, but you could use DTLS.

The question is whether the protocol and tools already support DTLS. If not, Let's Encrypt is of no use for your application.

1 Like

Thanks for taking out time to respond.

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.

Then you don’t need a signed certificate for that. Simply use pgp or similar and encrypt the logs before transmission.

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.

Kindly guide me"