Let's Encrypt integration

[carlosbaraza]

Yesterday I did a quick integration of Let's Encrypt in the deprecated MeteorUp repository. These are the pull requests: #873 and meteorhacks/mup-frontend-server#10

CLI

I would like to do this in a better way within this repo. After having a look to the architecture of this new MeteorUp, I thought that could be nice to create another module called tls or ssl, so we could use the following commands in the CLI:

• mup tls status: Give current status of the certificate, expiration, register, etc.
• mup tls renew: Renew the certificate.

Config

To configure Let's Encrypt generator, I was thinking about the following mup.js API:

...
"ssl": {
  "autogenerate": {
    "email": "example@example.com",
    "domains": "example.com"
  }
  ...
}
...

In order to use the renew, it should be needed to include the autogenerate option in the mup.js file.

Frontend server generating certificates

The way I would like to approach the generation is using the Let's Encrypt plugins webroot and standalone. Both behaviours could be included in the meteorhacks/mup-frontend-server container, as Let's Encrypt needs to expose a challenge file using a webserver that will be fetched by the certificate authority using the given domains as URL base. If the file is correctly fetched by them using the domains, the certificate is validated.

The usage I was thinking is mounting a volume to the container including the certificates.

• If certificate volume already include a valid certificate: Container should run like it runs right now, using the certificate.
• If certificate volume includes a valid certificate but it is close to expire and the autogenerate is set up: Container should run a cron job every week to check if the certificate will expire soon and renew the certificate, persisting it through the volume. This will use the webroot plugin, to avoid having downtime for the generation of the certificate.
• If the certificate is not existing or not valid, and the autogenerate is set up: The container should generate a new certificate using the standalone plugin, as nginx can not boot up without the certificate (Another option is having two nginx.conf files). Once the certificate is generated, nginx would boot normally.

Impressions and improvements

If you have any suggestion to improve this implementation, let me know and we can work on it.

[carlosbaraza]

Hi @madushan1000, what do you think about this approach?

[madushan1000]

The proposal looks good,

Let's encrypt apache/Nginx modules seems to be able to do the certificate renewal without stopping/disturbing the server (I haven't tested it though). If we can use Nginx module it's better. But it's still in alpha AFAIK(again I haven't tested how well it works).

In the PR you mentioned, I can see that auto renewal is not yet working. If we can make this work with webroot, or the Nginx module(when it's production ready) with auto renewal It's great.

[carlosbaraza]

Yes, I was a bit in a rush when I did the PRs, so the API was not really thought through. Therefore I am kind of glad I confused the project, cause we can implement it well.

I though about using the Nginx plugin, but I didn't want to introduce a non stable dependency. However, it is worth checking in out (I didn't) to see how stable the Nginx plugin is.

[tomasz-nolberczak]

Hello,

Any news about that feature?

[madushan1000]

@tomasz-nolberczak Hi, we were waiting on nginx let's encrypt module to become stable. @carlosbaraza was using the webroot method to get the certificate as I can recall. Since the nginx module seems to be taking more time, We can start working on a lib/modules/ssl module using the webroot method for now

We can't use standalone method because the productions server must have to be stopped for each certificate renewal. and even getting the webroot method working would be somewhat hackish. We would have to use some kind of a virtual host (I don't know it it's the right term in the context of nginx) to inject the challenge response on our server while it's running. @carlosbaraza any thoughts on how to do that?

[carlosbaraza]

@madushan1000, indeed we have to add a location to the nginx config for the challenge. I already did it in the PR meteorhacks/mup-frontend-server#10.

Here how to use the container: https://github.com/arunoda/meteor-up/pull/873/files#diff-2f09fabea34b444982cf909f840205b1R51

Unfortunately, I will not have more time to invest on this feature in the following two months, as I am 100% booked for other things.

[carlosbaraza]

Hopefully that is helpful and can give some light about how to set that up in nginx.

[wizonesolutions]

@madushan1000 anything I can do to help push this forward? I don't know where to start, but it'd be nice to get this in eventually.

[madushan1000]

We are currently working on this #72, As soon as it finishes this can be continued, follow the changes on @carlosbaraza pull on old mup repo, it should give some insight.

[madushan1000]

Work on pull #72 is over. Anyone interested can start working on this.

[dkmooers]

Big +1 on this, would love to have it. Will do manual generation for now, and then again in 60 days, etc. This would be a killer feature! Just wish CloudFlare would enable websockets on Free/Pro plans, then this would be moot... could just CF's free SSL. Ah well! +1!

[Obiwarn]

+1

[wizonesolutions]

@dkmooers how are you doing manual generation? With letsencrypt-standalone on the server itself?

[dkmooers]

Yep, exactly. Followed these instructions:

https://nickpolet.com/blog/using-letsencrypt-with-meteor-up/P82p2SNZSSfc4mGvT

(which site ironically has an expired cert!)

./letsencrypt-auto certonly --standalone

Except with fullchain.pem and privkey.pem instead of concatenating them to a single ssl.pem b/c I'm using mupx at the moment.

Ran this on my deployment server after pointing my DNS to it, so letsencrypt could verify ownership of the domain.

[vuhrmeister]

@dkmooers I followed those instructions too. But for me it doesn't work. Just running mupx deploy doesn't have any effect.
Running mupx setup fails with x Copying SSL certificate bundle: FAILED

How did you get it working?

*edit: Never mind. First I configured wrong certificates. And mupx didn't manage to override them with the new ones. So I just rebuilt my droplet and started from scratch. That worked!

[dkmooers]

@vuhrmeister Ah got it, well glad you got it figured out!

[thomasf1]

+1

[Obiwarn]

Galaxy just added auto SSL:
http://info.meteor.com/blog/automated-ssl-reserved-pricing-galaxy-europe

@madushan1000: Following your post: Did kadira stop development on this?

[madushan1000]

@Obiwarn We haven't started working on this yet. I'd love to see some community support on this though :)

[mbabauer]

+1

[mbabauer]

As an interim solution until the code supports it directly, couldn't we just use the -v option to point the existing docker image to the certs produced by Let's Encrypt?

[mbabauer]

It actually looks like it uses external files for the certs. I haven't tested it yet, but I think maybe I'll try to simply soft-link them to the Let's Encrypt cert files. This way I can have the certbot client running in a cron, and it should update the certs with no manual work from me.

[mbabauer]

So, it seems that linking from the installed folder to the lets encrypt folder works just fine. Here are the steps I took:

1. Installed Let's Encrypt using standard install (I am on Ubuntu 14.04).
2. Added a cronjob to auto-renew twice a day, as recommended. It puts the certs in /etc/letsencrypt/live/<hostname>.
3. Moved the bundle.crt and private.key to *.orig (so I could go back if things get screwed up)
4. Created a soft link for bundle.crt -> fullchain.pem and private.key -> privkey.pem to the path in step 2. You can find your app certs in /opt/<app_name>/config.
5. Restarted Meteor and tested.

So far this seems to work. The certs are supposed to only last 90 days, so we will see in time if the auto cert renewal works without issues, or if I will have to somehow schedule a restart of the services when the cert is renewed.

[nicooprat]

Hi, any news on this? :)

[mbabauer]

Does anyone know the status of this? It would be nice to simply have a property set in the build file to trigger Let's Encrypt support.

[dkmooers]

Would still love to have support for this. I'm on manual renew at the moment and would be super convenient to have this all happen automatically!

[jirikrepl]

+1
Yes, it would be super handy to have this feature. @carlosbaraza you would be my hero;)

[arunoda]

@madushan1000 we should try to get this or something similar to mup.
Also, there's a mup fork with SSL support too: https://forums.meteor.com/t/meteor-up-fork-with-free-ssl-certificates-by-lets-encrypt/27368

[snajjar]

+1, could the fork be integrated in kadira's and arunoda's mup?

[stefanve]

This thing is working perfectly and I see talks about a merge, but it does not seem to happen?
https://github.com/dtsepelev/meteor-up-letsencrypt/tree/meteor-1.4

[mbabauer]

I am trying to get this to work with the letsencrypt-nginx-proxy, but not having much luck. My fork can be found here if anyone wants help. I think the problem is in how the Meteor docker container is being port-mapped to the nginx proxy, but I am not sure.

[mbabauer]

I updated the last I have working. Most of the docker containers are starting now, all except the nginx one. That one is throwing the following error in it's docker logs:

2016/09/16 10:19:35 [emerg] 1#1: no servers are inside upstream in /etc/nginx/conf.d/default.conf:36

I think the issue now is that the meteor image is exposing port 80, and it's conflicting with the nginx port 80. I need to see if I can customize the meteor docker image to change the startup port back to 3000.

[mbabauer]

Latest update:

After LOTS of frustration with the Let's Encrypt docker project, I finally got something working. The latest checkin in my fork branch is running on my test Meteor server, but I would LOVE to get some others to see what I have done and make improvements. What I have done feels very hack-ish at the moment, and I feel that it may not be "complete" in all the required changes. There is definitely more work to be done, but it does work.

The premise on how this all works:
All my changes are in the start.sh script that is generated when you do the deploy for your app. Instead of pulling down the MUP project's nginx Docker image, it checks to see if the SSL is set to auto-gen. If it is, it pulls down the jwilder/nginx-proxy and jrcs/letsencrypt-nginx-proxy-companion Docker images instead. The jwilder/nginx-proxy image uses the base nginx image and adds the functionality of jwilder/docker-gen, which uses a template to dynamically configure nginx based on the runtime discovery (are there certs present, what ports are exposed on the other containers, etc). The jrcs/letsencrypt-nginx-proxy-companion image runs along side of it, checking if the certs need to be updated and updating them and restarting the nginx container if they are.

Once we get the code cleaned up I can submit a PR to the main project to get those changes pulled in.

[lfilho]

@madushan1000 @arunoda hey lovely folks, any news about this? :-)

[mbabauer]

@lfilho I would welcome your input on the branch I reference above. It is working locally for me but would love others to give some feedback.

[lfilho]

@mbabauer how could I test it? I mean, I already have my app in production and I don't have any extra droplets to test it... Thanks. Appreciate your efforts and contribution towards this 🙂 👍

[brylie]

@carlosbaraza would you please consider opening a pull request in this repository? I do not see one referenced in the discussion.

[brylie]

@mbabauer any status update on opening a PR with your changes? Some of the improvements could be made during the PR review process. That way, we could see the changes and work in progress.

[mbabauer]

@brylie Sure, I can do a PR. Will update w/ the PR number.

*Edit: * PR is #337.

[zodern]

The PR has been merged.

[EmirGluhbegovic]

Hey People, I assume that Lets Encrypt is now usable with Zodern-Meteor up. Is there link anywhere how to set it up?

[zodern]

https://github.com/zodern/meteor-up#autogenerate-certificates