Apache HTTP Server para devs- Habilitando o HTTPS com Certbot e Let’s Encrypt

Apache HTTP Server para devs- Habilitando o HTTPS com Certbot e Let’s Encrypt

Gerenciar certificados SSL/TLS no Apache HTTP Server (e não só nele) pode ser uma tarefa tediosa. 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 /dev/All.

O /dev/All (e os problemas que vamos resolver)


 

Algum tempo atrás migramos o frontend do site para o formato PWA, o que tornou necessário habilitar o protocolo TLS/SSL (aka “HTTPS”).

Nota 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 o termo HTTPS aparecer, saiba que estamos referindo ao 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 figura 1:

Figura 1- Representação dos componentes do /dev/All

Há dois processos distintos: o Apache e o Tomcat. A fim de sermos didáticos, vamos imaginar que ambos estejam executados no mesmo servidor físico. Se você está acompanhando nossa série de posts, 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.

Seguidos os dois passos acima estamos quase lá. Mas há dois problemas:

  • Certificados digitais são caros. No nosso caso, será necessário adquirir pelo menos dois certificados. Um para o domínio devall.com.br e outro para api.devall.com.br. É importante não se deixar enganar por promoções de R$ 13,00, pois esse valor se aplica somente ao primeiro ano. Certificados digitais exigem renovações periódicas, e é nesse momento que podem ocorrer aumento nos custos dependendo de qual a sua emissora.
  • Duas configurações distintas para os certificados? Possuo o Apache e o Tomcat. É necessário configurar ambos os serviços com seus respectivos certificados?

Vamos primeiro resolver o segundo problema: graças à configuração do proxy reverso podemos centralizar a gestão de certificados digitais no Apache HTTP Server, visto que todas as requisições irão passar por este componente antes de chegar ao Tomcat.

E agora a resposta para o primeiro problema: você não precisa comprar certificados digitais. Eles são oferecidos gratuitamente pelo Let’s Encrypt (e há outras alternativas que podemos abordar 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é pouco tempo atrás emitia certificados para apenas um domínio. Sendo assim, só seria possível ter um certificado para devall.com.br gratuitamente (sendo que precisamos de um para api.devall.com.br também).

Felizmente coisa mudou, e é possível emitir certificados que chamamos de wildcard certificates, ou seja, para todos os subdomínios que você quiser (exemplo: *.devall.com.br para atender teste.devall.com.br ou coisinha.devall.com.br). 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 ouviu falar sobre a EFF? Fica como dica conhecer: é 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

As minhas primeiras tentativas de utilização do Certbot foram frustradas devido à ausência de um pequeno detalhe 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. Além disso, considerando que é provável que você deseje ter um prefixo “www” no seu domínio, recomendo também utilizar a diretiva ServerAlias, conforme abordado no artigo sobre virtual hosts.

Eu mencionei que seria apenas um detalhe, não é mesmo? No entanto, devo corrigir minha afirmação, pois são, na verdade, dois detalhes. Caso você possua mais de um virtual host configurado no Apache, é essencial que exista um arquivo de configuração para cada virtual host. Sugiro que consulte novamente o artigo sobre virtual hosts para aprender o procedimento adequado a ser seguido.

Finalmente, como instalar os certificados

O procedimento é tão simplificado que chega a ser autoexplicativo. Trata-se, essencialmente, de uma instalação convencional seguindo o formato “avançar próximo próximo”. Basta seguir as instruções presentes no site. Os únicos detalhes não tão evidentes são os que disse no parágrafo anterior. De qualquer modo, vamos ao passo a passo.

Primeiro passo: instalar o Certbot

Acesse o site oficial do Certbot e selecione na primeira caixa de seleção a opção Apache e, na segunda, qual o seu sistema operacional, tal como na figura 2:


Figura 2- Site do CertBot

Caso seu sistema operacional esteja na lista a instalação de certificados, será um passo a passo tranquilo. Será apresentado um script de instalação muito similar ao que está sendo mostrado na figura 3: execute-o.

Figura 3- Script de instalação do Cerbot – não, o /dev/All não usa o Ubuntu 16 😉

Este guia destina-se a iniciantes, portanto, sugiro que não adote uma postura arrogante e opte pela opção “automated”. Após a instalação do Certbot, qual seria o próximo passo a ser realizado? (Você ficará surpreso com a resposta…)

Segundo passo: executar o certbot

sudo certbot --apache

Sim, o processo é simples assim. Após configurar os certificados mencionados anteriormente, será iniciado um assistente de instalação em modo de texto do Certbot para o Apache.

Primeiro ele lhe perguntará quais domínios quer proteger. Se apenas pressionar Enter, 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.

 

 

Posts Relacionados