Certificado SSL gratuito: como funciona (Let's Encrypt)

Quase todo site hoje roda em HTTPS, e boa parte desses certificados vem do Let's Encrypt. Ele existe para que a criptografia entre navegador e servidor não dependa de pagar uma autoridade certificadora nem de preencher formulários. A chave é a automação: depois da configuração inicial, um programa pede, prova e renova o certificado sem você tocar em nada.

Se você ainda não sabe o que um certificado TLS faz, comece por o que é SSL/TLS.

O que é o Let's Encrypt?#

O Let's Encrypt é uma autoridade certificadora (CA) pública, operada pela Internet Security Research Group (ISRG), uma organização sem fins lucrativos. Os certificados que ele emite são reconhecidos pelos navegadores e sistemas operacionais comuns, então um visitante não vê aviso algum.

O certificado é do tipo DV (Domain Validation): ele só atesta que quem o pediu controla o domínio. Ele não verifica a identidade da empresa por trás do site. Para a maioria dos sites, bots com painel web e APIs, isso é suficiente.

O Let's Encrypt não cobra pelos certificados. A operação é sustentada por doações e patrocínios, e o custo por certificado é baixo porque tudo é automatizado, sem atendimento nem verificação manual.

Quando você usa o Let's Encrypt por meio de um provedor de hospedagem ou de um painel, o certificado continua sem custo, mas o provedor pode cobrar uma taxa pelo trabalho administrativo dele. Leia o plano antes de supor que tudo sai de graça. Para comparar com certificados pagos, veja quanto custa um certificado SSL.

Como funciona o protocolo ACME?#

ACME (Automatic Certificate Management Environment) é o protocolo que o Let's Encrypt usa. O fluxo tem quatro passos:

1. Pedido. O cliente ACME (Certbot, acme.sh, Caddy, Traefik e outros) gera um par de chaves e pede um certificado para um domínio.
2. Desafio. A CA responde com um desafio: uma tarefa que só quem controla o domínio consegue cumprir.
3. Prova. O cliente cumpre o desafio, publicando um arquivo ou um registro DNS.
4. Emissão. A CA confere a prova, assina o certificado e o cliente o instala.

Como o cliente repete esse fluxo sozinho, a renovação não depende de lembrar uma data no calendário.

Quais são os tipos de desafio?#

O Let's Encrypt aceita três desafios. Os dois mais usados são HTTP-01 e DNS-01.

HTTP-01 é o mais simples: o cliente coloca um arquivo no seu servidor web e a CA o busca pela porta 80. Se você tem vários servidores atrás do mesmo domínio, o arquivo precisa estar em todos. Provedores de internet que bloqueiam a porta 80 impedem esse método.

DNS-01 é o único que emite certificados wildcard (*.exemplo.com). Também funciona com servidores que não estão acessíveis na internet. A contrapartida é automatizar a criação do registro TXT, o que exige que o provedor de DNS tenha uma API. Guardar a credencial dessa API no servidor web é um risco de segurança, então use uma chave com permissão limitada. Se registros DNS ainda são novidade, leia o que são registros DNS.

TLS-ALPN-01 tem suporte limitado entre os clientes e serve para proxies reversos que terminam o TLS.

Como emitir um certificado com o Certbot?#

Pré-requisitos: um domínio apontando para o IP do servidor, a porta 80 liberada e acesso sudo. As instruções de instalação por sistema ficam em certbot.eff.org. Em um servidor Ubuntu ou Debian:

sudo apt install certbot
sudo certbot certonly --standalone -d exemplo.com -d www.exemplo.com

O modo --standalone sobe um servidor temporário na porta 80, então pare qualquer serviço que a esteja usando. Os arquivos ficam em /etc/letsencrypt/live/exemplo.com/: fullchain.pem (certificado e cadeia) e privkey.pem (chave privada, nunca compartilhe).

Para um certificado wildcard, use DNS-01. O modo manual abaixo serve só para testar e não renova sozinho; em produção, use o plugin do seu provedor de DNS:

sudo certbot certonly --manual --preferred-challenges dns -d "*.exemplo.com"

Como verificar e renovar?#

Veja os certificados instalados e a data de expiração:

sudo certbot certificates

Teste a renovação sem emitir nada de verdade:

sudo certbot renew --dry-run

Para conferir o que o servidor está entregando de fato:

echo | openssl s_client -connect exemplo.com:443 -servername exemplo.com 2>/dev/null | openssl x509 -noout -dates -issuer

A saída mostra notBefore, notAfter e o emissor.

A recomendação do Let's Encrypt é renovar bem antes do vencimento, em um horário aleatório, para não gerar picos de tráfego na CA. Como a validade vem encurtando, um intervalo fixo em dias deixa de servir: prefira clientes com suporte a ARI (ACME Renewal Information) ou renove após cerca de dois terços da validade.

A maioria das instalações do Certbot já vem com renovação automática, por um timer do systemd ou uma entrada no cron, mas isso depende do método de instalação. Confirme com systemctl list-timers | grep certbot ou procurando certbot renew em /etc/cron.*/*. Certificados emitidos com --manual não renovam sozinhos.

Por que os certificados estão ficando mais curtos?#

Por anos, o padrão do Let's Encrypt foi de 90 dias. Em dezembro de 2025, ele anunciou um cronograma que reduz essa validade em etapas, primeiro no perfil opcional tlsserver e depois no perfil padrão, classic. As datas e os prazos de cada etapa estão no anúncio oficial. Existe ainda o perfil shortlived, com certificados de poucos dias, que exige renovação muito frequente.

Certificados curtos limitam o estrago de uma chave vazada, mas só funcionam bem com renovação automática. Se você renova na mão, esse é o motivo para automatizar. Outra mudança: o Let's Encrypt encerrou o OCSP em 2025, e os certificados não trazem mais URL de OCSP.

Quais erros aparecem com mais frequência?#

• Falha de validação HTTP-01: o domínio não aponta para o servidor, a porta 80 está bloqueada por firewall ou um redirecionamento quebra o caminho /.well-known/acme-challenge/.
• Limites de taxa (rate limits): há tetos para falhas de validação por domínio e por conta, para certificados idênticos e para certificados por domínio registrado, entre outros. Os valores atuais estão na página de rate limits. Teste com --dry-run antes de emitir de verdade.
• Renovação que para de funcionar: o timer foi desativado, a porta 80 passou a ser usada por outro serviço ou a credencial da API de DNS expirou.
• Navegador acusa certificado inválido: costuma ser a cadeia incompleta (use fullchain.pem, não cert.pem) ou o certificado vencido. Veja erros de certificado SSL.

Como fazer isso na Square Cloud#

Na Square Cloud você não precisa emitir nem renovar certificados: o TLS é automático em todos os planos, com certificado DV renovado sozinho, e o HTTP é redirecionado para HTTPS. Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS, sem configuração.

Para usar um domínio próprio, a partir do plano Standard, você cria no seu registrador os registros DNS mostrados no painel e acompanha a validação em tempo real. O TLS do domínio próprio também é automático, e o domínio continua registrado em seu nome no seu registrador.

Para o passo a passo com domínio próprio, veja como usar um domínio personalizado e a página de domínios.