search

PoliGNU / sitedeploy

GNU General Public License v3.0
2 stars 2 forks source link

Setup LetsEncrypt #29

Open diraol opened 7 years ago

diraol commented 7 years ago
leonardofl commented 7 years ago

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

leonardofl commented 7 years ago

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

diraol commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

leonardofl commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

http://polignu.org http://poligen.polignu.org

Diego Rabatone Oliveira

Em 2 de fev de 2017 5:47 PM, "Leonardo Leite" notifications@github.com 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 https://github.com/PoliGNU/sitedeploy/issues/29#issuecomment-277052021, or mute the thread https://github.com/notifications/unsubscribe-auth/AALwvp3fUqJ6Im2Gf-VBThWOLKK6qebgks5rYinVgaJpZM4LvMSX .

leonardofl commented 7 years ago

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

diraol commented 7 years ago

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 commented 7 years ago

With localhost I mean from inside the VM.

diraol commented 7 years ago

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

leonardofl commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

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".