Use Let’s Encrypt certificate for mail server

email-serverlets-encryptpostfix

I currently have a free StartSSL certificate for my mail server (postfix/dovecot). Of course, it works fine but Let's Encrypt certificates are easier and faster to work with. My Apache server also uses a Let's Encrypt certificate.

So, if I decide to use a Let's Encrypt certificate for my server, will other mail server reject my e-mails? How many acceptance has Let's Encrypt certificates in the mail world?

I know that every recent web browser accepts Let's Encrypt certificates. So, Let's Encrypt certificates are fine for web. Unless a user works with Windows XP and use a common browser from those times, the web will be properly displayed without browser diagnostic.

But how about a mail server? Does anybody have experience with Let's Encrypt certificates for mail? Specifically, my concern are not with big companies like Gmail, Yahoo or Hotmail, but with other private servers of other companies which perhaps doesn't accept my certificate.

NOTE I'm also worried about old mail clients like Outlook 2007 (some of my customer use them yet, and even Outlook Express), and smartphones (iPhones or Android).

ON-TOPIC EXTRA QUESTION Does Microsoft products delegates certificate management to the OS or other microsoft products? Because if I remember well, at least on Outlook 2003 and/or 2007, the certificate management was in charge of the IE browser; and if I remember well too, installing a user certificate on a browser like Firefox, effectively installed the certificate also on the OS itself (because I think it became system-wide available). So, if I'm right on that and even if a customer of mine has an old mail client, the certificate must be accepted automatically (guessing he has for sure a modern web browser accepting Let's Encrypt CAs), because root CAs from Chrome or Firefox are system-wide available.

In short: Should I take the risk of moving to Let's Encrypt for my mail server or it's better I wait at least one year more.

Best Answer

IMHO: Yes, LE is ready for production.

SMTP

Letsencrypt works great for Mutual-TLS communications between mail servers. Many servers support Opportunistic TLS with Self-Signed certificates, in rare cases will you find an MTA that requires either publicly signed or DANE secured TLS connections.

I use LE Certs on all my postfix servers, and checktls.com gives me all green lights!

[000.100]       Connected to server
[000.405]   <-- 220 vegas.localdomain ESMTP Postfix
[000.405]       We are allowed to connect
[000.406]   --> EHLO checktls.com
[000.500]   <-- 250-vegas.localdomain
250-PIPELINING
250-SIZE 52428800
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.500]       We can use this server
[000.501]       TLS is an option on this server
[000.501]   --> STARTTLS
[000.595]   <-- 220 2.0.0 Ready to start TLS
[000.596]       STARTTLS command works on this server
[000.827]       SSLVersion in use: TLSv1.2
[000.827]       Cipher in use: ECDHE-RSA-AES128-SHA256
[000.828]       Connection converted to SSL
[000.855]       
Certificate 1 of 3 in chain:
subject= /CN=vegas.jacobdevans.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3                                                  
[000.882]       
Certificate 2 of 3 in chain:
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3                                                    
[000.908]       
Certificate 3 of 3 in chain:
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3                                                      
[000.909]       Cert VALIDATED: ok
[000.909]       Cert Hostname VERIFIED (vegas.jacobdevans.com = vegas.jacobdevans.com)
[000.909]   ~~> EHLO checktls.com
[001.006]   <~~ 250-vegas.localdomain
250-PIPELINING
250-SIZE 52428800
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[001.007]       TLS successfully started on this server

POP/IMAP

Letsencrypt certs are Cross-Signed, so even if the OS doesn't support the root, it may already trust the root cross-signed cert. Unlike firefox, Outlook uses the internal CA Trust, which you can control with GPO's and use any CA you like (such as internally signed CAs)

https://letsencrypt.org/certificates/

Manual plugin

You can either perform a manual verification - with the manual plugin.

certbot -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns certonly

Certbot will then provide you instructions to manually update a TXT record for the domain in order to proceed with the validation.

Please deploy a DNS TXT record under the name
_acme-challenge.bristol3.pki.enigmabridge.com with the following value:

667drNmQL3vX6bu8YZlgy0wKNBlCny8yrjF1lSaUndc

Once this is deployed,
Press ENTER to continue

Once you have updated the DNS record, press Enter, certbot will continue and if the LetsEncrypt CA verifies the challenge, the certificate is issued as normally.

You may also use a command with more options to minimize interactivity and answering certbot questions. Note that the manual plugin does not yet support non-interactive mode.

certbot --text --agree-tos --email you@example.com -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns --expand --renew-by-default  --manual-public-ip-logging-ok certonly

Renewal does not work with the manual plugin as it runs in non-interactive mode. More info in the official certbot documentation.

Update: manual hooks

In the new certbot version you can use hooks, e.g., --manual-auth-hook, --manual-cleanup-hook. The hooks are external scripts executed by certbot to perform the task.

Information is passed in environment variables - e.g., domain to validate, challenge token. Vars: CERTBOT_DOMAIN, CERTBOT_VALIDATION, CERTBOT_TOKEN.

certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /path/to/dns/authenticator.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com

You can write your own handler or use already existing ones. There are many available, e.g., for Cloudflare DNS.

More info on official certbot hooks documentation.

Automation, Renewal, Scripting

~~If you would like to automate DNS challenge validation it is not currently possible with vanilla certbot.~~ Update: some automation is possible with the certbot hooks.

We thus created a simple plugin that supports scripting with DNS automation. It's available as certbot-external-auth.

pip install certbot-external-auth

It supports the DNS, HTTP, TLS-SNI validation methods. You can either use it in handler mode or in JSON output mode.

Handler mode

In handler mode, the certbot + plugin calls external hooks (a program, shell script, Python, ...) to perform the validation and installation. In practice you write a simple handler/shell script which gets the input arguments - domain, token and makes the change in DNS. When the handler finishes, certbot proceeds with validation as usual.

This gives you extra flexibility, renewal is also possible.

Handler mode is also compatible with Dehydrated DNS hooks (former letsencrypt.sh). There are already many DNS hooks for common providers (e.g., CloudFlare, GoDaddy, AWS). In the repository there is a README with extensive examples and example handlers.

Example with Dehydrated DNS hook:

certbot \
    --text --agree-tos --email you@example.com \
    --expand --renew-by-default \
    --configurator certbot-external-auth:out \
    --certbot-external-auth:out-public-ip-logging-ok \
    -d "bristol3.pki.enigmabridge.com" \
    --preferred-challenges dns \
    --certbot-external-auth:out-handler ./dehydrated-example.sh \
    --certbot-external-auth:out-dehydrated-dns \
    run

JSON mode

Another plugin mode is JSON mode. It produces one JSON object per line. This enables a more complicated integration - e.g., when Ansible or some deployment manager is calling certbot. Communication is performed via STDOUT and STDIN. Cerbot produces JSON objects with data to perform the validation, for example:

certbot \
    --text --agree-tos --email you@example.com \
    --expand --renew-by-default \
    --configurator certbot-external-auth:out \
    --certbot-external-auth:out-public-ip-logging-ok \
    -d "bristol3.pki.enigmabridge.com" \
    --preferred-challenges dns \
    certonly 2>/dev/null

{"cmd": "perform_challenge", "type": "dns-01", "domain": "bs3.pki.enigmabridge.com", "token": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4", "validation": "ejEDZXYEeYHUxqBAiX4csh8GKkeVX7utK6BBOBshZ1Y", "txt_domain": "_acme-challenge.bs3.pki.enigmabridge.com", "key_auth": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4.tRQM98JsABZRm5-NiotcgD212RAUPPbyeDP30Ob_7-0"}

Once DNS is updated, the caller sends the new-line character to STDIN of certbot to signal it can continue with validation.

This enables automation and certificate management from the central management server. For installation you can deploy certificates over SSH.

For more info please refer to the readme and examples on certbot-external-auth GitHub.

EDIT: There is also a new blog post describing the DNS validation problem and the plugin usage.

EDIT: We currently work on Ansible 2-step validation, will be soon off.

Let’s Encrypt – How to Use Let’s Encrypt as a Free SSL Certificate Provider

I have written a pair of how-tos for running Let's Encrypt SSL certs on CentOS: initial setup & cronning it.

And my per-domain (I use the file naming convention of z-<[sub-]domain-tld>.conf) Apache config files look like this:

<VirtualHost *:80>
ServerName domain.tld
Redirect permanent / https://domain.tld/
</VirtualHost>

<VirtualHost *:443>
    SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/fullchain.pem
    DocumentRoot /var/www/domain
    ServerName domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    ServerAdmin user@domain.tld

    SSLEngine on

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

    <Directory "/var/www/domain">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>

</VirtualHost>

And my ssl.conf looks like this:

#SSL options for all sites
Listen 443
SSLPassPhraseDialog  builtin
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
Mutex sysvsem default
SSLRandomSeed startup file:/dev/urandom  1024
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
SSLCompression          off
SSLHonorCipherOrder     on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Using Let's Encrypt to get SSL certs (and get your site up to an "A" rating from SSL Labs) is pretty straight-forward - once you get past some of the arcana of the Apache configs and LE command-line arguments.