ByteSeguroPode Confiar.

SSL/HTTPS não funciona no site: como separar certificado, domínio, DNS e configuração

Aviso de certificado, HTTPS que não abre, redirecionamento em loop e mixed content são problemas diferentes. Antes de reinstalar certificado, trocar DNS ou desligar HTTPS, descubra qual hostname falha e em qual camada a conexão deixa de funcionar.

Autor
ByteSeguro Editorial
Publicado
Notebook exibe um cadeado relacionado à segurança da conexão.

Comece com uma pergunta:

Que tipo de falha HTTPS o navegador está mostrando?

A sequência mais segura é:

  1. identifique o sintoma exato;
  2. confirme qual hostname falha;
  3. verifique se o certificado corresponde ao hostname e ainda está válido;
  4. se HTTP funciona e HTTPS não, trate o endpoint HTTPS como uma camada própria;
  5. confirme se o DNS leva ao ambiente esperado;
  6. compare domínio raiz e www;
  7. reveja mudanças recentes de DNS, hospedagem, proxy ou certificado;
  8. se o HTTPS conecta mas entra em loop, investigue redirecionamento;
  9. se a página carrega, mas há aviso de conteúdo inseguro, investigue mixed content;
  10. verifique renovação apenas depois de confirmar que o problema é realmente de certificado;
  11. não ignore avisos do navegador nem desligue HTTPS;
  12. leve hostname, horário, erro e mudança recente à hospedagem, autoridade certificadora ou desenvolvedor.

Princípio central: o certificado é apenas uma parte do caminho. O hostname precisa resolver para o ambiente certo, esse ambiente precisa oferecer HTTPS e a aplicação precisa responder sem criar redirecionamentos ou conteúdo inseguro.

SintomaCamada que ganha pesoPróxima verificação
Certificado expiradoValidade/renovaçãoConfirmar certificado apresentado e status de renovação
Nome do certificado não correspondeIdentidade do hostnameComparar hostname solicitado e nomes cobertos
Cadeia não confiávelCertificado/servidorHospedagem ou autoridade certificadora
HTTP abre, HTTPS nãoEndpoint HTTPSHospedagem, proxy ou terminação TLS
Só www falhaHostname/DNS/certificadoTestar www separadamente
Só domínio raiz falhaHostname/DNS/certificadoTestar domínio raiz separadamente
HTTPS abre e redireciona sem pararAplicação/proxy/redirecionamentoRever regras e URLs
Página HTTPS abre com conteúdo inseguroMixed contentIdentificar recursos ainda carregados por HTTP
Problema após migraçãoDNS/ambiente/certificadoConfirmar destino atual e certificado apresentado
Funciona em outros dispositivosCliente/rede local ganha pesoRelógio, navegador e confiança local

1. “SSL não funciona” pode significar problemas diferentes

A expressão “SSL não funciona” costuma misturar situações distintas:

  • certificado expirado;
  • certificado para outro hostname;
  • cadeia de confiança inválida;
  • HTTPS não aceita conexão;
  • HTTP funciona, mas HTTPS não;
  • um hostname funciona e outro não;
  • redirecionamento entra em loop;
  • página abre, mas o navegador sinaliza mixed content;
  • certificado parece correto, mas o domínio chega ao ambiente errado.

Esses sintomas não devem receber a mesma correção.

A cadeia conceitual é:

hostname → DNS → endpoint HTTPS → certificado → aplicação

Se o DNS leva ao ambiente errado, você pode ver um certificado perfeitamente válido — para outro site.

Se o endpoint HTTPS nem responde, o navegador pode não chegar ao ponto de avaliar o certificado.

2. Primeiro veja qual hostname está falhando

Um certificado é emitido para nomes específicos.

Por isso, teste separadamente os hostnames usados pelo site.

Exemplos:

  • example.com
  • www.example.com

Eles são relacionados, mas não devem ser tratados como se a configuração de um garantisse automaticamente a do outro.

Um site pode ter:

  • DNS correto no domínio raiz e incorreto no www;
  • certificado cobrindo um hostname, mas não o outro;
  • redirecionamento configurado apenas em um deles;
  • ambientes diferentes respondendo por cada nome.

Anote exatamente qual URL gera o erro.

Não use apenas “meu domínio” como descrição do problema.

3. Certificado precisa corresponder ao hostname e estar válido

Para um navegador confiar em uma conexão HTTPS, o certificado apresentado precisa ser apropriado ao hostname solicitado e estar dentro das condições de validade e confiança esperadas.

Erros comuns incluem:

  • certificado expirado;
  • certificado emitido para outro nome;
  • emissor/cadeia não reconhecido;
  • certificado revogado ou considerado inseguro.

O Firefox, por exemplo, diferencia erros como certificado expirado, emissor desconhecido e domínio incorreto.

Não contorne o aviso.

A recomendação segura é corrigir a situação do certificado ou procurar o responsável pelo site.

Também não altere o relógio do computador “para fazer funcionar”, a menos que haja evidência de que a hora do dispositivo está realmente errada.

4. HTTP funcionando não prova que HTTPS está configurado

http:// e https:// usam esquemas diferentes.

HTTPS transporta HTTP por um canal TLS seguro.

Portanto, é possível que:

  • HTTP chegue ao site;
  • mas HTTPS não esteja disponível;
  • ou o endpoint HTTPS apresente certificado/configuração incorreta.

Se HTTP abre e HTTPS não, isso mostra que domínio e DNS provavelmente conseguem chegar a algum serviço, mas não prova que o endpoint HTTPS esteja correto.

Ganham peso:

  • terminação HTTPS;
  • certificado;
  • proxy/CDN;
  • configuração da hospedagem;
  • serviço que responde apenas por HTTP.

Não avance para portas, firewall, Nginx ou Apache neste artigo.

Se a conexão HTTPS nem chega a ser estabelecida, o suporte da hospedagem deve verificar o endpoint.

5. DNS pode levar você ao servidor certo ou ao ambiente errado

DNS participa diretamente desse diagnóstico porque transforma o hostname no destino que o navegador tentará acessar.

Se o DNS aponta para:

  • servidor antigo;
  • ambiente de staging;
  • proxy diferente;
  • CDN desatualizada;
  • hospedagem anterior;

o navegador pode receber:

  • certificado errado;
  • certificado padrão;
  • nenhum serviço HTTPS;
  • site antigo.

Ou seja:

DNS pode estar funcionando tecnicamente e ainda levar ao endpoint HTTPS errado.

Não transforme isso em tutorial de A, AAAA ou CNAME.

O que você precisa confirmar é apenas:

o hostname que falha está chegando ao ambiente que deveria responder por ele?

Se o problema parece estar antes do HTTPS, veja [Domínio não abre o site: como descobrir se o problema está no DNS, na hospedagem ou na configuração](/br/35/software-it/hosting-wordpress-domains/dominio-nao-abre-o-site).

6. Mudanças de hospedagem e DNS podem deixar certificados desencontrados

Migrações criam um cenário clássico.

Depois de trocar hospedagem, DNS, CDN ou proxy:

  • alguns acessos podem continuar chegando ao ambiente antigo por causa de cache;
  • o novo ambiente pode não estar pronto para aquele hostname;
  • o certificado pode estar instalado apenas em um dos ambientes;
  • o domínio raiz e www podem ter sido migrados de forma diferente.

Não use um prazo fixo como “24–48 horas”.

O comportamento observado depende do DNS publicado anteriormente, caches e momento de cada consulta.

Faça duas perguntas:

  1. qual ambiente o DNS atual deveria alcançar?
  2. qual certificado esse ambiente está apresentando para o hostname?

Cronologia ajuda, mas não prova que a migração é a causa.

7. Renovação de certificado é uma pista, não a explicação automática

Certificados possuem período de validade.

Se o navegador informa expiração, confirme:

  • qual certificado está sendo apresentado;
  • qual hostname ele cobre;
  • se esse é o ambiente esperado;
  • se a hospedagem ou autoridade certificadora registra tentativa de renovação;
  • se houve mudança recente de DNS ou infraestrutura.

Renovação automática não deve ser tratada como algo infalível.

Sistemas automatizados ainda dependem de condições operacionais e de validação.

Também não presuma que “reemitir o certificado” é sempre o primeiro passo.

Se o DNS ainda aponta ao servidor errado, uma nova emissão pode não corrigir o endpoint que os visitantes realmente acessam.

Reemissão/renovação pertence à camada de certificado depois de confirmar hostname e ambiente.

8. Redirect loop é diferente de certificado inválido

Um loop de redirecionamento acontece quando respostas de redirecionamento levam o navegador de uma URL para outra repetidamente sem chegar ao conteúdo final.

Isso ocorre depois que existe comunicação HTTP/HTTPS suficiente para o servidor responder com redirecionamentos.

Portanto, se:

  • o certificado é aceito;
  • a conexão HTTPS é estabelecida;
  • mas o navegador informa redirecionamentos excessivos;

o foco passa para:

  • aplicação;
  • WordPress;
  • proxy/CDN;
  • configuração da hospedagem;
  • regras de redirecionamento.

Não reinstale certificado por reflexo.

Também não edite .htaccess, Nginx ou cabeçalhos de proxy neste artigo.

Registre as URLs entre as quais o navegador fica alternando e encaminhe essa evidência.

9. Mixed content é diferente de falha do HTTPS principal

Mixed content ocorre quando uma página principal carregada por HTTPS tenta buscar recursos por HTTP.

Exemplos:

  • imagens;
  • scripts;
  • folhas de estilo;
  • fontes;
  • embeds.

Nesse cenário, o certificado da página principal pode estar perfeitamente válido.

O problema está nos subrecursos inseguros.

Navegadores podem atualizar alguns tipos de conteúdo automaticamente ou bloquear outros.

O resultado pode aparecer como:

  • aviso de segurança;
  • layout quebrado;
  • script que não funciona;
  • imagem que não carrega.

Não instale um “mixed content fixer” automaticamente.

Primeiro descubra qual recurso ainda usa HTTP e de onde ele vem.

Este artigo não ensina busca/substituição em massa no banco.

10. CDN, proxy e WordPress entram apenas quando há evidência

Se o site usa CDN, proxy reverso, balanceador ou outra camada intermediária, essa camada pode terminar HTTPS separadamente do servidor de origem.

Isso significa que:

  • o certificado visto pelo visitante pode estar no proxy;
  • o servidor de origem pode usar outra conexão;
  • redirecionamentos podem depender de como o proxy informa o esquema original;
  • WordPress pode gerar URLs incorretas se não reconhecer corretamente HTTPS.

Mas não assuma que todo site usa proxy/CDN.

No WordPress, os conceitos de Site Address e WordPress Address também participam de como URLs são geradas.

Configuração incorreta pode contribuir para:

  • HTTP sendo gerado onde deveria haver HTTPS;
  • redirecionamentos inesperados;
  • mixed content.

Se o wp-admin funciona, use as configurações suportadas do próprio WordPress apenas para verificar coerência.

Se o painel está inacessível ou existe proxy/infraestrutura complexa, encaminhe ao desenvolvedor ou hospedagem em vez de editar banco ou wp-config.php.

11. O que não fazer diante de um aviso de certificado

Um aviso TLS existe porque o navegador não conseguiu estabelecer confiança normal naquela conexão.

Não faça como primeira tentativa:

  • clicar em “prosseguir mesmo assim”;
  • adicionar exceção de certificado sem entender a causa;
  • desabilitar validação;
  • desligar HTTPS;
  • manter o site permanentemente em HTTP;
  • instalar certificado raiz aleatório;
  • desabilitar segurança do navegador;
  • reemitir certificado repetidamente;
  • trocar DNS por tentativa;
  • colar chave privada em fórum;
  • enviar chave privada para ferramenta online;
  • usar “certificate repair” desconhecido;
  • editar servidor por receita copiada.

A documentação da Mozilla recomenda corrigir a situação do certificado em vez de desabilitar as verificações.

A chave privada merece atenção especial.

Ela deve permanecer secreta.

Se uma chave privada foi exposta, a resposta adequada é tratá-la como comprometida e seguir o procedimento de revogação/substituição do responsável pelo certificado.

12. Quando procurar hospedagem, autoridade certificadora ou desenvolvedor

O sintoma indica para quem encaminhar.

Procure a hospedagem ou operador do endpoint HTTPS quando:

  • HTTP funciona, mas HTTPS não aceita conexão;
  • certificado errado aparece no ambiente hospedado;
  • existe problema de cadeia;
  • HTTPS parou após migração;
  • o endpoint não reconhece o hostname;
  • logs/configuração do servidor são necessários.

Procure a autoridade certificadora ou suporte responsável pela emissão quando:

  • o certificado está realmente expirado;
  • a renovação automática falhou;
  • emissão/validação do hostname está pendente;
  • houve comprometimento de chave.

Procure o desenvolvedor/WordPress quando:

  • certificado é válido e HTTPS conecta;
  • existe redirect loop;
  • mixed content vem da aplicação;
  • URLs do WordPress estão incoerentes;
  • proxy/CDN e aplicação precisam ser reconciliados.

Leve:

  • hostname exato;
  • URL completa;
  • horário aproximado;
  • mensagem do navegador;
  • se HTTP funciona;
  • se raiz e www se comportam diferente;
  • destino DNS esperado;
  • mudança recente;
  • certificado apresentado;
  • se existe CDN/proxy;
  • se a falha ocorre em outro dispositivo/rede.

Se o site inteiro pode estar falhando em outra camada, veja [Site WordPress está fora do ar: como separar problema de hospedagem, domínio, DNS, SSL e WordPress](/br/35/software-it/hosting-wordpress-domains/site-wordpress-fora-do-ar).

Conclusão

“SSL não funciona” pode esconder problemas completamente diferentes.

A ordem segura é:

sintoma → hostname → certificado → HTTP vs HTTPS → destino DNS → raiz vs www → mudança recente → renovação → redirecionamento → mixed content → suporte.

Não enfraqueça a segurança para fazer o site “abrir”.

Corrigir a camada certa é mais seguro — e mais rápido — do que ignorar avisos, desligar HTTPS ou reinstalar certificados sem saber qual endpoint está falhando.

Fontes públicas

  • Mozilla Support — What do the security warning codes mean?
  • MDN — URI schemes e URI authority.
  • MDN — Redirections in HTTP.
  • MDN — Mixed content.
  • MDN — insecure certificate error code.
  • Let’s Encrypt / ISRG — política de validação de FQDNs e documentação de certificados.
  • Let’s Encrypt — Certificate Lifetime Rationale and Plans e Revoking Certificates.
  • WordPress Developer Resources — funções e detecção de URLs HTTPS.
  • ICANN — The Domain Name System e name resolution.