So I appreciate that the main thrust of this is to secure web servers, allowing them to use HTTPS, but can I use these certificates to also secure a mailserver using (say) Dovecot and Postfix?
6 Likes
Currently using self-signed cert for POP, IMAP, and SMTP (Dovecot & Postfix) and don’t see any reason LE DV certs shouldn’t be usable for this also. I sure hope so. But let’s see what the official word from LE is.
Certificates issued are marked with the X509v3 Extended Key Usage flags for id-kp-serverAuth and id-kp-clientAuth (CPS 1.0 Draft, Section 8.1.2). That technically constraints the certificates to activities where the TLS protocol is used in association with a Domain Name for the purpose of encrypting Internet communications (Subscriber Agreement 1.0.1, Section 3.6). The official Let’s Encrypt client will help you use them for web servers. Other uses permitted by the EKU flags are not officially supported by Let’s Encrypt.
2 Likes
Just in case people reading this thread aren’t familiar with the key usage concept, the Let’s Encrypt certs are indeed intended to be used with POP, IMAP, and SMTP servers and should work fine for these applications.
The applications that are forbidden by the EKU policies are other non-TLS uses such as code signing.
Hopefully the Let’s Encrypt client will eventually even have built-in functionality to help you automatically install certs into servers for other Internet protocols, like IMAP servers.
5 Likes
Sounds like the short 90 day certificate lifetime is pretty much a practicality show stopper for servers not supported by the LE client renewal automation. Really disappointed by find this out. 
4 Likes
Petition the vendors to support the ACME protocol, then 
Well, it’s also a problem for those of us who want or need (for whatever reason) to do manual certificate installation.
If you want ludicrously short expiry times, leave 90 days as the default but at least allow the ability to override it.
7 Likes
From some quick browsing, from a pragmatic viewpoint it looks like it might be possible to use the “letsencrypt” client in standalone mode from some cron scripts to provision and refresh certificates as needed. You could then manually install the certificates as normal, or do that as part of the script.
At this point I freely admit to not being the worlds expert in ACME, or networking. However:
It seems to me that if you’re running multiple TLS-protected services on one server, and want to have ACME clients manage them all, then I think we’re going to have some challenges re where inbound HTTP/HTTPS connections from the ACME servers terminate.
Again, from a pragmatic perspective (as I run a mailserver and a webserver on the same machine) I think I can get around that by running one standalone “letsencrypt” client from a cron script, and getting it to update all the servers certificates as required, after it has temporarily quiesced both the web and mail servers. I can also install the updated certificates from that script at the same time. But it’s a bit clunky.
It would be nice if it would be possible to ask the ACME server to respond on a specific port, then you could have multiple ACME clients active (for multiple applications) on the same physical server, and have them all interacting with ACME servers independently. But I can’t see anything in the ACME protocol definition that allows the Client to request that the Server respond on a non-default port, so I don’t think that’s currently possible.
But feel free to tell me I’m wrong 
1 Like
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
In the current implementation the ACME validation must be performed to a web port, even if the certificate is later going to be deployed on a non-web server. (The standalone authenticator listens on port 443; if you have something else listening on that port, you have to shut it down temporarily in order to use the standalone authenticator.)
1 Like
Thanks for the pointers to those conversations. Personally I’m not convinced by the arguments for fixing the port for the ACME exchanges to 443, but I guess it’s not my specification.
Of more interest to me is the use of HAProxy to allow the sharing of port 443 between a webserver and the standalone ACME server. Although its horrible to have to install and reconfigure so much software just to accommodate the ACME, it’s good to at least see how it can be done.
So, it is absolutely legal to use a LE certificate for HMailServer?
Why should it be illegal? Of course it’s legal.
I mean usually you don’t talk about legal/illegal when it comes to certificates, but rather about working/not working. In this case you can of course also use LE certs for mail servers and it’s going to work.
1 Like
Yes, if you’re using protocols that can support TLS, like IMAPS, POPS, SMTPS, or SMTP with STARTTLS, you can use a Let’s Encrypt cert for those protocols, regardless of your particular server software, as long as your server can directly or indirectly import PEM-formatted certificates.
5 Likes
I just got done setting up Let’s Encrypt on my server. Rather than let the ACME client mess with my server config, I simply deleted my old certificates and key and created symlinks to the LE certificates. Restarted web and E-mail servers and all three (HTTPS, IMAP, and SMTP STARTTLS) are using the certificate and trusting it.
The configuration files for Apache, Dovecot, and Postfix on my server reference the same certificate files.
1 Like
What happens in 60 days when LE certs are renewed? Do the symlinks need to be updated to point at the new LE certs?
I’m using one on my Windows FTP server. Filezilla FTP client doesn’t seem to trust the cert so I’ll have to approve it every three months. I’ll see if I can use it for Remote Desktop as well.
[quote=“NOYB, post:15, topic:425”]
What happens in 60 days when LE certs are renewed? Do the symlinks need to be updated to point at the new LE certs?
[/quote] if they’re like webroot authentication method, the renewed ssl certs all symlink to same link so are unchanged
Actually it will be every 60 days. The first cert will expire in 90 days. After that each subsequent renewed cert will only have 60 days remaining when the previous one expires.
Cert 1: Day 1 Day 30 Day 60 Day 90
Cert 2: Day 1 Day 30 Day 60 Day 90
Cert 3: Day 1 Day 30 Day 60 Day 90
Cert 4: Day 1 Day 30 Day 60 Day 90The symlinks in the server configs point to the certificates in the /etc/letsencrypt/live/[domain]/ directory, so will kept up-to-date. I simply need to restart the servers to load in the new keys and certificates.
Or reload, if that’s supported.