"Sua conexão não é particular": Qual das Cinco é, e a Máquina de Quem Está Errada

Uma única tela vermelha de aviso cobre pelo menos cinco falhas sem relação entre si. Essa é toda a dificuldade da mensagem “Sua conexão não é particular”: a página que o usuário vê é idêntica, seja porque seu certificado expirou ontem à noite, porque o notebook dele acha que ainda é 2019, ou porque o empregador dele está lendo o tráfego.

A tela esconde a única coisa que diferencia esses casos, e ela fica atrás do link Avançadas: um código que começa com NET::ERR_CERT_. Tudo o que é útil está nesse código, e quase nenhum relato de bug o inclui.

O que o navegador está realmente fazendo

Antes de qualquer requisição sair, o navegador verifica o certificado apresentado pelo servidor. Três dessas verificações falham com frequência suficiente para ter códigos de erro próprios, e a própria lista de erros de rede do Chromium descreve cada uma em uma linha.

ERR_CERT_COMMON_NAME_INVALID é, nas palavras do Chromium, “O servidor respondeu com um certificado cujo nome comum não correspondia ao nome do host.” O certificado é real e válido, mas para um nome diferente. Alguém acessou www.example.com quando o certificado cobre example.com, ou um endereço IP puro, ou um host de staging que nunca foi adicionado à lista de nomes.

ERR_CERT_DATE_INVALID é o mais interessante, e vale a pena ler a descrição duas vezes: “O servidor respondeu com um certificado que, segundo o nosso relógio, parece ainda não ser válido ou já ter expirado.”

Segundo o nosso relógio. O navegador está comparando as datas do certificado com o relógio da máquina em que está rodando. Um certificado perfeitamente válido vai falhar nessa verificação em um dispositivo cujo relógio está errado, e um dispositivo com o relógio errado não é algo raro: um notebook que voltou de meses dentro de uma gaveta, um celular que perdeu a sincronização de horário, uma máquina virtual retomada a partir de um snapshot, um desktop em que alguém ajustou a data manualmente. A mesma página carrega para você e é recusada para a outra pessoa, e nada no erro diz de quem é o relógio errado.

ERR_CERT_AUTHORITY_INVALID é “O servidor respondeu com um certificado assinado por uma autoridade em que não confiamos.” Três situações bem diferentes produzem esse erro, e vale a pena diferenciá-las, o que fazemos a seguir.

ERR_CERT_REVOKED é “O servidor respondeu com um certificado que foi revogado” (a redação é a do próprio Chromium). Alguém revogou o certificado antes do vencimento, geralmente porque uma chave vazou. Esse aqui é genuinamente seu, e genuinamente urgente.

Os números também são estáveis, caso você acabe lendo logs em vez de telas: -200, -201, -202 e -206, respectivamente.

Três das cinco causas não são do seu servidor

Essa é a parte que transforma um erro de certificado em um problema de relato de bug, e não em um problema de operações.

O relógio. Já foi abordado acima. Seu certificado está bem. O dispositivo da outra pessoa discorda sobre que dia é hoje. Você não consegue reproduzir isso, não consegue corrigir do seu lado, e nenhuma quantidade de redeploy vai resolver.

A rede está lendo o tráfego. Um proxy corporativo, alguns antivírus e a maioria dos portais cativos de wifi público funcionam apresentando o próprio certificado para cada site e assinando-o com uma raiz que instalam na máquina. Quando isso funciona, o usuário não vê nada. Quando a raiz não está instalada, ou o dispositivo não é da empresa, todo site nessa rede mostra ERR_CERT_AUTHORITY_INVALID. O sinal revelador é que o erro segue a rede, não o site: a mesma pessoa nos dados móveis fica tudo bem.

O intermediário ausente. Um certificado é confiável através de uma cadeia: o seu é assinado por um intermediário, que por sua vez é assinado por uma raiz em que o navegador já confia. Seu servidor deveria enviar o intermediário junto com o próprio certificado. Se não enviar, alguns visitantes ficam bem mesmo assim, porque o navegador deles já tem esse intermediário de outra origem ou o busca na hora, e outros visitantes recebem ERR_CERT_AUTHORITY_INVALID.

Esse último caso merece uma frase só para ele, porque é o problema de configuração mais mal diagnosticado da web: uma cadeia sem o intermediário funciona na máquina de quem a configurou, e falha para uma fração de desconhecidos. A culpa é genuinamente do seu servidor, e o seu próprio navegador é o pior instrumento possível para encontrar isso.

Fraco

Um cliente diz que o site é inseguro. Verificamos no Chrome e no Safari aqui, o cadeado está ok. Pedimos para ele limpar o cache.

Melhor

NET::ERR_CERT_AUTHORITY_INVALID, só na wifi do escritório dele, funciona nos dados móveis. A mesma página está ok aqui. Proxy ou intermediário ausente, verificamos a cadeia de fora antes de culpar a rede dele.

Diferenciando as causas em um minuto

O código reduz a causa a uma entre três possibilidades. Três perguntas resolvem o resto.

Que horas o dispositivo dele acha que são? Pergunte pelo relógio, não pela data. Minutos importam para algumas coisas; para esse caso, estar um ano errado é o comum, e fica óbvio assim que você olha. Se o relógio estiver errado, ERR_CERT_DATE_INVALID já está explicado e não há mais nada a investigar. Um relógio de dispositivo silenciosamente errado por meses também é o motivo pelo qual “quebrou lá pelas três” pode te mandar para a hora errada dos seus logs, então vale a pena saber disso além desse erro específico. O guia de relato de bugs coloca o ambiente no modelo pelo mesmo motivo.

O erro segue a rede ou o site? Uma pergunta: acontece nos dados móveis? Um problema de certificado que desaparece quando o usuário sai da wifi é a rede apresentando o próprio certificado, e a correção fica do lado dele, ou do departamento de TI dele.

Acontece para alguém fora do seu escritório? Verifique a cadeia a partir de uma máquina que nunca visitou seu site, que é exatamente o que um verificador de SSL externo faz: ele se conecta do zero e informa o que seu servidor de fato enviou, em vez do que o seu navegador aprendeu a completar sozinho. Se ele apontar um intermediário ausente, o problema é do seu deploy, e provavelmente está quebrado para uma parte dos visitantes desde a última renovação do certificado.

A renovação que funcionou pela metade

Vale a pena conhecer esse padrão, porque ele produz a versão mais confusa desse problema.

Hoje os certificados são renovados automaticamente, e uma renovação que instala o certificado novo mas não o intermediário novo, ou que recarrega um processo e não outro, deixa um servidor correto de alguns ângulos e errado de outros. Usuários atrás de um load balancer caem no nó corrigido ou no desatualizado aleatoriamente. Metade dos relatos diz que está quebrado, metade diz que está tudo bem, as duas metades estão dizendo a verdade, e uma hora inteira é gasta procurando um padrão nos usuários quando o padrão está nos servidores.

A saída é parar de testar a partir de um navegador que talvez esteja te ajudando sem você perceber. Teste o endpoint, de fora, repetidamente.

O que quem relata o bug pode realmente te enviar

Aqui está o limite honesto, e ele vale para nós tanto quanto para qualquer um. Um aviso de certificado significa que a página nunca chegou a carregar. Não há console, não há log de rede, e não há nada para uma ferramenta de captura registrar, porque o navegador recusou antes mesmo do seu site rodar. O que você normalmente usa para enxergar uma falha pelos olhos de outra pessoa não está disponível nesse caso.

Então tudo volta a perguntar, e a perguntar pelas três coisas certas:

• O código, de trás do link Avançadas, na íntegra. NET::ERR_CERT_AUTHORITY_INVALID, e não “um aviso de segurança”.
• A data e a hora no dispositivo dele, lidas diretamente do relógio da pessoa.
• A rede, e se os dados móveis se comportam de forma diferente.

Três respostas, e a causa geralmente já está resolvida antes de alguém sequer olhar para um servidor. Essa é uma taxa de acerto melhor do que a maioria dos erros oferece, e ela só está disponível porque o navegador já fez o diagnóstico e o colocou atrás de um link que ninguém clica.

Uma coisa para não pedir: que a pessoa clique para ignorar o aviso. É o reflexo natural, o botão está bem ali, e numa interceptação de verdade isso entrega o tráfego para quem está interceptando. Se a causa for o relógio, corrigir o relógio leva os mesmos trinta segundos e mantém a verificação funcionando para o próximo site.

O que levar disso

A tela vermelha é uma categoria, não um diagnóstico. O código atrás de Avançadas é o diagnóstico, e ele vem de graça em cada ocorrência.

Três das causas moram na máquina do usuário ou na rede dele, então reproduzi-las na sua é impossível por construção, e a única que é genuinamente sua, o intermediário ausente, é justamente a que o seu próprio navegador tem menos chance de te mostrar. As duas metades disso apontam na mesma direção: para erros de certificado, peça o código e teste de fora, nessa ordem.

A própria lista de erros do Chromium, com a definição de uma linha de cada um, é o net_error_list.h. É a fonte a partir da qual as páginas de erro são geradas, e ela resolve discussões mais rápido do que qualquer artigo consegue.