Olá a todos,

Para o post desta semana trago-vos algo que certamente reconhecem: o Let’s Encrypt
Contando já com alguns anos de existência, é apoiado para EFF e é a norma hoje em dia para homelabbers e entusiastas que queiram ter certificados assinados por uma CA reconhecida, com um custo 0 (o típico https).

O pressuposto do projeto assenta nos seguintes simples pontos:

• Ser gratuito! Todos podem ter um certificado válido, a custo zero.
• A provisão dos certificados ser automática, com a mínima interação humana possível.
• Ser seguro. A plataforma Let’s Encrypt  é gerida segundo as melhores práticas referentes a TLS
• Ser totalmente transparente. Todos os certificados emitidos podem ser consultados.
• Aberto. O sistema automático e as suas API’s estão publicadas como OSS e como tal todos podem adotar.
• Cooperativo. A semelhança dos protocolos usados o código é aberto e é suportado num esforço comum, para beneficio da comunidade, sem estar sob o controle de nenhuma empresa.

Desde o inicio este projeto tem tido muita aceitação por parte da comunidade. Quem não quer os seus certificados gratuitamente? Existe no entanto condicionantes que vos convido a ver na pagina do projeto oficial.

O post  de hoje debruça-se num dos componentes que nasceu com o advento do Let’s Encrypt – o CertBot.
O certbot é um automatismo que faz o interface entre o vosso servidor https e o servidor do Let’s Encrypt, obtém o certificado, aplica o certificado e reinicia o serviço de httpd.

No nosso caso, temos um servidor http simples, que foi instalado fresh num container.
Para usarmos usar o certbot client e gerar o nosso certificado SSL gratuito, teremos de instalar o mod_ssl e os repositórios EPEL e em seguida os modulos de python para o Certbot:

# yum install epel-release
# yum install httpd mod_ssl python-certbot-apache

Em seguida, e assumindo que o vosso serviço de apache está corretamente em execução, é altura de se testar o certbot:

# certbot –apache -d nuneshiggs.com -d site.nuneshiggs.com

Para o exemplo em mãos, o domínio base será o nuneshiggs.com – blatant self-promotion 🙂

Podemos invocar o comando em modo interativo de forma a obter um certificado que apenas irá funcionar num domínio simples:

# certbot –apache –d nuneshiggs.com

O certbot pode ainda ser mais interativo, sendo apenas necessário ser invocado apenas com o flavor do webserver que o irá invocar (neste caso apache):

# certbot –apache

Desta forma o certbot irá efetuar todas as perguntas necessárias para a construção do nosso certificado associado ao domínio por nós escolhido:
No fim do processo, se com sucesso, iremos ser brindados com a seguinte mensagem:

IMPORTANT NOTES:
 – Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/site.nuneshiggs.com/fullchain.pem. Your cert
   will expire on 2017-06-01. To obtain a new version of the
   certificate in the future, simply run Let’s Encrypt again.
 – If you lose your account credentials, you can recover through
   e-mails sent to [email protected].
 – Your account credentials have been saved in your Let’s Encrypt
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Let’s
   Encrypt so making regular backups of this folder is ideal.
 – If you like Let’s Encrypt, please consider supporting our work by:

   Donating to ISRG / Let’s Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Após o processo finalizar, os nossos certificados irão estar localizados no diretório /etc/letsencrypt/live.

Em seguida, iremos adicionar ao vhost servido com o certificado que criamos, as seguintes linhas:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
#Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains; preload”
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache “shmcb:logs/stapling-cache(150000)”
# Requires Apache >= 2.4.11
# SSLSessionTickets Off
Certificate Path: /etc/letsencrypt/live/site.nuneshiggs.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/site.nuneshiggs.com/privkey.pem

Finalmente efetuamos reload ao daemon de apache validando o resultado do mesmo.

Contudo estes certificados tem uma vida útil muito curta em relação aos certificados pagos, pelo que deveremos implementar um automatismo de renovação dos mesmos.

No meu caso optei por utilizar o cron para invocações automáticas da renovação:

30 2 * * * /usr/bin/certbot renew –renew-hook “systemctl restart httpd” >> /var/log/certificados_renovacao_site.nuneshiggs.com.log

Finalmente uma pergunta que provavelmente alguns de vós terão agora a flutuar na vossa cabeça: Sim, o certbot suporta MAIS que UM vhost em apache e nginx, assumindo que respeitaram a localização indicada para tal na vossa distribuição – e a vossa distribuição é suportada.

Como conclusão do nosso post da semana, foi apresentada aqui uma tool muito útil para garantir a nossa privacidade (passamos de http aberto para TLS), com certificados considerados válidos, assinados por uma CA reconhecida.

Com esta alteração, irão desaparecer os erros de certificados inválidos que acedam aos nossos sites por browser, e ao mesmo tempo, em casos mais particulares onde as redes sejam mais fechadas, os vossos acessos não serão barrados pelo facto dos sites destino  terem um certificados self signed.

Portanto já sabem. Se tiverem duvidas sabem onde me encontrar. Terei o maior prazer em vos auxiliar.
Conto em breve fazer um post onde demonstro o conceito, utilizando reverse proxy’s, mesmo com a metodologia automática de renovação.

Abraço!
Nuno