Checklist Let's Encrypt para automação residencial no Debian 13

14 min de leitura · · lets-encrypt, certbot, automacao-residencial, ssl, debian-13, https, AviraHost · 0

Checklist Let's Encrypt para automação residencial no Debian 13 é a sequência de verificações e comandos para emitir, instalar e renovar certificados TLS gratuitos em painéis como Home Assistant, Node-RED e proxies locais. Para proteger a automação residencial com HTTPS confiável no Debian 13, siga estes passos:

  1. Confirme domínio, DNS e portas 80/443 no host Debian 13.
  2. Instale o Certbot e o plugin adequado ao desafio (HTTP-01 ou DNS-01).
  3. Emita o certificado para o hostname do painel de automação.
  4. Aponte o reverse proxy ou o serviço TLS para fullchain e privkey.
  5. Ative renovação automática e teste com dry-run.
  6. Valide HTTPS no navegador e no firewall da casa.

Pré-requisitos

  • Debian 13 atualizado, com acesso root ou sudo via SSH.
  • Domínio (ou subdomínio) com registro A/AAAA apontando para o IP público do servidor de automação.
  • Porta 80 liberada no roteador e no firewall para o desafio HTTP-01, ou API do provedor DNS para DNS-01/wildcard.
  • Serviço de automação residencial já em execução (Home Assistant, Node-RED, MQTT com painel web, etc.) e, de preferência, um reverse proxy (Nginx ou Caddy).
  • Certbot disponível nos repositórios do Debian 13 (pacote certbot e, se usar Nginx, python3-certbot-nginx).
  • Horário do sistema sincronizado (NTP/systemd-timesyncd), essencial para validação TLS.

Checklist Let's Encrypt para automação residencial no Debian 13: o que validar antes de emitir

Antes de rodar o Certbot, o checklist Let's Encrypt para automação residencial no Debian 13 começa pela rede e pelo DNS. Em casa, o servidor costuma ficar atrás de NAT: o roteador precisa encaminhar a porta 80 (e depois a 443) para o IP interno do Debian 13. Sem isso, o desafio HTTP-01 falha com timeout mesmo com o Certbot instalado corretamente.

Verifique o hostname e a resolução pública. O nome que você digitar no Certbot deve bater com o registro DNS. Se o painel for hass.seudominio.com.br, o A/AAAA desse FQDN deve responder com o IP que a internet enxerga. Em IP dinâmico ou CGNAT, o HTTP-01 costuma ser frágil; nesse caso o checklist aponta para DNS-01.

hostname -f
dig +short hass.seudominio.com.br A
ss -tlnp | grep -E ':80|:443'
timedatectl status
Output esperado:
hass.seudominio.com.br
203.0.113.40
LISTEN 0 128 0.0.0.0:80 ...
System clock synchronized: yes

Confirme também que nenhum outro container ou serviço “segura” a porta 80 sem estar preparado para o desafio. Se o Home Assistant ou o proxy já escutam 80, planeje parar temporariamente, usar o plugin do Nginx ou migrar para DNS-01. Documente o caminho dos certificados que o proxy usará: no Debian com Certbot, o padrão é /etc/letsencrypt/live/NOME/fullchain.pem e privkey.pem. Para o mapeamento de zona e registros, o Guia de zona DNS: registros A, MX, CNAME e TXT do zero ajuda a evitar CNAME errado no apex ou TTL excessivo durante o teste.

Instalar Certbot e emitir certificado TLS no Debian 13

A emissão de certificado TLS com Certbot no Debian 13 é o núcleo prático do checklist. Atualize os índices de pacotes e instale o Certbot. Se o reverse proxy for Nginx, inclua o plugin correspondente para que o Certbot ajuste o server block ou use o modo standalone com cuidado.

sudo apt update
sudo apt install -y certbot python3-certbot-nginx
Output esperado:
Reading package lists... Done
...
Setting up certbot ...
Setting up python3-certbot-nginx ...

Com o Nginx já servindo o painel de automação na porta 80, o fluxo mais simples é o plugin Nginx. Substitua o domínio pelo FQDN real do Home Assistant ou do gateway:

sudo certbot --nginx -d hass.seudominio.com.br --agree-tos -m [email protected] --redirect
Output esperado:
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/hass.seudominio.com.br/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/hass.seudominio.com.br/privkey.pem
...
Congratulations! You have successfully enabled HTTPS

Se não houver Nginx e a porta 80 puder ficar livre por alguns segundos, use standalone. Atenção: o modo standalone sobe um servidor temporário na 80; pare o serviço que estiver escutando essa porta antes de continuar, senão o Certbot falha com “address already in use”.

sudo systemctl stop nginx
sudo certbot certonly --standalone -d hass.seudominio.com.br --agree-tos -m [email protected]
sudo systemctl start nginx

Para automação com vários subdomínios (hass, nodered, grafana), o desafio DNS-01 com wildcard entra no checklist. Exemplo genérico (ajuste o plugin ao seu provedor DNS):

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

O Certbot pedirá um registro TXT _acme-challenge. Publique-o, aguarde a propagação e confirme. Wildcard cobre subdomínios, mas não substitui o nome nu se você também acessar o apex; emita ambos quando necessário. Depois da emissão, aponte o proxy para os arquivos em /etc/letsencrypt/live/ e recarregue o serviço TLS. Se ainda restar tráfego HTTP puro, configure redirecionamento conforme o material Como redirecionar um site http para https?.

Integrar o certificado ao proxy da automação residencial

Integração do certificado ao reverse proxy da casa é o passo em que o HTTPS deixa de ser “arquivo no disco” e passa a proteger o painel. No Nginx, o server block do subdomínio de automação deve referenciar fullchain e privkey, forçar TLS moderno e, se possível, HSTS só depois de validar que não há clientes legados quebrando.

server {
    listen 443 ssl http2;
    server_name hass.seudominio.com.br;
    ssl_certificate     /etc/letsencrypt/live/hass.seudominio.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hass.seudominio.com.br/privkey.pem;
    location / {
        proxy_pass http://127.0.0.1:8123;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
sudo nginx -t && sudo systemctl reload nginx
Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

No Home Assistant atrás do proxy, habilite o uso de cabeçalhos de proxy confiáveis e o acesso externo apenas via HTTPS. Evite expor a porta interna 8123 diretamente na internet se o TLS termina no Nginx. Para Node-RED e outros dashboards, o mesmo padrão se aplica: um server_name por host, certificados corretos e WebSocket com Upgrade quando o painel usar tempo real.

Valide no cliente:

echo | openssl s_client -connect hass.seudominio.com.br:443 -servername hass.seudominio.com.br 2>/dev/null | openssl x509 -noout -issuer -dates -subject
Output esperado:
issuer=C = US, O = Let's Encrypt, CN = R3
notBefore=...
notAfter=...
subject=CN = hass.seudominio.com.br

Se o issuer não for Let's Encrypt ou o CN/SAN não bater com o hostname, o navegador mostrará aviso e o checklist não está completo. Em ambiente de laboratório com IP privado apenas, o Let's Encrypt público não emite; use DNS público resolvível ou um laboratório com desafio DNS-01 bem configurado.

Renovação automática e checklist operacional contínuo

Renovação automática do Certbot no Debian 13 fecha o ciclo do checklist operacional. Certificados Let's Encrypt expiram em cerca de 90 dias; o pacote no Debian costuma instalar um timer systemd que executa certbot renew. Confirme o timer e faça dry-run antes de confiar na produção da casa.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run
Output esperado:
certbot.timer ...
...
Congratulations, all simulated renewals succeeded

Se o dry-run falhar, o problema costuma ser porta 80 bloqueada, DNS alterado ou plugin que não consegue recarregar o proxy. Para não derrubar a automação a cada tentativa, use um deploy-hook que apenas recarrega o Nginx quando houver renovação real:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Inclua no checklist mensal: espaço em disco em /etc/letsencrypt, permissões da privkey (somente root), e teste de acesso HTTPS ao painel. Em servidores remotos ou VPS que hospedam o proxy da casa, o acesso SSH estável importa tanto quanto o TLS; o guia Acessando servidores VPS Linux da AviraHost cobre o acesso administrativo ao host. Mantenha o firewall restritivo: 443 aberta para o painel, 80 só se ainda usar HTTP-01, e SSH limitado a IPs confiáveis.

Checklist Let's Encrypt para automação residencial no Debian 13 após o go-live

  • Certificado válido no navegador sem aviso de autoridade.
  • certbot certificates lista o domínio e a data de expiração futura.
  • Timer de renovação ativo e dry-run OK.
  • Proxy recarrega sem reiniciar containers do Home Assistant desnecessariamente.
  • Firewall e port-forward coerentes com o desafio escolhido.
  • Backup dos arquivos em /etc/letsencrypt em mídia segura (a privkey é sensível).
sudo certbot certificates
Output esperado:
Found the following certs:
  Certificate Name: hass.seudominio.com.br
    Domains: hass.seudominio.com.br
    Expiry Date: ... (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/hass.seudominio.com.br/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/hass.seudominio.com.br/privkey.pem

Problemas comuns e como resolver

Sintoma: connection refused ou timeout no desafio HTTP-01

Causa: registro A/AAAA incorreto, CGNAT, porta 80 não encaminhada no roteador ou outro processo ocupando a 80 sem responder ao ACME.
Solução: confira DNS público, ss -tlnp na 80, regras de firewall e port-forward. Em IP dinâmico ou CGNAT, mude o checklist para DNS-01. Reveja logs com sudo journalctl -u certbot e a saída do próprio Certbot.

Sintoma: certificado emitido, mas o painel ainda mostra HTTP inseguro

Causa: proxy não aponta para fullchain/privkey, server_name errado ou cache do navegador; às vezes o app mobile ainda usa IP interno.
Solução: valide nginx -t, recarregue o proxy, teste com openssl s_client e acesse pelo FQDN. Force redirecionamento 80→443 só depois do TLS estável.

Sintoma: renew --dry-run falha após meses de funcionamento

Causa: mudança de IP, plugin DNS com token expirado, ou serviço que passou a monopolizar a porta 80.
Solução: rode dry-run com verbosidade, renove o token da API DNS se for o caso, e ajuste o deploy-hook para reload em vez de restart agressivo da automação.

Sintoma: wildcard não cobre o domínio nu ou um host específico

Causa: certificado *.dominio não inclui o apex; SAN incompleto na emissão.
Solução: emita de novo com -d "*.seudominio.com.br" -d seudominio.com.br e atualize o proxy para o novo Certificate Name.

Perguntas frequentes sobre checklist Let's Encrypt para automação residencial no Debian 13

Por que usar Let's Encrypt em automação residencial no Linux?

Let's Encrypt emite certificados TLS gratuitos e confiáveis pelos navegadores, permitindo HTTPS em painéis como Home Assistant, Node-RED ou gateways locais expostos. Isso reduz risco de interceptação de credenciais e sensores na rede. Com Certbot, a renovação pode ser automatizada via systemd ou cron no Debian.

Quais portas preciso liberar para o Certbot no servidor Linux?

No desafio HTTP-01 o Certbot precisa da porta 80 acessível a partir da internet no host que responde pelo domínio. No DNS-01 não é necessário abrir 80, mas é preciso API do provedor DNS. Após emitir o certificado, mantenha 443 aberta para o HTTPS do painel de automação e restrinja o restante no firewall.

Como renovar o certificado Let's Encrypt sem derrubar a automação?

Use o timer do Certbot ou um job que rode certbot renew e, só se houver renovação, recarregue o proxy ou o serviço que serve o TLS. Teste com certbot renew --dry-run antes de confiar na produção. Evite reiniciar containers ou o Home Assistant a cada tentativa; prefira reload do Nginx, Caddy ou do reverse proxy.

Posso usar certificado wildcard para vários subdomínios de casa?

Sim, com desafio DNS-01 o Let's Encrypt emite wildcard (*.seudominio.com.br) útil para hass, nodered e outros hosts. É necessário um plugin ou script que atualize o registro TXT no DNS. Wildcard não cobre o apex sozinho; emita também o nome nu se for usá-lo no painel.

O que fazer se o Certbot falhar com connection refused ou timeout?

Confirme que o registro A/AAAA do domínio aponta para o IP público do servidor, que o firewall e o roteador encaminham a porta 80 e que nenhum outro processo ocupa 80 durante o desafio. Verifique logs do Certbot e do proxy. Em CGNAT ou IP dinâmico, prefira DNS-01 ou um túnel com TLS terminado corretamente.

Conclusão

  • Execute o checklist de DNS, portas e horário antes de qualquer emissão no Debian 13.
  • Prefira Certbot com proxy (Nginx) ou DNS-01 em redes residenciais com NAT/CGNAT, e valide com openssl e dry-run.
  • Automatize a renovação com timer e deploy-hook de reload para não interromper Home Assistant e demais painéis.

Leia também

Precisa de ajuda com Let's Encrypt e automação no Debian?

Um VPS estável facilita terminar TLS na borda, expor só o proxy e manter renovação previsível para a automação residencial. Avalie recursos e conectividade conforme o volume de painéis e sensores que você expõe.

Conhecer planos de VPS AviraHost


Esta resposta foi útil?