Use letsencrypt.org when it launches in summer 2015

[JoshData]

Free & automated SSL certificates: https://letsencrypt.org/

[zkanda]

• 1 This should be on by default. :+1:

[dave818]

I agree!

[ghost]

would be brilliant if integration can be achieved +1

[mickume]

+1

[ausminternet]

+1

[JoshData]

I've started working on a simple client library for Let's Encrypt here:

https://github.com/mail-in-a-box/letsencrypt_simpleclient

If anyone can help out with packaging it up nicely, I'd certainly appreciate the help.

[JoshData]

And I've begun working on provisioning for Mail-in-a-Box on a branch:

https://github.com/mail-in-a-box/mailinabox/tree/letsencrypt

Let's Encrypt is still in testing so this won't work yet, but if you try the new script by running tools/certificates.py it should work, up to the point of actually installing it on the box (so it is safe to run).

[nikolay]

@JoshData I just got a few domains whitelisted in the beta. Is the branch usable yet?

[JoshData]

No I don't think so. Let's Encrypt has been changing rapidly pre-launch and the branch is probably broken in a few ways now.

[dave818]

It looks like it's slated to go general availability on November 16th. My SSL cert recently expired, so I'm waiting until then to generate one with LetsEncrypt.

[JoshData]

If anyone is a Python developer, I could use a hand finishing https://github.com/mail-in-a-box/letsencrypt_simpleclient, which is how Mail-in-a-Box will call the Lets Encrypt API. Before I can get back to the letsencrypt branch here, I need to make sure that library actually works.

[tracker1]

Really glad to see this coming together. :-) I don't know python, and it's way down on my todo list, otherwise would love to participate. Are you just going to wrap the letsencrypt client itself, or are you actually making your own?

[ghost]

Using the official LE client would have some upsides. For once, it has a nice and intuitive filesystem setup in /etc/letsencrypt that can simply be scanned for certificated, and for another great advantage, you can renew the certificates with a single command and get updated symlinks in /etc/letsencrypt/live, no moving of files required.

Maybe MIAB could do all of this without user intervention as soon as it detects the domain to be working.

PS: LE General Availability is Dec 3.

[dave818]

I manually installed LE certs on a test MIAB - all of the certs worked, it broke one of the TLSA DNS records though. If I had python experience, I would help out here, but unfortunately I don't. I would be happy to test out the process though.

[tuminoid]

Agree with @DamonGant. Using LE official client with letsencrypt-auto certonly --webroot --webroot-path /home/user-data/www/default -d dom1 -d dom2 ... and symlinking /etc/letsencrypt/live/... certs to /home/user-data/ssl certs works perfectly fine with MIAB 0.14 already.

[ausminternet]

https://twitter.com/Mailinabox/status/677659245156896770 Native integration is on its way!

[alexweissman]

@tuminoid, which certs in /home/user-data/ssl should be linked to which certs in /etc/letsencrypt/live/...?

[alexweissman]

Ok, I think I figured it out:

First, create the certs using --webroot:

cd /opt/letsencrypt
sudo ./letsencrypt-auto certonly --webroot --webroot-path /home/user-data/www/default -d box.example.com

Then, backup the self-signed certs created by MiaB:

cd /home/user-data/ssl
sudo mv ssl_certificate.pem ssl_certificate.pem.old
sudo mv ssl_private_key.pem ssl_private_key.pem.old

Finally, link the cert names used by MiaB to the paths generated by letsencrypt, and restart nginx:

sudo ln -s /etc/letsencrypt/live/box.example.com/fullchain.pem ssl_certificate.pem
sudo ln -s /etc/letsencrypt/live/box.example.com/privkey.pem ssl_private_key.pem
sudo service nginx restart

For completeness, I also wanted to set up auto-renewal (since letsencrypt certs expire after 90 days), so I used a configuration file:

sudo cp /opt/letsencrypt/examples/cli.ini /usr/local/etc/le-renew-webroot.ini
sudo nano /usr/local/etc/le-renew-webroot.ini

Comment out the server = ... line, and uncomment the email, domains, and webroot-path lines:

email = me@gmail.com
domains = box.example.com
webroot-path = /home/user-data/www/default

Use a script to automatically check this domain for renewal:

sudo curl -L -o /usr/local/sbin/le-renew-webroot https://gist.githubusercontent.com/thisismitch/e1b603165523df66d5cc/raw/fbffbf358e96110d5566f13677d9bd5f4f65794c/le-renew-webroot
sudo chmod +x /usr/local/sbin/le-renew-webroot

Check that this script works (should say that the cert is up-to-date and does not currently need to be renewed):

sudo le-renew-webroot

Now, use a cron job to run this script every Monday:

sudo crontab -e

Add the job to your crontab:

30 2 * * 1 /usr/local/sbin/le-renew-webroot >> /var/log/le-renewal.log

Adapted from the DigitalOcean tutorial: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04

[tuminoid]

@alexweissman Yup, thats how I use it.

[dave818]

@alexweissman That is awesome, thank you for all of the details!

[dave818]

@alexweissman the only "issue" I'm seeing is that after installing the new certs, on the MIAB System Status Checks page it shows:

The DANE TLSA record for incoming mail (_25._tcp.box.domain.com) is not correct. It is '3 0 1 f90c8fada4cebed6b247cf83bfff1aa89c878a85c8562c85fe195447efaaa2345' but it should be '3 0 1 a0f6e09089378fa9508c07a94a7cbfad483179f0b25f7f0e461efb3f6b1f665a'. It may take several hours for public DNS to update after a change.

Are you also seeing that? Maybe I should just wait a few hours to see if it updates. I guess I'm not sure how that TLSA records gets generated/updated, but it must be related to the SSL cert.

ETA: https://www.huque.com/bin/gen_tlsa - ah ha, so it is generated from the cert, just not sure how MIAB handles generating it and populating it in DNS.

[alexweissman]

@dave818 I think I had that error when I first installed the cert, but it seems to disappear once the DNS propagates. So, I'd give it a few hours or a day at most.

[dave818]

@alexweissman thank you...hey I just noticed one typo in your instructions above regarding adding it to crontab. You are missing "local" in your path: It should be /usr/local/sbin/le-renew-webroot

30 2 * * 1 /usr/local/sbin/le-renew-webroot >> /var/log/le-renewal.log

[alexweissman]

Thanks, fixed! Phew, glad you caught that or my own renewal would have failed ;-)

[alexweissman]

@JoshData do you know what the ETA is on LE integration? If it will still be a while, I can do a PR on the website and add my interim solution to the setup guide.

[aspdye]

Should answer your question @alexweissman: https://twitter.com/Mailinabox/status/677659245156896770

[alexweissman]

Well that was six days ago, so I'm not sure what the overall timeline is...

[aspdye]

I think it comes with 0.15. the Problem with MiaB is, that it is only powerd by one Person. So there is no real Public Roadmap :sob: :sweat_smile:

[dave818]

For the record, the TLSA record was updated after I modified a record using the Custom DNS page in the control panel. By updating a different record, it must have kicked off a check of the TLSA record and found it was out of date since a new SSL cert was installed. All checks are green now.

[JoshData]

@aspdye This issue is the only item on the roadmap right now. :) I'm really hoping to get a release candidate for v0.15 soon.

[JoshHarmon]

Warning I got from someone after updating my certs (message runs from here to end - formatting unintended):

MX and TLSA records:

joshharmon.com. IN MX 10 box.joshharmon.net.
joshharmon.me. IN MX 10 box.joshharmon.net.
joshharmon.net. IN MX 10 box.joshharmon.net.
_25._tcp.box.joshharmon.net. IN TLSA 3 0 1 0dc52ad25261c70f3c72fd1b5af856d0c7e892c89b2472820c97cf1ddd228149 ; passed

The certificate details are:

Subject = CN=box.joshharmon.net
Issuer = CN=Let's Encrypt Authority X1,O=Let's Encrypt,C=US
Inception = 2015-12-24T06:04:00Z
Expiration = 2016-03-23T06:04:00Z

See https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 for information on why "3 0 1" records should be avoided with LE certificates.

To generate a TLSA "3 1 1" record from a certificate file in PEM format (using OpenSSL 1.0.0 or later):

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
    $(uname -n) \
    $(openssl x509 -in cert.pem -noout -pubkey |
        openssl pkey -pubin -outform DER |
        openssl dgst -sha256 -binary |
        hexdump -ve '/1 "%02x"')

You can use the attached tlsagen script if you prefer,

$ ./tlsagen cert.pem $(uname -n) 3 1 1

or use the website:

https://www.huque.com/bin/gen_tlsa

If you don't update your TLSA record, DANE enabled SMTP servers will not be able to send you email. It is better to not publish TLSA RRs at all, than to publish incorrect data, please take care to maintain correct TLSA records.

See also:

http://tools.ietf.org/html/rfc7671#section-8.1
http://tools.ietf.org/html/rfc7671#section-8.4

for important ongoing operational requirements. When updating the certificate chain you need to temporarily pre-publish multiple TLSA records matching the current and future certificate:

https://dane.sys4.de/common_mistakes#3

[JoshData]

@andysaini Please don't spam issues with lots of +1's. My life isn't a democracy. If you want to see something exist in the world, please start helping out to make it a reality.

[alexweissman]

+1 to what @JoshData said ;-)

[JoshData]

@JoshHarmon Great catch. I've switched the TLSA record format in 392d33b.

[JoshData]

I've just force-pushed a big update to the letsencrypt branch.

[aspdye]

:+1: Great Work @JoshData :wink: Do you plan anything more for 0.16?

[JoshData]

The branch is now merged into master. Give it a try everyone! You can find it in the SSL page on the control panel, or run management/ssl_certificates.py on the command line.

@aspdye Nothing else major, no. To be honest, I don't know that I'm planning anything else major at all. Just want to get the existing feature set as stable as possible.

[aspdye]

@joshdata Great. Maybe we could make this to our 1.0 release :wink: - maybe we could merge the quota aswel ;) the First User is fixed now ;)

[OmgImAlexis]

@JoshData updated to v0.15a and I don't see anything at all on the SSL page about Let's Encrypt.

xo@box:~/mailinabox/management$ python ./ssl_certificates.py 
  File "./ssl_certificates.py", line 326
    re_pem = rb"(-+BEGIN (?:.+)-+[\r\n]+(?:[A-Za-z0-9+/=]{1,64}[\r\n]+)+-+END (?:.+)-+[\r\n]+)"
                                                                                              ^
SyntaxError: invalid syntax

[JoshData]

It's not released yet. 15a only has the zpush fix.

On January 9, 2016 8:31:11 PM EST, X O notifications@github.com wrote:

@JoshData updated to v0.15a and I don't see anything at all on the SSL page about Let's Encrypt.

---

Reply to this email directly or view it on GitHub: https://github.com/mail-in-a-box/mailinabox/issues/268#issuecomment-170299458

Josh Tauberer (@JoshData)

// Sent from my phone.

[zkanda]

Wow, I'm really excited for this. Thanks Josh for your awesome work!

[dave818]

@JoshData out of curiosity, what was broke in v0.14 with zpush? I've been running it for a while now on v0.14 without issue. Maybe only certain conditions caused issues?

[aspdye]

@dave818 He is Talking about 15a and not 15 :wink: Nothing was broken with Zpush in 0.14 but in 0.15. this was fixed by 0.15a.

[JoshData]

See #668.

[ausminternet]

pulled master and get certificates yesterday - worked like a charm!

[JoshData]

Great thanks for posting the feedback!

[ausminternet]

forget to mention: I have a domain, which is not managed by miab - only the mx records are set to my box: setup and the letsencrypt script have correctly handled that.

[shageman]

I pulled down the current master. When I installed new certificates via the admin console, it worked like a breeze for 2 out of 3 names (naked domain and www). The last cert (for the machine name) had been reporting "Certificate has a problem: The certificate is for the wrong domain name" before (see #493). It did not get replaced and is still reporting the same problem.

Is that expected behavior?

[JoshData]

It might be... except for the underlying problem there. It will only install certificates for domains that have missing or expired certificates, and your certificate is probably not expiring soon. Except that it's clearly reading the certificate incorrectly, and so maybe it really is expiring soon but the system can't tell.

I'd delete /home/user-data/ssl/ssl_certificate.pem, re-run Mail-in-a-Box setup to have it generate a new self-signed cert, and then use the admin to get a real cert.

[shageman]

All the certs I had were in fact expiring in a couple of days. For that last cert this was not detected by the system.

The steps you suggest fix the problem - thanks! For whoever follows these steps, you may have to switch from using the domain name to using the IP while the cert is deleted to not get blocked by your browser from accessing the admin console.