Como Corrigir o Erro “Este Site Não Pode Fornecer uma Conexão Segura”

O erro "Este site não pode fornecer uma ligação segura" significa que o seu browser não conseguiu concluir um handshake TLS com o servidor de destino. A tentativa de ligação foi encerrada antes de qualquer canal encriptado poder ser estabelecido, deixando o browser incapaz de verificar a identidade do servidor ou negociar um conjunto de cifras.

Este erro surge no Chrome, Firefox, Edge e Safari e é quase sempre acompanhado por um código de erro específico — mais comumente ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH ou SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Cada código aponta para uma camada de falha distinta: a configuração do certificado do servidor, a pilha TLS do cliente ou o caminho de rede entre eles. Identificar qual camada é responsável antes de alterar qualquer configuração poupará tempo significativo.

O Que Acontece Realmente Durante um Handshake TLS

Antes de mergulhar nas correções, é importante compreender o mecanismo de falha. Quando o seu browser se liga a um site HTTPS, realiza um handshake TLS em milissegundos:

1. O browser envia uma mensagem ClientHello anunciando as versões TLS e conjuntos de cifras suportados.
2. O servidor responde com um ServerHello, selecionando uma versão de protocolo e cifra, e apresentando a sua cadeia de certificados.
3. O browser valida o certificado em relação às Autoridades de Certificação (CAs) raiz confiáveis, verifica a data de expiração, confirma que o domínio corresponde ao Nome Alternativo do Sujeito (SAN) e confirma que o certificado não foi revogado (via OCSP ou CRL).
4. Ambos os lados derivam chaves de sessão e iniciam a comunicação encriptada.

Uma falha em qualquer um destes quatro passos produz a mensagem "não pode fornecer uma ligação segura". O código de erro no painel de detalhes do browser indica exatamente qual passo falhou.

Causas Raiz Mapeadas para Códigos de Erro

Se o código de erro atribui a responsabilidade ao administrador do servidor e não controla o servidor, as suas opções limitam-se a contactar o proprietário do site. As secções seguintes focam-se em erros que pode resolver do lado do cliente, seguidos de remediação do lado do servidor para administradores.

Correções do Lado do Cliente

1. Verifique o Certificado Antes de Alterar Qualquer Coisa

Clique no cadeado (ou no ícone de aviso) na barra de endereços e selecione Ligação segura > Certificado válido. Verifique:

• Período de validade: A data "Não Após" deve ser no futuro.
• Emitido para: O domínio no campo SAN do certificado deve corresponder exatamente ao URL, incluindo subdomínios.
• Emitido por: A cadeia de CA deve terminar numa CA raiz em que o seu sistema operativo confia.

Se o certificado estiver expirado ou não corresponder e não for proprietário do servidor, pare aqui e contacte o proprietário do site. Se gerir o servidor, avance para a secção do lado do servidor abaixo.

2. Sincronize a Data e Hora do Sistema

A validação do certificado é sensível ao tempo. Um relógio do sistema com apenas alguns minutos de desfasamento pode fazer com que o browser conclua que um certificado válido está expirado, ou que um certificado ainda não válido está a ser utilizado prematuramente.

Windows:

w32tm /resync /force

Em alternativa, clique com o botão direito no relógio do sistema, selecione Ajustar data/hora e ative Definir hora automaticamente com o serviço de Hora do Windows.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Abra Definições do Sistema > Geral > Data e Hora e ative Definir data e hora automaticamente.

Após a sincronização, reinicie o browser e teste novamente.

3. Limpe o Estado SSL e a Cache do Browser

Os browsers armazenam em cache os resultados de validação de certificados e as políticas HSTS (HTTP Strict Transport Security). Uma entrada de cache desatualizada pode bloquear o acesso mesmo após a resolução de um problema de certificado do lado do servidor.

Chrome — limpar dados de navegação:

Navegue para chrome://settings/clearBrowserData, selecione Todo o período, marque Cookies e outros dados do site e Imagens e ficheiros em cache, depois clique em Limpar dados.

Chrome — limpar entrada HSTS para um domínio específico:

Navegue para chrome://net-internals/#hsts, introduza o domínio em Eliminar políticas de segurança do domínio e clique em Eliminar. Isto é particularmente útil quando um domínio era anteriormente apenas HTTPS e agora está mal configurado.

Windows — limpar o estado SSL ao nível do sistema operativo:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Isto limpa a cache de certificados utilizada pelo Internet Explorer, Edge (legado) e algumas aplicações Windows.

Firefox: Navegue para about:preferences#privacy, desloque-se até Cookies e Dados do Site e clique em Limpar Dados.

4. Desative a Inspeção HTTPS do Antivírus

Produtos de segurança de fornecedores incluindo Avast, AVG, Kaspersky, ESET e Bitdefender realizam interceção SSL/TLS — atuam como um proxy local man-in-the-middle, reassinando certificados com a sua própria CA raiz. Quando a sua CA raiz não está corretamente instalada no repositório de confiança do browser, ou quando o módulo de interceção tem erros, todas as ligações HTTPS falham.

Para testar se esta é a causa:

1. Desative temporariamente a funcionalidade Web Shield, Verificação HTTPS ou Filtragem SSL nas definições do seu antivírus.
2. Recarregue a página com falha.
3. Se o erro desaparecer, o antivírus é o culpado.

A correção permanente é adicionar o domínio afetado à lista de exclusões do antivírus em vez de desativar a verificação HTTPS globalmente, o que reduziria a sua postura de segurança.

5. Atualize o Browser

O TLS moderno requer suporte do browser para TLS 1.2 no mínimo, e TLS 1.3 para segurança ideal. Browsers mais antigos do que aproximadamente Chrome 70, Firefox 63 ou Edge 79 podem não ter suporte para TLS 1.3 ou ter erros conhecidos de handshake.

Chrome:

Navegue para chrome://settings/help. O Chrome verifica atualizações automaticamente e instala-as ao reiniciar.

Firefox:

Navegue para about:support, depois Verificar Atualizações no menu Ajuda.

Manter o browser atualizado também garante que o repositório de CA raiz integrado no browser está atualizado, o que é importante para certificados emitidos por CAs mais recentes.

6. Audite as Definições de Protocolo TLS no Browser

Chrome e Edge (baseados em Chromium):

Estes browsers não expõem controlos de versão TLS na interface desde o Chrome 84. TLS 1.0 e 1.1 estão permanentemente desativados. Se um site requer TLS 1.0 ou 1.1, o site deve ser atualizado — não existe solução alternativa do lado do cliente, nem deveria existir.

Para verificar flags TLS experimentais, navegue para chrome://flags e procure por TLS. Na maioria das versões de produção, não aparecerão flags acionáveis.

Firefox:

Navegue para about:config e procure por security.tls.version.min. O valor deve ser 3 (correspondente a TLS 1.2). Definir para 1 ou 2 para acomodar um servidor com problemas é um risco de segurança e deve ser feito apenas em ambientes de teste isolados.

Internet Explorer / Edge Legado:

Navegue para Opções da Internet > Avançadas > Segurança e certifique-se de que Usar TLS 1.2 e Usar TLS 1.3 estão marcados. Desmarque Usar SSL 3.0, Usar TLS 1.0 e Usar TLS 1.1.

7. Desative ou Audite as Extensões do Browser

Extensões com acesso à rede — particularmente VPNs, bloqueadores de anúncios, ferramentas de privacidade e comutadores de proxy — podem intercecionar ou modificar ligações TLS. Para isolar um conflito de extensão:

Navegue para chrome://extensions/ e desative todas as extensões. Recarregue a página com falha. Se o erro for resolvido, reative as extensões uma de cada vez, recarregando após cada uma, até identificar a extensão problemática.

8. Altere o Resolvedor DNS

O DNS não afeta diretamente o TLS, mas um resolvedor DNS que devolve endereços IP incorretos (devido a envenenamento, filtragem ou interferência do ISP) pode direcionar o seu browser para um servidor que apresenta um certificado para o domínio errado, causando um erro ERR_CERT_COMMON_NAME_INVALID.

Mudar para um resolvedor público elimina a manipulação DNS ao nível do ISP:

Windows — alterar DNS via PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Substitua "Ethernet" pelo nome real da sua interface (use Get-NetAdapter para listar as interfaces).

Linux:

sudo nano /etc/resolv.conf

Adicione:

nameserver 1.1.1.1
nameserver 8.8.8.8

Resolvedores públicos recomendados:

9. Reinicie a Pilha de Rede (Windows)

Um catálogo Winsock corrompido ou uma pilha TCP/IP pode causar falhas TLS intermitentes que parecem não estar relacionadas com certificados. Execute o seguinte como Administrador:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Reinicie a máquina após executar todos os cinco comandos. Não ignore o reinício — netsh winsock reset em particular requer um reinício para entrar em vigor.

Correções do Lado do Servidor para Administradores

Se gere o servidor web que apresenta o certificado, seguem-se as causas mais comuns do lado do servidor e a sua remediação.

Certificado SSL Expirado ou Mal Configurado

Um certificado expirado é a causa mais comum deste erro ao nível do servidor. Se estiver a executar um site num ambiente de Alojamento VPS, a renovação do certificado deve ser automatizada.

Verifique a expiração do certificado a partir da linha de comandos:

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

Automatize a renovação com Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Adicione um cron job ou temporizador systemd para executar certbot renew duas vezes por dia — os certificados Let's Encrypt expiram a cada 90 dias, e o Certbot apenas renova quando restam menos de 30 dias.

0 0,12 * * * root certbot renew --quiet

Se precisar de um certificado validado comercialmente com validação estendida ou cobertura wildcard, os Certificados SSL de uma CA confiável fornecem a cadeia de confiança necessária para todos os principais browsers.

Cadeia de Certificados Incompleta

Uma configuração incorreta muito comum: o servidor apresenta apenas o certificado de entidade final sem os certificados CA intermediários. O browser não consegue construir um caminho de confiança até uma CA raiz que reconhece, resultando em ERR_CERT_AUTHORITY_INVALID.

Diagnostique com SSL Labs:

Execute o seu domínio através do SSL Labs Server Test (ferramenta externa). Um problema de cadeia será sinalizado imediatamente.

Correção no Nginx:

A diretiva ssl_certificate deve apontar para um ficheiro contendo a cadeia completa — o seu certificado seguido de todos os certificados intermediários:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Correção no Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Versões TLS Obsoletas e Conjuntos de Cifras Fracos

Os browsers removeram o suporte para TLS 1.0 e TLS 1.1. Se o seu servidor apenas oferece estas versões de protocolo, os browsers modernos recusarão a ligação completamente.

Configuração TLS recomendada para Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Configuração TLS recomendada para Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Após modificar a configuração do servidor, teste com:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Incompatibilidade de Domínio do Certificado

Se o seu certificado cobre www.example.com mas os utilizadores acedem a example.com (ou vice-versa), o browser reportará uma incompatibilidade de domínio. A correção correta é emitir um certificado com ambos os nomes no campo SAN, ou usar um certificado wildcard (*.example.com).

Ao configurar um novo domínio num ambiente de Servidores Dedicados, verifique sempre se o campo SAN cobre todas as variantes de nome de host às quais o servidor responderá antes de entrar em produção.

Bloqueio de Conteúdo Misto

Uma página carregada via HTTPS que referencia recursos HTTP (imagens, scripts, folhas de estilo) desencadeia avisos de conteúdo misto. Embora isto não produza diretamente o erro "não pode fornecer uma ligação segura", pode causar falhas parciais de página que são erroneamente diagnosticadas como erros TLS.

Audite o conteúdo misto com:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Comparação de Causas do Lado do Cliente vs. Lado do Servidor

Considerações sobre o Ambiente de Alojamento

O ambiente de alojamento que utiliza influencia diretamente a facilidade com que pode resolver problemas TLS do lado do servidor.

No Alojamento Web Partilhado, a gestão de certificados é normalmente feita através do painel de controlo. A maioria das plataformas modernas de alojamento partilhado inclui integração gratuita com Let's Encrypt, mas tem controlo limitado sobre as definições de protocolo TLS ao nível do servidor.

Num VPS com cPanel, obtém acesso ao AutoSSL para provisionamento automatizado de certificados e pode configurar diretamente as definições TLS do Apache ou Nginx. Este é o ambiente recomendado para sites onde a precisão da configuração TLS é importante.

Em Servidores Dedicados bare-metal, tem controlo total sobre toda a pilha TLS — versão OpenSSL, seleção de conjuntos de cifras, OCSP stapling, pré-carregamento HSTS e fixação de certificados — mas também é totalmente responsável por manter a configuração atualizada.

Lista de Verificação Prática de Decisão

Use esta lista de verificação para triagem sistemática do erro em vez de aplicar correções aleatoriamente:

• O erro aparece em todos os sites HTTPS ou apenas num?
• Todos os sites: foque-se no relógio do sistema, verificação HTTPS do antivírus, atualização do browser, repositório de CA raiz do sistema operativo.
• Um site: o problema é quase certamente do lado do servidor.

• O que diz o código de erro específico?
• ERR_CERT_DATE_INVALID: verifique primeiro o relógio do sistema, depois a expiração do certificado.
• ERR_CERT_AUTHORITY_INVALID: verifique a completude da cadeia de certificados.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: o servidor está a executar TLS obsoleto ou cifras não suportadas.
• ERR_CERT_COMMON_NAME_INVALID: o SAN do certificado não corresponde ao domínio.

• O erro desaparece numa rede diferente?
• Sim: firewall, proxy ou inspeção TLS ao nível do ISP é a causa.

• O erro desaparece com o antivírus desativado?
• Sim: configure uma exclusão para o domínio nas definições de verificação HTTPS do antivírus.

• É o administrador do servidor?
• Execute diagnósticos openssl s_client e o teste SSL Labs antes de tocar em qualquer ficheiro de configuração.
• Automatize a renovação do certificado imediatamente após resolver o problema imediato.

FAQ

Por que razão "Este site não pode fornecer uma ligação segura" aparece apenas num website?

Quando o erro está isolado a um único domínio, a causa raiz é quase sempre do lado do servidor: um certificado expirado, uma cadeia de certificados incompleta, uma incompatibilidade de nome de domínio no campo SAN do certificado, ou o servidor estar configurado para usar apenas versões TLS obsoletas (1.0 ou 1.1) que os browsers modernos já não aceitam.

Uma VPN pode causar este erro?

Sim. Alguns clientes VPN encaminham consultas DNS através dos seus próprios resolvedores ou realizam inspeção de tráfego que interfere com handshakes TLS. Se o erro aparecer apenas enquanto a VPN está ativa, desative a funcionalidade de "split tunneling" ou "inspeção SSL" da VPN, ou adicione o domínio afetado como exclusão.

Limpar a cache resolve sempre erros SSL?

Não. Limpar a cache resolve erros causados por políticas HSTS desatualizadas ou respostas de certificados inválidos em cache. Não tem efeito em problemas de certificado do lado do servidor, problemas de relógio do sistema ou interceção do antivírus. Use a limpeza da cache como primeiro passo, não como solução universal.

Como verifico se o certificado SSL do meu servidor está corretamente configurado sem um browser?

Use OpenSSL a partir de qualquer máquina com acesso à rede:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

O resultado mostra a cadeia de certificados completa, a versão TLS negociada, o conjunto de cifras selecionado e quaisquer erros de verificação. Este é o método de diagnóstico mais fiável para problemas TLS do lado do servidor.

Qual é a diferença entre ERR_SSL_PROTOCOL_ERROR e ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR indica que o servidor enviou uma resposta que não está em conformidade com nenhum formato de registo TLS reconhecido — frequentemente causado por um servidor a enviar uma resposta HTTP na porta 443, um balanceador de carga mal configurado ou uma firewall a encerrar a ligação a meio do handshake. ERR_SSL_VERSION_OR_CIPHER_MISMATCH significa que o handshake começou corretamente mas o cliente e o servidor não conseguiram acordar numa versão TLS ou conjunto de cifras mutuamente suportados, tipicamente porque o servidor suporta apenas protocolos obsoletos.