Porque é que um certificado autoalojado é renovado localmente, mas falha a partir da Internet?
Um certificado pode renovar localmente e, ainda assim, falhar publicamente quando a autoridade ACME não consegue aceder ao desafio ou verificá-lo através do caminho exposto à Internet.
Num NAS autoalojado ou servidor doméstico, um teste local pode confirmar que o Certbot, o acme.sh ou o proxy inverso consegue criar ficheiros de desafio e aceder à sua própria configuração. A emissão pública acrescenta requisitos diferentes: o DNS autoritativo tem de apontar para o endereço correto, o caminho IPv4 ou IPv6 selecionado tem de estar acessível, o router e a firewall têm de encaminhar o pedido de validação e o proxy inverso tem de servir o token de desafio exato antes que os redirecionamentos ou as rotas da aplicação interfiram.
Separe o Sucesso do Cliente Local da Validação Pública do Domínio
Leia o registo da renovação e identifique o que realmente foi bem-sucedido. Uma verificação da configuração local, um teste de análise do certificado, uma escrita no webroot ou um pedido de teste não comprovam que uma autoridade de certificação externa conseguiu chegar ao servidor doméstico.
Um caso comum do Nginx Proxy Manager identifica a acessibilidade da porta 80 pública como o primeiro requisito a verificar quando um desafio HTTP falha apesar de a interface local do proxy funcionar.
Registe o tipo de desafio, o nome do anfitrião, o URL de validação, o endereço resolvido e o erro exato da AC. Prossiga apenas a partir da primeira falha externa — pesquisa DNS, ligação TCP, estado HTTP, incompatibilidade do token ou validação secundária — em vez de forçar repetidamente a renovação sem novas evidências.
Compare os Registos A e AAAA Autoritativos com o Caminho Real para o Servidor
Consulte cada nome de anfitrião do certificado através do DNS autoritativo e registe as respetivas respostas A e AAAA. Compare-as com o IPv4 público atual do router, o endereço IPv6 acessível do servidor e o proxy que efetivamente serve o desafio.
Um caso de renovação no Virtualmin só foi bem-sucedido depois de remover um registo AAAA publicado que encaminhava a validação para um caminho IPv6 avariado, demonstrando como um caminho de validação AAAA avariado pode sobrepor-se a uma configuração IPv4 que, de outro modo, estaria saudável.
Se uma família de endereços não estiver totalmente acessível, remova temporariamente esse registo ou repare a respetiva firewall, rota, serviço de escuta e caminho do proxy. Verifique também se todos os servidores de nomes autoritativos devolvem os mesmos registos atuais antes de tentar novamente a emissão.
Teste o URL Exato do Desafio HTTP a Partir do Exterior da Rede Doméstica
Para HTTP-01, coloque um ficheiro de teste inofensivo no caminho /.well-known/acme-challenge/ configurado e solicite-o através de dados móveis ou de outra rede externa, utilizando o nome de anfitrião do certificado por HTTP.
Um relato sobre autoalojamento do Home Assistant mostra como um desafio HTTP bloqueado pelo ISP impede a validação HTTP mesmo quando o serviço funciona localmente.
O pedido externo tem de chegar ao token correto sem autenticação, uma página cativa, um início de sessão do router, um erro 404 da aplicação ou um redirecionamento para um destino inacessível. Se a porta TCP 80 nunca abrir, verifique o ISP, o CGNAT, o encaminhamento do router, a firewall do anfitrião e o serviço de escuta do proxy antes de alterar o cliente ACME.
Verifique se o Proxy Inverso e o Webroot Servem o Mesmo Token
Compare o caminho do token escrito pelo cliente ACME com o sistema de ficheiros ou o respondedor temporário utilizado pelo anfitrião virtual público. Os contentores, os pontos de montagem vinculados e as redes separadas do proxy podem fazer com que o cliente escreva num diretório enquanto o NGINX ou o Caddy serve outro.
Inspecione o registo de acesso do proxy durante um pedido de desafio externo. Um pedido que chega mas devolve 404 aponta para uma incompatibilidade de rota ou webroot; 401 ou 403 apontam para autenticação ou filtragem; 502 aponta para uma dependência desnecessária de um serviço a montante no caminho do desafio.
Dê prioridade à localização do desafio em relação ao encaminhamento normal da aplicação e preserve o nome de anfitrião. Mantenha os redirecionamentos simples e verifique-os externamente; não encaminhe o token através de uma aplicação de backend que possa estar offline durante a renovação.
Verifique o CGNAT, as Firewalls e a Acessibilidade a Partir de Vários Locais
Compare o endereço WAN do router com o endereço IPv4 público e confirme que a porta de validação está acessível a partir de mais do que uma rede externa. Um teste local de NAT loopback pode ser bem-sucedido mesmo quando o tráfego não solicitado da Internet nunca chega ao router.
As autoridades de certificação validam cada vez mais a partir de vários locais de rede para reduzir ataques de encaminhamento. A investigação sobre vários pontos de observação de validação explica por que motivo um caminho acessível a partir de um país, ISP ou serviço de teste pode ainda falhar numa validação mais abrangente.
Remova o bloqueio geográfico, os filtros por país, as regras de bloqueio temporárias e os limites de frequência do caminho restrito do desafio durante a validação. Se a ligação doméstica estiver atrás de CGNAT ou o ISP bloquear a porta necessária, utilize DNS-01 ou um método de validação através de ligações de saída, em vez de enfraquecer regras de firewall não relacionadas.
Escolha o Tipo de Desafio Adequado aos Limites da Rede
Mantenha o HTTP-01 quando o DNS público estiver correto e a porta 80 conseguir chegar de forma fiável ao respondedor do desafio. Utilize o DNS-01 quando a acessibilidade de entrada não estiver disponível, forem necessários certificados wildcard ou o serviço tiver de permanecer privado.
O artigo da ZimaSpace sobre como o CGNAT bloqueia a validação de entrada ajuda a identificar quando é mais adequado alterar o método ACME do que reparar o proxy local.
A correção só está concluída quando uma renovação forçada for bem-sucedida através da AC de produção, o novo certificado for implementado no proxy ativo, os clientes externos receberem o novo número de série e a nova data de expiração, e um teste de renovação automática funcionar sem alterações manuais às portas ou ao DNS.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
