Let's encrypt

[mabo1972]

there will be a support for lets encrypt?

https://letsencrypt.org

[omega8cc]

Yes, we will definitely support this as soon as it is available. See: https://twitter.com/omega8cc

[zkrebs]

+1 this looks awesome.

[radimklaska]

Just some info :)

CCCen, Let's Encrypt - A Free Robotic Certificate Authority: https://www.youtube.com/watch?v=OZyXx8Ie4pA

• 21:55 - non-interactive mode
• 22:55 - standalone mode
• Now issuing test certificates
• Expected launch: June 2015

[chriscroome]

Let's Encrypt is due to go live in mid November 2015.

The standalone method of provisioning certs involved stopping the web server and since certs will only last 90 days this isn't really practical on a production server. However the, yet to be merged, webroot branch allows certs to be created and renewed via the creation of files for domain validation and this would probably be the simplest way to intergrate Let's Encrypt (there should also be a DNS method available, but I haven't had a play with that yet).

[ar-jan]

The public beta starts December 3 (https://letsencrypt.org/2015/11/12/public-beta-timing.html). Looking forward to using this.

[ar-jan]

I'm reading good things about how letsencrypt is working in beta (public beta now), and about these simpler alternative clients: https://github.com/diafygi/acme-tiny and https://github.com/kuba/simp_le.

Would it be feasible to get this in BOA 3.0.0 (as experimental)?

[omega8cc]

Right, we definitely need this in 3.0.0. Thanks for the hints!

[attiks]

I tried the official clients, but it has some drawbacks, like it needs root access.

I think it will be cleaner of there's an aegir add-on, that takes care of everything, the only downside is that the keys will not be created by root, so setting the right permissions might be a problem. The benefit is that the module can create a certificate for all domain names at once.

There's a php lib available at https://github.com/kelunik/acme, they also have a php client, but it needs root for the moment.

Full list of known clients: https://community.letsencrypt.org/t/list-of-client-implementations/2103

[omega8cc]

I think we will integrate simp_le with our xboa tool. We only need a small, clever bash wrapper around this python based tool.

[bery]

Would it be, in the meantime, before 3.0 comes, to allow web-root validation by allowing example.com/.well-known on NGINX? Currently, this URL returns 404.

[attiks]

You can add it, create /data/disk/o1/config/server_master/nginx/post.d/nginx_force_include_acme.conf containing the following, assuming the user is o1

  location ~ ^/.well-known/acme-challenge/ {
    try_files $uri 404;
  }

[macmladen]

Taking into the account that it is still in public beta and that nginx support is currently highly experimental, I am not too sure it is yet ready to be included for the release.

[macmladen]

From the FAQ page, near the end https://community.letsencrypt.org/t/frequently-asked-questions-faq/26

Can I issue a certificate without bringing down my web server?

Yes, the ACME protocol226 is designed to perform server validation without any downtime. You can use the webroot mode541 on the official letsencrypt client, which places a validation file at a specific location on your web server, or the Apache91 mode, which configures a temporary self-signed certificate for validation and gracefully reloads Apache.

[bery]

The thing is that currently nginx configuration block incoming request to example.com/.well-known/ when using the webroot authentication method, so basically we only need to pass this request to the server without any outage

[attiks]

I'm using the above code for nginx and wrote a script that generates the keys and creates a nginx_ssl config file, have used it for 20 sites on 3 servers without any real problem. Keep in mind I'm generating the keys locally, using sshfs to map the webroot, so there's nothing running on the server.

[caldenjacobs]

@attiks Would you mind sharing the script you wrote? I'd like to look at it! Cheers

[attiks]

Have a look at https://gist.github.com/attiks/20091b901d508ad1bdb9

It's quick and dirty and the generation of the nginx include is not there (yet).

[unknownterritory]

Really looking forward for this!

[omega8cc]

Done! The only remaining tiny detail is cron auto-update via daily.sh

[macmladen]

This is truly fantastic, I've been sincerely impatiently waiting for this! :D

But there is a little thing, probably which you are aware of but still: new agent is developed, probably old is going to be deprecated:

https://www.eff.org/deeplinks/2016/05/announcing-certbot-new-tls-robot

And new home is here:

https://certbot.eff.org/#debianwheezy-nginx

Their solution looks like it is built on shell but it is actually based on python (ah, why there have to be so much different languages?!). I'd prefer if that was JavaScript based and actually there are solutions (agents) on npm like:

• https://www.npmjs.com/package/letsencrypt - The main thing
• https://www.npmjs.com/package/letsencrypt-express - To be used from code
• https://www.npmjs.com/package/letsencrypt-cli - Probably ours, to be used in bash
• https://www.npmjs.com/package/letiny - More abstract package

As far as daily script, it is recommended to run two times a day just to be sure it does not expire:

Note: if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.

[omega8cc]

@macmladen Yes, we are aware of the old agent new name (it is not really a new agent, though) -- https://www.eff.org/deeplinks/2016/03/new-name-and-roadmap-lets-encrypt-client, but we don't need it, and we couldn't use it, because we don't want the agent to touch Nginx config -- we maintain this on the BOA / Aegir side. To communicate with LE we are using https://github.com/omega8cc/hosting_le which in turn invokes https://github.com/lukas2511/letsencrypt.sh

We don't need anything else to make it work: https://twitter.com/omega8cc/status/731321340364460032

Running letsencrypt.sh via daily.sh for every SSL enabled site (daily) is more than enough.

[macmladen]

Even better!

The less complexity, the less problems.

This will be excellent move, to have easily enabled and enforced HTTPS for all sites!

I am using Cloudflare for DNS and they also have some HTTPS mumbling and it may make problems so there should be also some sidenote in documentation about using some service like that. I didn't have time to experiment everything about that myself so I am waiting for Let's encrypt inclusion to test and document.

[omega8cc]

Note that we will not force SSL on all sites. It will be configurable within Aegir interface, via Aegir own SSL management modules. We just replace the default Aegir self-signed certs with LE certs.

I should also add that we don't need to run the renewal check more than once daily, because by default letsencrypt.sh will force renewal for any cert which is valid for less than 30 days -- that is a month of attempts before it really expires, which is better than running it twice just before expiration date.

[zanami]

@macmladen So have you tested BOA/LE with Cloudflare? I have bunch of sites proxied via CF and wanted to enable http->https redirect but I'm not sure if it will work. CF free plan doesn't include automatic http to https redirect so I have to do it on my side somehow/ Here's a rather fresh howto from CF but I don't know how BOA set up to work with LE.

[macmladen]

I see the 3.1.0 is out and I am very excited about that, probably the biggest release ever since :)

If I understood well, you are asking on CF/LE/BOA integration: it is a tricky business as you have to balance three delicate systems with their own rules established to protect the system from threats and breaks.

I will not go here into too much detail as there are many things to consider and you have to think well before going with any of your ideas to see how they fit into big picture.

I was evaluating Lets Encrypt before it was included in BOA and I tested on standalone sites outside of BOA (not to break anything), just to see how valid is that option, how does browser behave, etc.

The main thing is that you have to be careful with redirection as both BOA and CF may redirect and you may end in endless loop so you have to do it only in one place and CF is (also) a DNS service that does some things in background so you have to be aware of that and not clash with BOA.

Always check the BOA way first.

The proper way to do that in BOA 3.1.0+ is to set redirection in site configuration as explained in CHANGELOG.txt:

  * How to add Letsencrypt.org SSL certificate to hosted site?

    In your Aegir control panel please go to the site's node Edit tab, then
    under `SSL Settings > Encryption` choose either `Enabled` or `Required`,
    if you want to enable HTTP->HTTPS redirection on the fly. Now click `Save`
    and wait until you will see the Verify task completed. Done!

    NOTE: SSL Settings are not available in the Add Site form, only in Edit.

Use Required (I still didn't upgrade and checked that myself so anyone correct me if I am wrong).

On the other hand, if you want CF solution for some reason and not this BOA you may do the HTTP->HTTPS Redirection even on free plan: it is done with page rules (in the main menu icon row on individual site). There you can set up to three rules under the free plan for specific behaviour on desired URL.

Note the wildcard /* for the URL meaning every URL so you may use some specific, like mygreatshop.com/cart to be protected while others are not (of course, do not bother and have complete site under HTTPS)

I will upgrade probably during weekend so I'll be more experienced on next Monday.

If you wish to check yourself, the best way is to spin some VPS instance (on Digital Ocean, for instance), use your barracuda.cnf and octopus.cnf to replicate your configuration, make new BOA and test how that works for you before doing it on live server.

If you need some more explanation, feel free to ask.

[zanami]

@macmladen Thank you! I guess the 'proper' way to set everything up is 1. Make BOA use LE and 2. Touch nothing on CF side.

This way they are independent so I don't have to remember which domain is under CF etc. Now the main question is whether BOA/LE solution aware of/compatible with CF as it is or not. I've already upgraded but BOA is like a black box to me so I'm not ready to try myself right now.

[bserem]

I believe they do under site rules, you will have to use a wildcard for it to run on all pages.

On 05/31/2016 06:53 AM, zanami wrote:

CF free plan doesn't include automatic http to https redirect so I have to do it on my side somehow