Este é um acompanhamento no meu post anterior, onde configuramos um servidor de proxy reverso simples usando o nginx. Nesta postagem, garantiremos a conexão entre o cliente e o servidor proxy reverso usando TLS gratuito (a.k.um certificado SSL) da LetSencrypt. Convido você a conferir o post acima mencionado em proxy reverso para o básico.

Pré -requisitos

1. Um servidor com IP público estático. É aqui que o nginx está funcionando.
2. Servidores de back -end com o site pretendido em execução HTTP
3. Um nome de domínio registrado. Eu estarei usando Ranvirslog.com meu nome de domínio principal e os dois sites estão no FQDNS - WW1.ranvirslog.COM e WW2RANVIRSLOG.com

Configurar

Portanto, os endereços IP mudaram desde a última vez, já que estou fazendo essa configuração novamente. Aqui estão os novos ips e nomes de host.

VM/HostName	IP Público	IP privado	Função/função
Reverseproxy	68.183.214.151	10.135.127.136	Ponto de terminação TLS e servidor de proxy reverso
Web1	N / D	10.135.126.102	Hospedagem na Segunda Guerra Mundial.ranvirslog.com Site sobre a porta 80 HTTP
Web2	N / D	10.135.126.187	Hospedagem WW2.ranvirslog.com Site sobre a porta 80 HTTP

Os registros do DNS são configurados, pois ambos os sites (subdomínios diferentes) estão apontando para o mesmo IP público estático. Esse é o endereço IP do nosso proxy reverso nginx:

Uma gravação	Valor
WW1.ranvirslog.com	68.183.214.151
WW2.ranvirslog.com	68.183.214.151

Para fazer com que nossos DNs reversos funcionem sobre HTTP não criptografado, criamos dois arquivos em /etc /conf.D/ nomeado WW1.conf e ww2.Conf cada um com a seguinte configuração:

/etc/conf.D/WW1.conf

servidor
Ouça 80;
Ouça [::]: 80;
Server_name WW1.ranvirslog.com;
Localização /
proxy_pass http: // 10.135.126.102/;
proxy_buffering off;
proxy_set_header x-real-ip $ remote_addr;

/etc/conf.D/WW2.conf

servidor
Ouça 80;
Ouça [::]: 80;
Server_name WW2.ranvirslog.com;
Localização /
proxy_pass http: // 10.135.126.187/;
proxy_buffering off;
proxy_set_header x-real-ip $ remote_addr;

O sistema operacional que estamos usando é o Ubuntu 18.04 LTS e nós temos removido O arquivo/etc/nginx/sites-habilitado/padrão para que o nginx possa atuar puramente como um DNS reverso usando as configurações mostradas acima.

Objetivo

Com o DNS reverso (e os sites de back -end) já em funcionamento, nosso objetivo é instalar um único certificado TLS para ambos os FQDNs (que é a Segunda Guerra Mundial.ranvirslog.com e Segunda Guerra Mundial.ranvirslog.com) em nosso proxy reverso nginx.

O tráfego entre qualquer cliente e o proxy reverso será criptografado, mas o tráfego entre o proxy reverso e os servidores de back -end não é criptografado. No entanto, essa ainda é uma opção infinitamente mais segura do que não ter https. Para os casos em que o proxy reverso e os vários servidores da Web estão no mesmo host, digamos que se você estiver usando contêineres do Docker para hospedar tudo no mesmo VPS, até mesmo esse tráfego não criptografado está contido em um único host.

Instalando o certbot

O CERTBOT é um programa de clientes que será executado em nosso servidor de proxy reverso e negociará um certificado TLS com LetSencrypt. Isso provará deixar o que o servidor de fato tem o controle dos FQDNs que afirma ter controle sobre. Não vamos nos preocupar com o quão CertBot.

Tradicionalmente, você pode usar o CERTBOT como um software independente, que apenas obterá os certificados (que são basicamente apenas longas chaves criptográficas) e salvá -lo no servidor. Mas, felizmente, para a maioria dos sistemas operacionais, existem plugins personalizados para Nginx, Apache e outros softwares. Instalaremos o certbot com nginx plugin. Isso configurará automaticamente o nginx para usar as teclas recém -obtidas e se livrar de regras inseguras, como ouvir HTTP na porta 80.

Se você está usando sistemas baseados em Debian, como no meu caso, estou usando o Ubuntu 18.04 LTS, então a instalação é uma brisa.

$ sudo apt update
$ sudo apt install install-properties-common
$ sudo add-aprop-repositório universo
$ sudo add-aprop-repository ppa: certbot/certbot
$ sudo apt update
$ sudo apt install pyth-certbot-nginx

Outros sistemas operacionais, seu redhat, gentoo, fedora podem seguir as instruções oficiais listadas aqui.

Depois de instalar o certbot com plugin nginx Para sua combinação de sistema operacional, podemos chegar aos negócios.

Obtendo certificados TLS

Para obter o certificado TLS pela primeira vez, execute o seguinte comando:

$ sudo certbot -nginx

Isso vai passar por uma série de perguntas interativas, como mostrado abaixo:

1. Digite seu e-mail

Salvando o log de depuração para /var/log/letSencrypt/letSencrypt.registro
Plugins selecionados: autenticador nginx, instalador nginx
Digite o endereço de e -mail (usado para avisos urgentes de renovação e segurança) (digite 'c' para cancelar): [email protected]

2. Concorde com TOS

Leia os termos de serviço em https: // LetSencrypt.org/documentos/le-sa-v1.2 de novembro-15-2017.pdf. Você deve concordar para se registrar no servidor ACME em https: // acme-v02.API.LetSencrypt.org/diretório
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A) Gree/(c) Anch: A

3. Newsletter opcional

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Você estaria disposto a compartilhar seu endereço de e-mail com a Electronic Frontier Foundation, um parceiro fundador do projeto Let's Encrypt e a organização sem fins lucrativos que desenvolve o CERTBOT? Gostaríamos de enviar um e -mail sobre nosso trabalho criptografar na web, notícias, campanhas e maneiras de apoiar a liberdade digital.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y) es/(n) o: y

4. Ele então detectará os nomes de domínio em seu servidor e, se você deseja selecionar todos os domínios, simplesmente pressione

Quais nomes você gostaria de ativar HTTPs para?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: WW1.ranvirslog.com
2: Segunda Guerra Mundial.ranvirslog.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Selecione os números apropriados separados por vírgulas e/ou espaços ou deixe a entrada em branco para selecionar todas as opções mostradas (digite 'c' para cancelar):

5. Redirecionar tudo para TLS. Eu escolhi a opção 2, para redirecionar tudo para SSL, mas seu caso de uso pode ser diferente. Para novas instalações de back -end, é seguro escolher a opção 2.

Escolha se deve ou não redirecionar o tráfego HTTP para HTTPS, removendo o acesso HTTP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1: sem redirecionamento - não faça mais alterações na configuração do servidor da web.
2: Redirecionar - faça com que todas as solicitações sejam redirecionadas para garantir o acesso HTTPS. Escolha isso para novos sites ou se você está confiante de que seu site funciona no HTTPS. Você pode desfazer essa alteração editando a configuração do seu servidor da web.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Selecione o número apropriado [1-2] depois [ENTER] (pressione 'C' para cancelar): 2

Se tudo correr bem, isso mostrará esta mensagem, apenas para seus nomes de domínio em vez disso.

Parabéns! Você ativou com sucesso https: // ww1.ranvirslog.com e https: // ww2.ranvirslog.com você pode visitar os FQDNs e observar que os sites agora têm a placa de cadeado sugerindo que tudo é criptografado.

Veja os arquivos de configuração

Se você visualizar os arquivos de configuração que criamos anteriormente, a saber /etc /conf.D/WW1.conf e /etc /conf.D/WW2.Conf, você notará que todas as regras “ouvidas 80” desapareceram e algumas novas linhas foram adicionadas ao servidor que a comunicação precisa ser criptografada e a localização dos certificados e chaves para executar a criptografia referida.

Eu recomendo fortemente examinar os arquivos de configuração, pois isso também pode ensinar como instalar corretamente os certificados e escrever arquivos de configuração.

Renovação de certificação

Os certificados típicos letSencrypt são válidos por 90 dias e antes de expirarem, você precisa renová -los. Você pode usar o CERTBOT para primeiro executar a renovação a seco, executando o comando:

$ sudo certbot renow-run-run

Se a operação for bem -sucedida, você verá a seguinte mensagem:

Parabéns, todas as renovações foram bem -sucedidas. Os seguintes certificados foram renovados:

/etc/letSencrypt/Live/ww1.ranvirslog.com/fullchain.PEM (sucesso)
** RUN DRY: Simulando 'CertBot Renow' próximo ao vencimento do CERT
** (Os certificados de teste acima não foram salvos.)

Agora você pode adicionar um trabalho de cron que tentará renovar a cada semana ou mais. O CERTBOT não renovará os certificados, a menos que sejam realmente devido a isso, então você não precisa se preocupar. O comando de renovação real é:

$ CERTBOT RENOVA

Adicione -o ao trabalho Cron da raiz usando:

$ sudo crontab -e

No prompt a seguir, selecione seu editor favorito (escolha Nano se não tiver certeza) e adicione as seguintes linhas no final do arquivo agora aberto:

..
# Por exemplo, você pode executar um backup de todas as suas contas de usuário
# às 5 a.m toda semana com:
# 0 5 * * 1 tar -zcf/var/backups/home.TGZ /Home /
#
# Para mais informações, consulte as páginas manuais de Crontab (5) e Cron (8)
#
# M H Dom Mon Dow Comando
* 2 * * 2 CertBot Renow

Isso administrará o comando de renovação do certbot às 2 da manhã a qualquer minuto aleatório, no segundo dia de cada semana.

Conclusão

Se você é novo nos certificados TLS, experimentar coisas como HSTs pode ser arriscado. Uma vez que essas mudanças são irreversíveis. No entanto, se você quiser descer a toca do coelho da segurança, posso recomendar o blog de Troy Hunt, que é uma das principais inspirações por trás deste anotar.