HTTPS

Gerando certificados SSL gratuitos com Certbot

Vimos anteriormente como automatizar a geração de certificados SSL locais para ambientes de desenvolvimento, mas e quando precisamos de um certificado para um servidor de produção? Não podemos utilizar um certificado local auto-assinado nesse caso, e tradicionalmente para gerar um certificado SSL precisamos pagar por isso.

Entretanto, existe algumas alternativas para gerar um certificado SSL válido para seus ambientes fora do ambiente local. Uma dessas formas é com o Certbot. Vamos conhecer nesse artigo o Certbot, como ele funciona e como podemos configurá-lo em um dos nossos servidores.

O que o Certbot faz

Acessar um site que tenha HTTPS é quase um pré requisito hoje em dia. Além de ser recomendável pelos principais navegadores, acessar um site com HTTPS te dá mais segurança e até ajuda no rankeamento do seu site nos resultados de busca do Google. Para isso é preciso ter um certificado SSL emitido por uma Autoridade Certificadora (Certificate Authority) que reconhece a sua titularidade para determinado domínio. Para uma introdução sobre SSL, leia mais no artigo O que é certificado SSL.

Para gerar um certificado SSL válido é preciso vários passos, como entrar em contato com uma Autoridade Certificadora, gerar a chave privada que vai ser utilizada para assinar seu certificado e enviar seu certificado para a Autoridade Certificadora, validar que você é o responsável pelo domínio que deseja utilizar HTTPS, aguardar a resposta da Autoridade Certificadora e configurar seus servidores. Tudo isso precisa ser repetido anualmente ou a cada três anos, pois o certificado SSL tem um prazo de validade, e geralmente existe um custo envolvido para a emissão desse certificado.

Esse processo pode ser automatizado, e o melhor, realizado de forma gratuita, ao utilizar o Certbot. O Certbot é um utilitário em linha de comando mantida pela Eletronic Frontier Fountation (EFF), uma organização sem fins lucrativos que luta pela privacidade online e desenvolve tecnologias para melhorar a segurança na internet.

Junto com Let’s Encrypt, o Certbot faz parte de uma iniciativa da EFF que tem como objetivo encriptar a internet como um todo. Desde o lançamento do Let’s Encrypt e do Certbot (que chegou na sua versão 1.0 recentemente), o percentual do tráfego web que é encriptado saiu de 40% para 77%, segundo dados da EFF.

Com o Certbot é possível gerar certificados emitidos pelo Let’s Encrypt como Autoridade Certificadora, gerar e configurar esse certificado em seu servidor web e renovar automaticamente esse certificado, tudo isso de forma gratuita. Para isso você só precisa ter acesso SSH ao seu servidor e acesso ao sudo. Caso esteja utilizando uma hospedagem talvez você não tenha acesso ao SSH dos servidores, porém algumas hospedagens já suportam a geração de certificados através dos seus painéis.

Vamos acompanhar como gerar esse certificado utilizando um servidor Ubuntu 18.04 LTS com Ngnix.

Como instalar o Certbot no Ubuntu com Nginx

Para efetuar a instalação do Certbot, é preciso que nosso servidor Web já esteja configurado com nosso domínio e esteja rodando com HTTP. O Certbot se encarregará de configurar um desafio com HTTP para validar que você é responsável por aquele domínio. Caso isso não seja possível, existe a opção de efetuar um desafio incluindo um registro TXT no seu domínio, porém esse processo leva mais tempo.

Site sem HTTPS

Ao selecionar sua distribuição e servidor web, você pode consultar as instruções para instalação. No Ubuntu, vamos adicionar o repositório do apt-get do Cerbot e iniciar sua instalação:

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update

sudo apt install certbot python-certbot-nginx

No último comando, temos a variação de um script python com a variação de web server utilizado. Por exemplo, caso esteja utilizando o Apache, você instalaria python-certbot-apache

O próximo passo é executar o certbot com o argumento do servidor web que você irá configurar:

sudo certbot --nginx

Caso se sinta mais confortável, você pode escolher fazer a configuração do seu servidor web manualmente, e somente gerar o certificado com a opção certonly:

sudo certbot certonly  --nginx

Será feita algumas perguntas, como qual o domínio a ser configurado, se você deseja redirecionar todo o tráfego para HTTPS automaticamente, entre outros. Será gerado então sua chave privada para esse certificado e o Nginx será configurado de acordo:

Execução do certbot

Com isso temos nosso servidor configurado e respondendo em HTTPS!

Site com HTTPS

O Certbot irá gerar um certificado com validade de apenas três meses, ao contrário dos certificados de um ou três anos geralmente emitidos por outras Autoridades Certificadoras. Entretanto, o certificado do Certbot é gratuito e se renova automaticamente. É possível testar o processo de renovação automática com o comando:

sudo certbot renew --dry-run

Caso você esteja utilizando outra distribuição Linux, na página inicial do Certbot você pode consultar instruções detalhadas de como instalar em diferentes distribuições e servidores web:

Opções de servidores e distribuições suportadas

O que mais o Certbot pode fazer?

Vimos aqui o processo de geração de certificados no caso que temos acesso ao servidor via SSH. Em uma hospedagem compartilhada isso pode não ser possível, porém caso a mesma forneça suporte para utilizar um certificado SSL gerado por você, é possível gerar o certificado somente na sua máquina local e fazer o upload dos certificados necessários pela sua hospedagem.

É possível até gerar um certificado wildcard, que é válido para todos os subdomínios, caso seu domínio esteja em um DNS suportado. O processo para gerar um certificado wildcard é bem próximo ao mostrado anteriormente, alterando somente os plugins utilizados na hora da instalação.

Para outras variações de configuração, confira a documentação do Certbot para instruções mais detalhadas para seu cenário. Muito provavelmente você encontrará o que precisa.

Para que serve o certificado SSL?

O número de pessoas que executam transações sensíveis na internet (como compras online, transações bancárias, etc.) cresce cada vez mais. Porém, com a facilidade que a internet trouxe em geral para a execução destas operações, os cuidados devem ser redobrados. Analisar e verificar os sites onde estas operações são feitas com o intuito de detectar se o site é confiável, real e seguro é algo essencial.

Por isso, aspectos relacionados a segurança em geral em aplicações web merecem uma atenção especial. A sensação de segurança que uma aplicação web passa a seus usuários é algo extremamente importante, pois inspira confiança e credibilidade. Uma aplicação web precisa garantir que é verdadeira e que as informações trocadas estarão criptografadas e seguras. Visando isso, a implementação de um certificado SSL torna-se algo essencial.

O SSL (Secure Socket Layer) é um mecanismo de criptografia com o objetivo de aumentar a segurança na troca de informações entre clientes e servidores, protegendo a integridade e veracidade do conteúdo que trafega na internet. O certificado garante que a informação do navegador chegará de forma segura desde um cliente (como um browser) até o servidor do site. Quando você coloca seu número de cartão de crédito em uma página que utiliza SSL por exemplo, os números serão codificados e embaralhados, dificultando que um invasor ou interceptador consiga ver o número de cartão de crédito informado.

HTTP - Fundamentos
Curso de HTTP - Fundamentos
CONHEÇA O CURSO

Com a utilização do certificado SSL, o endereço do seu site passa de HTTP para HTTPS, indicando que as informações trafegadas entre cliente e servidor ocorrerão através do protocolo SSL/TLS e que as informações serão criptografadas. Além disso, os browsers modernos passam a exibir o desenho de um cadeado antes da URL, fazendo com que o usuário saiba que a aplicação web é segura.

O HTTPS (sigla para Hyper Text Transfer Protocol Secure ou Protocolo de Transferência de Hipertexto Seguro) é uma derivação do protocolo HTTP com uma camada SSL/TLS adicional implementada, o que adiciona mais segurança ao HTTP. Como o HTTPS utiliza criptografia, as chances de um intruso interceptar as mensagens trocadas entre cliente e servidor e obter acesso ao conteúdo destas mensagens reduz-se consideravelmente, pois as mensagens passam a ser criptografadas através de certificados digitais. Quando falamos sobre aplicações web, essa criptografia é essencial: através do tradicional HTTP, as mensagens são trafegadas como texto puro, ou seja: caso um interceptador capture mensagens HTTP, este terá total acesso a seu conteúdo sem maiores dores de cabeça. Com o HTTPS e sua criptografia inerente, esse risco é drasticamente reduzido.

Além de deixar o seu site mais seguro e confiável, a utilização do certificado SSL traz um outro benefício: a otimização do SEO. São diversos fatores que influenciam o ranqueamento dos sites no Google, sendo que um destes fatores é justamente a utilização de SSL. Como o Google considera o certificado SSL um benefício importante para os usuários, ele prioriza isso ao selecionar os sites que aparecem na busca, melhorando o posicionamento do seu site.

Como ele funciona?

O ciclo de uma transmissão HTTPS começa com um certificado digital. Um certificado digital é como se fosse uma espécie de RG eletrônico, identificando a sua aplicação como sendo uma aplicação confiável e verdadeira. Certificados digitais devem ser obtidos através de entidades certificadoras (ou CAsCertification Authorities), pois somente estas têm as permissões necessárias para gerar certificados digitais válidos. É um processo muito parecido com o RG humano propriamente dito… Um RG não pode ser emitido em qualquer lugar: ele deve ser solicitado somente em locais autorizados a lidarem com a emissão de RGs e que tenham acesso aos sistemas estaduais e nacionais de identificação. É o mesmo cenário com certificados digitais, já que estes irão identificar sua aplicação dentro de toda a web. Algumas entidades certificadoras são Verisign, GeoTrust, Comodo e Amazon. O serviço de geração de um certificado é geralmente pago e deve ser feito peridiodicamente, pois os certificados possuem uma data de expiração. Também existem serviços que emitem certificados de maneira gratuita, como o Let’s Encrypt.

Um certificado é composto basicamente por duas partes: uma chave pública e uma chave privada que são geradas randomicamente pela entidade certificadora. A chave pública é utilizada para verificar os clientes que realizam as requisições, enquanto a chave privada é utilizada para a realização do processo de criptografia.

Quando você se conecta a um servidor que utilize HTTPS/SSL para a transferência de informações, o servidor irá responder inicialmente com a chave pública e o certificado associado à aplicação que está sendo acessada. Cabe ao cliente (como um browser), ao receber esta chave, verificar alguns pontos:

  • Se a chave pública não está expirada (o que ocorre quando o certificado já se encontra expirado);
  • Se a chave pública pertence realmente à aplicação que está sendo acessada;
  • Se o cliente consegue descriptografar a assinatura digital do certificado enviado, o que significa que aquela chave pública e aquele certificado são válidos.

Quando um destes pontos de verificação falha, o cliente (como um browser) aborta a conexão e mostra uma mensagem de alerta para o usuário parecida com a tela abaixo.

Caso todas as verificações ocorram com sucesso, o browser entende que a comunicação está sendo feita com um servidor confiável.

Quando o cliente detecta que a conexão é confiável, o cliente cria uma nova chave, chamada de chave de sessão ou session key. Com a chave de sessão criada, o cliente envia esta chave de volta ao servidor, porém, criptografada com a chave pública validada nos passos anteriores.

Quando o servidor recebe a chave de sessão do cliente, ele utiliza a chave privada (que nunca é trafegada entre as requisições) para tentar obter a chave de sessão informada pelo browser. Um conteúdo criptografado com a chave pública só pode ser descriptografado com a chave privada, o que garante a autenticidade e legitimidade das informações que são trafegadas criptografadas com a chave pública. Caso o servidor consiga realizar este processo, é enviado de volta ao cliente uma resposta de que “está tudo OK”, também chamada de ACK (acknowledgement ou reconhecimento). Esse processo todo é chamado de handshake, pois agora somente o cliente e o servidor têm conhecimento das chaves públicas e de sessão que foram trocadas. É como se o cliente e o servidor tivessem se identificado um com o outro e, após existir a confiança entre os dois, ambos apertassem as mãos e disessem: “sei que você é você mesmo de fato e, por isso, confio nas informações que vamos trafegar entre nós”.

A partir deste momento, o servidor passa a responder as informações de volta ao cliente criptografando-as com a chave de sessão que somente o cliente e o servidor têm conhecimento. O cliente passa a utilizar a chave de sessão para descriptografar as informações enviadas pelo servidor. Quando o cliente precisa enviar informações para o servidor, este utiliza também a chave de sessão para criptografar o conteúdo, enquanto o servidor utiliza a mesma chave (que somente este cliente e o servidor possuem conhecimento) para descriptografar o conteúdo.

Veja que o processo de confidencialidade é bem forte neste processo: se algum interceptador interceptar estas mensagens, este não terá a chave de sessão vinculada ao cliente para descriptografar as mensagens. Ele também não conseguirá obter esta chave de sessão, mesmo que ele tenha acesso à chave pública do certificado: não se esqueça que o conteúdo criptografado com a chave pública só pode ser descriptografado com a chave privada. A única maneira de um invasor conseguir descriptografar o conteúdo é se este, de alguma maneira, tiver acesso à chave privada do certificado do servidor ou à chave de sessão do cliente.

Um ponto interessante é que esse processo de criptografia que é utilizado no HTTPS é chamado por muitos de criptografia assimétrica, já que existem duas chaves de criptografia utilizadas durante o processo: uma estática, mas que fica escondida no cliente (no caso da chave privada) e no cliente (no caso da chave de sessão); e uma chave pública, cujo conteúdo só pode ser descriptografado justamente com a chave privada. Veja que esse processo é diferente da criptografia “tradicional”, que também é dita como criptografia simétrica, onde só existe uma chave estática para a realização do processo de criptografia e descriptografia.