Setup LetsEncrypt

[diraol]

• https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
• https://supermarket.chef.io/cookbooks/acme#knife
• https://github.com/schubergphilis/chef-acme
• https://letsencrypt.org/getting-started/
• https://letsencrypt.org/docs/staging-environment/
• http://letsencrypt.readthedocs.io/en/latest/using.html

[leonardofl]

Let me try this one! (if you are not already on this)

[leonardofl]

In this issue I'll implement the initial certificate installation. The renewal goes to issue #32.

[diraol]

Sure! =)

Just remember to use the staging environment for that.

Hum... but I have a question.... is it possible for us to "test" it on a virtual machine ? Since the 'certificate authority' have to check de domain prior to the certificate emission, it does not seems possible to me to test it outside of a "production environment" (a server where the domain DNS is pointing to).

Does that makes sense?
If so, maybe we can try a "test domain" (something like a dev.polignu.org or test.polignu.org)...

[leonardofl]

Yeap, I was wondering about that (not researched yet), and I was going to ask you about this haha.

Maybe instead a domain name is possible to use 'localhost' on the certificate. So we can use the content of the server_name variable as an argument to generate the certificate. On local tests, server_name=localhost, but on production server_name must hold the domain name.

[leonardofl]

No, it seems the localhost approach is not possible... I'm researching on this.

[leonardofl]

So, following the steps on https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04 and implementing them on Chef seem to be easy.

But make it testable it's really a hard issue.

Let's Encrypt client needs to prove that it controls the domain name. So using a "test domain" on a local virtual machine is not enough, since Let's Encrypt service will be not able to access dev.polignu.org since it's running on localhost... moreover, if the VM is on localhost, how to make DNS point the domain to the VM?

It seems the way is using auto-singed certificates on localhost environment.

However, we can not run all this let's encrypt stuff on production without previous testing! So the solution seems to using a stage environment. It can be a VM on Amazon or Digital Ocean, alive only for a moment to test the Chef recipe. We wouldn't run this all the time, but only in strategical moments: after implementing Let's Encript usage... or just before the first production execution.

And the recipe will need to smartly distinguish if it's running for local, staging or production environment. For each environment the commands to issue a certificate will be different. What is bad, but it seems to be the only way.

What do you think about it?

[diraol]

I agree with your solution. The main problem on the proposed solution is that we have to point the DNS to the Amazon/DO VM, but it take some time to be propagated. So we can not do this kind of test "in a minute".

[leonardofl]

So, about this, my ideia is: the domain name will be a property on chef node.json. So, when we run on Amazon, before we have to edit the json to use the VM url as the domain name (EC2 instances are accessable not only by a public IP, but by a given domain name too).

By the way, the stage environment is good to validate and practice the node.json usage, since in local environment it's created by kitchen.

[leonardofl]

Hey, I'm a little confused about we are serving two sites with different domains (polignu and poligen). How does it work? Usually a domain points to an IP, right? In our case, we have two domains pointing to the same IP. If we call only polignu.org how nginx will redirect this internally? Something like localhost:8080/polignu... and poligen would go to localhost:8080/poligen... OR will they be served on different ports, like pplignu.org -> localhost:8080 and poligen -> 8081?

All this stuff may impact how we must provision the stage environment.

[diraol]

@leoleite, this is done (on nginx) by the directive "server_name". There is no problem having multiple domains on the same IP Address, the webservers (and proxys) can handle the http request evaluating the the request parameters ('server_name' among others). Each domain may have one specific "site-enabled" file, or not. In our case, as both sites (polignu and poligen) will use the same Drupal instance (multidrupal setup) and also they will use the same ssl certificate (the certificate can be emitted by domain and considering all subdomains), may be we can even use just only one "nginx" setup for both sites [on set of server directives for both, just adding both domains on the server_name and redirects rules]. Was my explanation clear? Could you understand what is going on?

[leonardofl]

I believe I understood what you said. But to make it clearer, please, show me how would be the URLs of both sites home pages.

[diraol]

http://polignu.org http://poligen.polignu.org Diego Rabatone Oliveira Em 2 de fev de 2017 5:47 PM, "Leonardo Leite" <[email protected]> escreveu:

…

I believe I understood what you said. But to make it clearer, please, show me how would be the URLs of both sites home pages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALwvp3fUqJ6Im2Gf-VBThWOLKK6qebgks5rYinVgaJpZM4LvMSX> .

[leonardofl]

And from localhost, how do we access these two home pages?

[diraol]

On this case you will have to setup your /etc/hosts file and add the following line:

127.0.0.1  polignu.org poligen.polignu.org

(I'm supposing that you are redirecting the ports from your test VM to your system ports. And it would be better for you to redirect 80 -> 80 and 443 -> 443. If you do 80 -> 8080 and 443 -> 8443 you will face problems with our nginx redirect rules)

[leonardofl]

With localhost I mean from inside the VM.

[diraol]

Ok, for that you will need to setup the /etc/hosts of the VM =) (same lines)

[leonardofl]

Humm... sorry, not there yet.

From our figure, I see HHVM is listening on 8002. So, what does happen if from inside the VM we call directly localhost:8002? Will it serve the polignu or poligen page? How drupal serve different home pages?

At polignu.conf I saw a server block with listen 127.0.0.1:8080; and server_name polignu.org; pointing to some drupal configuration file. Will we have another server block with listen 127.0.0.1:8080; and server_name poligen.polignu.org; pointing to different drupal config files? By the way... if the server block is listening localhost, what does mean the server_name property?

Another point... when varnish invokes nginx, it will invoke localhost:8080, right? So, nginx do not have anymore the domain name. Right? So how nginx (listening 8080) knows it is a request for polignu or poligen? And if it does not need to know, how does it is resolved?

Maybe we should schedule a call =S

[leonardofl]

After calling Diego, the answer for my question is basically: the domain name is kept in a http header and it's carried until reach drupal and drupal itself uses this header to know which site to host. Tks Di!!!!

[leonardofl]

What I've done up to now (and merged into the master):

• Changing repo structure to enable a chef-solo execution on staging (or production). In this case it's better that the cookbook is clearly separated from some top levels artifacts, such as solo.rb and node.json.
• Configuring things to use the ACME cookbook (not so easy... specially in staging... integrating Berkshelf and Chef-Solo still depends upon a dirty hack...)

But about ACME, not success yet =/

In staging the recipe run with no errors and the acme command was run, but it seems the certificate was not created.

But for now it's a kind of hard to test such things, since even in localhost I'm not able to access any content. So I'll back to this issue after handling #33 and being able to access any content from localhost with no certificate complain but "this certificate is self-signed".