Revista /dev/All

Gerenciar certificados SSL/TLS no Apache HTTP Server (e não só nele) pode ser uma tarefa muito chata. A documentação existente sobre o assunto é escassa (vamos resolver isto em breve) e o próprio processo é exageradamente burocrático, pra não dizer caro. 

Mas e se pudesse ser feito de uma forma rápida, fácil e ainda por cima de graça? Entra em cena dois atores: a iniciativa Let’s Encrypt e o Certbot.

Este post também tem outra função: nele vamos poder por em prática dois conceitos já apresentados neste guia: virtual hosts e proxy reverso. Mas antes vamos à situação de exemplo, que é o próprio /dev/All. 

Nosso exemplo: o /dev/All (e os problemas que vamos resolver)

Recentemente transformamos o /dev/All em um PWA, o que nos obrigou a atender um requisito fundamental do padrão, que é o fato do conteúdo servido obrigatoriamente precisar ser trafegado usando o protocolo TLS/SSL.

(um pouco sobre nomenclatura:
  TLS (Transport Layer Security) e SSL (Security Socket Layer) hoje representam essencialmente a mesma coisa, apesar do TLS ser o sucessor do SSL.
  E quando eu usar o termo HTTPS, já sabe, to falando do protocolo TLS/SSL)

O /dev/All é composto por dois componentes: o Frontend, implementado em Angular (ou seja, é essencialmente um site estático, composto apenas por HTML, CSS, JavaScript e algumas imagens) e sua API, escrita em Spring Boot. Nosso setup portanto é similar ao apresentado na imagem a seguir:

Há dois processos distintos: o Apache e o Tomcat. Para sermos didáticos vamos imaginar que ambos ambos estejam executados no mesmo servidor físico. Se você está seguindo este guia, já sabe o que podemos fazer mantendo uma única instância do Apache:

• Configurar dois virtual hosts: https://devall.com.br e https://api.devall.com.br.
• Incluir uma configuração de proxy reverso, que direciona todo o tráfego do virtual host http://api.devall.com.br para o Apache Tomcat.

Já estamos com uns 75% do caminho andado. Resta agora apenas apresentar os problemas:

• Certificados digitais são caros. No nosso caso precisaremos comprar pelo menos dois. Um para o domínio devall.com.br e outro para api.devall.com.br. Não se engane com promoções de R$ 13,00. Só o primeiro ano tem teste valor: certificados digitais precisam ser renovados esporadicamente, e é aí que vêm a facada.
  (pessoalmente acho extorsivos os valores cobrados).
• Duas configurações distintas para os certificados? Tenho o Apache e o Tomcat. Preciso configurar os dois serviços, cada qual com seu certificado? 

Primeiro a resposta para o segundo problema: não, você não precisa. A partir do momento em que configuramos um proxy reverso para o Tomcat, podemos centralizar toda a configuração de certificados no Apache, o que tornará nossa vida bem mais fácil. Lembra quando disse que um dos objetivos do proxy reverso é justamente interceptar as requisições que chegarão ao serviço alvo e, com isto, inclusive modificá-las? 

E agora a resposta para o primeiro problema: você não precisa comprar certificados digitais se estes agora são oferecidos gratuitamente pelo Let’s Encrypt (e há outras alternativas sobre as quais podemos falar no futuro).

Let’s Encrypt e Certbot

Let’s Encrypt é uma iniciativa da Linux Foundation que tem como objetivo principal tornar a web mais segura através da adoção do protocolo HTTPS, que tem como principal barreira em sua adoção justamente o custo dos certificados digitais.

Para tal, foi criada uma nova entidade certificadora, a Let’s Encrypt, que emite certificados HTTPS (mais precisamente, do tipo Domain Validation (DV)) gratuitamente e que até bem pouco tempo atrás emitia certificados para apenas um domínio. Sendo assim, eu poderia ter um certificado para devall.com.br gratuitamente, mas não para api.devall.com.br

Agora a coisa mudou, e é possível emitir certificados que chamamos de wildcard certificates, ou seja, para todos os subdomínios que você quiser. Há uma única particularidade neste provedor: os certificados tem prazo de validade de 90 dias. Então, depois de 90 dias, você volta à estaca zero e precisa configurar tudo de novo? Nope! Entra em cena o Certbot!

A entidade Let’s Encrypt recomenda o uso de um programa extremamente útil, mantido pela EFF (Electronic Frontier Foundation). Não conhece a EFF? Devia: é uma organização sem fins lucrativos que tem como objetivos aprimorar a privacidade, liberdade de expressão e segurança na Internet (e tem um site excelente que recomendo ser acessado com frequência).

O Certbot irá automatizar todo o processo de instalação de certificados digitais no Apache (não só no Apache, também no Nginx, HAProxy e Plesk) e também sua renovação automática.

Iniciando o processo com Certbot: requisitos ocultos

Minhas primeiras tentativas de uso do Certbot foram frustradas por que um pequeno detalhe não constava na documentação. E o detalhe é: você deve ter pelo menos um virtual host configurado no seu servidor Apache.

E por pelo menos um virtual host, o que digo é: você obrigatoriamente deve ter a diretiva ServerName configurada em seu host, mesmo que seja único. Mais que isto, dado que você provavelmente vai querer ter um “www” no domínio, recomendo que também use a diretiva ServerAlias, tal como vimos no post sobre virtal hosts. 

Eu falei que era um detalhe, né? Pois é: eu menti. São dois. Se você tem mais de um virtual host configurado no Apache, é fundamental que exista um arquivo de configuração por virtual host. (de novo, volte ao post sobre virtual hosts para aprender como proceder).

Finalmente, como instalar os certificados

O procedimento é tão simples que chega a dar vergonha a sua explicação. Essencialmente será uma instalação típica no formato “next next next”. Você basicamente só precisa seguir o que está no site. O únicos detalhes que não são evidentes são os que mencionei na seção anterior.

Primeiro passo: instalar o Certbot

Acesse o site oficial do Certbot (https://certbot.eff.org) e selecione na primeira caixa de seleção a opção Apache e, na segunda, qual o seu sistema operacional, tal como na imagem a seguir:

Se seu sistema operacional estiver na lista a instalação de certificados será ultra tranquila. Será apresentado um script de instalação muito similar ao que você pode ver no print a seguir: execute-o.

Este é um guia para iniciantes, sendo assim não seja arrogante e opte pela opção “automated”. Após ter instalado o certbot, o que você precisa fazer? (você vai ficar de cara…)

Segundo passo: executar o certbot

sudo certbot --apache

Sim, acredite em mim, é basicamente isto. Tendo atendido os certificados que mencionei acima, será iniciado um assistente de instalação em modo texto do certbot para o Apache. 

Primeiro ele lhe perguntará quais domínios quer proteger. Se apenas pressionar enter (até aonde me lembro, basta isto), todos serão protegidos. Logo na sequência será realizada a seguinte sequência de passos:

• O Apache será configurado, isto é, cada arquivo de virtual host será devidamente alterado para que os certificados possam ser usados.
• Os certificados serão baixados para seu computador e instalados na pasta de configurações do certbot.
• E ao final o Certbot irá lhe perguntar se deseja que seja realizado o redirecionamento automático, isto é, se quando o usuário acessar, por exemplo, http://devall.com.br ele deve ser direcionado para https://devall.com.br (é uma boa prática dizer que sim, mas caso precise de realizar alguma validação antes de tornar tudo HTTPS, diga não).
• E serão instaladas tarefas agendadas no cron do Linux para que daqui a 90 dias ou menos os certificados sejam renovados em seu servidor.

Sim meus amigos e amigas, todo este post foi para mostrar que você pode ter os certificados instalados gratuitamente em seu servidor sem custo com apenas um comando e sem burocracia alguma. Legal, né?