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.