Faça inventário de hostnames, dependências e responsáveis
Liste todo hostname que visitantes ou integrações usam: apex, www, subdomínios, APIs, hosts de ativos, portais e nomes regionais. Para cada um, registre onde o TLS termina, quem pode alterá‑lo, a cobertura e data de expiração do certificado, o método de renovação e dependências que geram URLs. Um certificado precisa cobrir o hostname solicitado na lista Subject Alternative Name. Inclua o CMS, CDN, tag manager, armazenamento de objetos, provedor de pagamento, templates de e‑mail e embeds de terceiros; eles comumente introduzem URLs HTTP após a primeira liberação de HTTPS.
Selecione um hostname canônico (www ou apex) e redirecione a alternativa diretamente para ele via HTTPS.
Implemente o certificado e as versões TLS atuais
Configure o servidor web, o proxy reverso, a CDN ou o balanceador de carga que atende à requisição pública. Instale o certificado e a cadeia necessária, associe-os aos nomes pretendidos e verifique-os de fora da rede de hospedagem. O navegador confere a cadeia, o hostname e as datas; um aviso do navegador deve impedir o release. Use TLS 1.3 por padrão e mantenha TLS 1.2 somente quando a compatibilidade exigir. Desative SSL, TLS 1.0 e TLS 1.1. Siga orientações atualizadas da plataforma em vez de copiar listas legadas de conjuntos de cifras e mantenha o servidor e a biblioteca TLS atualizados com patches.
Limite o acesso às chaves privadas e registre todo sistema que compartilha uma chave para que a substituição alcance todos eles.
Redirecione HTTP uma vez e torne HTTPS canônico
Retorne um redirect permanente no servidor, normalmente 301 ou 308, de cada URL HTTP para sua URL equivalente em HTTPS. Evite cadeias: elas adicionam atraso e mais pontos de falha. Publique URLs canônicas HTTPS em links internos, tags canonical, sitemaps, dados estruturados, tags sociais, e‑mails e links absolutos gerados por aplicações. Teste a página inicial, uma página profunda, uma URL com query, rotas de erro e variantes de hostname. Quando o TLS termina em um proxy, configure o tratamento confiável do forwarded‑protocol para que a aplicação não entre em loop entre HTTP e HTTPS.
Ele pode permanecer disponível apenas para redirecionar ou completar um desafio de certificado, não para servir um site público separado.
Encontre e corrija o conteúdo misto na origem
Conteúdo misto é uma página HTTPS que solicita um recurso por HTTP ou outro protocolo inseguro. Os navegadores podem atualizar automaticamente alguns recursos de mídia, mas bloqueiam muitas requisições de alto risco, incluindo scripts, folhas de estilo, frames, chamadas fetch e fontes. Substitua cada referência por uma URL HTTPS testada, uma URL relativa para conteúdo próprio ou uma alternativa aprovada. Rastreie modelos de página representativos e inspecione as ferramentas de desenvolvedor enquanto conclui jornadas-chave. Verifique CSS, JavaScript, blocos do CMS, manifestos de ativos, entradas do gerenciador de tags, downloads e incorporações de fornecedores. Uma página segura não deve oferecer um download via HTTP.
A atualização automática do navegador pode ainda deixar uma dependência de terceiro indisponível ou sem suporte; corrija a URL armazenada.
Automatize a renovação e treine recuperação de certificados
Trate a renovação como uma implantação automatizada, não como um lembrete de calendário. Ela deve renovar, implantar em todas as camadas de serviço e recarregar o serviço com segurança. Teste a mesma rota de validação antes da expiração em produção. A Let’s Encrypt, por exemplo, recomenda renovar certificados de 90 dias a cada 60 dias; siga o ciclo de vida do seu emissor e da sua plataforma. Mantenha em um inventário os nomes dos certificados, a conta do emissor, o método de desafio, a automação, a localização da chave, os destinos e os contatos de emergência. Verifique as datas no endpoint público após a implantação.
Em caso de falha na renovação, verifique DNS, roteamento do desafio, permissões, acesso ao emissor, limites de taxa e a implantação da CDN até a origem.
Use HSTS apenas depois que o ambiente HTTPS estiver pronto
HTTP Strict Transport Security, ou HSTS, é um cabeçalho de resposta HTTPS que instrui os navegadores a usar HTTPS em visitas posteriores a um host. Assim, os navegadores não oferecem ao visitante uma opção de ignorar erros de certificado. Envie-o apenas por HTTPS e mantenha o redirecionamento HTTP, pois o HSTS só é aprendido após uma resposta segura, exceto quando houver uma entrada aplicável na lista de pré-carregamento. Comece com um max-age limitado e aumente-o depois de comprovar as renovações e as rotas necessárias. Não adicione includeSubDomains até que cada subdomínio presente e futuro possa servir HTTPS válido. O pré-carregamento não faz parte da especificação HSTS e exige uma análise de compromisso separada.
max-age=0 funciona apenas depois que um navegador atingir uma resposta HTTPS válida; ele não repara um host seguro inalcançável.
Implante, teste e reverta sem enfraquecer o transporte
Capture a configuração conhecida como boa do certificado, da borda e dos redirecionamentos antes da mudança. Defina quem aprova um rollback, faça a implantação em etapas quando possível e altere uma classe de controle por vez. Verifique imediatamente endpoints públicos a partir de mais de uma rede, siga os redirecionamentos, inspecione o certificado e conclua ações importantes do visitante. Teste navegadores e grupos de clientes relevantes para seu público. Para fluxos de pagamento ou regulamentados, consulte o provedor de pagamento e um profissional de segurança qualificado para revisar os requisitos aplicáveis. Se uma mudança interromper o HTTPS, restaure uma configuração segura validada; não disponibilize páginas voltadas aos clientes em HTTP como solução temporária.
Capture o hostname, hora, cliente, erro, mudança e resultado para que a próxima renovação ou migração seja mais fácil de diagnosticar.