ERR_CERT_DATE_INVALID: certificado expirado ou relógio errado, e como corrigir

O que significa ERR_CERT_DATE_INVALID

Todo certificado TLS traz dois carimbos de tempo, "Valid from" e "Valid to" (os campos X.509 notBefore e notAfter). Durante o handshake, o navegador compara esses carimbos com a sua própria ideia de horário atual. Se a janela do certificado já se fechou, ou ainda não abriu, ou o relógio do navegador coloca o "agora" fora dessa janela por qualquer motivo, o handshake para antes mesmo de o navegador checar quem emitiu o certificado. Chrome e Edge mostram NET::ERR_CERT_DATE_INVALID. Firefox mostra SEC_ERROR_EXPIRED_CERTIFICATE no caso de expiração. Safari mostra "This certificate has expired" ou "This certificate is not yet valid."

Duas situações completamente diferentes produzem o mesmo aviso, e o navegador não consegue dizer qual delas é: o certificado realmente expirou ou ainda não é válido, ou o certificado está certo e o relógio do cliente está errado. As duas falham na mesma comparação.

Como o erro aparece

No navegador, a página nunca carrega e aparece um aviso ocupando a aba inteira, em vez de um ícone de cadeado com erro numa página já carregada. Clicar em "Avançado" mostra o motivo específico e, no Chrome, as próprias datas do certificado.

Na linha de comando, o curl relata a mesma falha com mais precisão:

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

Um certificado ainda não válido produz uma linha parecida, com "certificate is not yet valid." Os logs do servidor e da aplicação do lado de quem administra o site geralmente não mostram nada para esse erro, porque o handshake TLS falha antes de qualquer requisição HTTP ser registrada. A evidência está no certificado e no cliente, não no log de acesso do servidor web.

O que causa o ERR_CERT_DATE_INVALID

• O certificado expirou. A renovação não aconteceu antes da data "Valid to", quase sempre porque um job de renovação automática parou de rodar silenciosamente.
• O certificado ainda não é válido. Menos comum: um certificado foi emitido ou reemitido com uma data "Valid from" ligeiramente no futuro, ou um servidor começou a servir um certificado novo antes de a janela abrir.
• Um certificado intermediário da cadeia expirou. O certificado folha pode estar perfeitamente em dia enquanto um intermediário que o servidor ainda envia já passou da própria validade, e alguns clientes verificam cada certificado da cadeia.
• O relógio do dispositivo do visitante está errado. Um notebook que ficou desligado por meses, um celular com sincronização automática de horário desativada, ou um dispositivo com a bateria do CMOS morta podem iniciar com a data anos fora do lugar, para qualquer um dos lados.
• Uma máquina virtual ou contêiner com relógio parado. VMs que foram tiradas de snapshot, clonadas ou retomadas depois de uma pausa longa costumam iniciar com um relógio que só se acerta depois de uma sincronização NTP.
• Um fuso horário mal configurado ou uma data manual incorreta, definida por um usuário ou por um dispositivo tipo quiosque sem fonte de horário própria.

Como saber de quem é a culpa

A forma mais rápida de separar os dois casos é checar o certificado a partir de outro lugar, fora do dispositivo afetado. Se um segundo dispositivo com relógio correto, ou um ponto de verificação fora da sua rede, carrega o site sem aviso de data, o certificado está certo e o problema é local, no relógio daquele dispositivo. Se todos os pontos de observação relatam a mesma data expirada ou ainda não válida, é o próprio certificado que precisa de atenção. Rodar uma verificação de SSL a partir de vários lugares ao mesmo tempo resolve isso em uma única etapa, sem precisar pegar emprestado um segundo notebook para testar.

Como corrigir o ERR_CERT_DATE_INVALID

Se você é o visitante

1. Confira primeiro a data, o horário e o fuso horário do seu dispositivo. Essa é de longe a causa autoinfligida mais comum, especialmente em dispositivos Android com sincronização automática desativada, notebooks antigos que ficaram parados, e máquinas com a bateria do CMOS falhando. Ative "Definir hora automaticamente" e confirme que o ano está correto, não só o relógio na tela.
2. Tente o site em outro dispositivo ou outra rede. Se carregar normalmente em outro lugar, o relógio do seu dispositivo original (ou um portal cativo interceptando a conexão) é a causa, não o site.
3. Leia as datas reais na página de aviso antes de fazer qualquer outra coisa. O painel "Avançado" do Chrome e o visualizador de certificado mostram "Valid from" e "Valid to" em texto simples, o que diz na hora se o certificado está expirado, ainda não é válido, ou se o relógio errado é o seu.
4. Não clique para continuar em um certificado que realmente expirou, num site que lida com qualquer coisa sensível. Depois de corrigir o relógio, recarregue a página; não fique só tentando de novo o mesmo estado quebrado.

Se você administra o site

1. Leia as datas do próprio certificado diretamente, em vez de confiar num lembrete de calendário:

   openssl s_client -connect example.com:443 -servername example.com /dev/null   | openssl x509 -noout -dates

   Isso imprime notBefore e notAfter direto do certificado que o servidor está apresentando agora.
2. Se você usa Let's Encrypt, cheque o job de renovação, não só o certificado. Os certificados da Let's Encrypt duram 90 dias por design e renovam automaticamente perto dos 30 dias restantes, mas a automação pode falhar silenciosamente por semanas antes de alguém perceber: systemctl status certbot.timer (ou a entrada de cron equivalente) confirma que o timer ainda está ativo e disparando, e certbot renew --dry-run testa o caminho de renovação sem mudar nada em produção. Leia /var/log/letsencrypt/letsencrypt.log para ver a falha real, quase sempre um destes: um desafio DNS-01 cujas credenciais de API expiraram, uma mudança de firewall bloqueando o caminho do desafio HTTP-01, ou os limites de taxa da Let's Encrypt sendo atingidos durante tentativas repetidas de diagnóstico.
3. Confira a cadeia completa que o seu servidor envia, não só o certificado folha:

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Alguns servidores continuam servindo um intermediário antigo em disco depois de trocar o certificado folha. Todo certificado da cadeia precisa de uma janela de validade em dia, já que alguns clientes validam o caminho inteiro.
4. Verifique o relógio do próprio servidor. Um servidor com o horário errado pode emitir renovações automáticas com uma data "Valid from" incorreta, e também pode falhar na própria validação de OCSP e de handshake, independentemente do certificado. Confirme que o NTP está rodando e sincronizado.
5. Renove ou reemita o certificado, depois recarregue o servidor web. Um certificado renovado parado em disco não faz nada até que o processo que serve TLS o pegue: nginx -s reload, systemctl reload apache2, ou o equivalente num load balancer ou numa borda de CDN que guarda a própria cópia.
6. Confirme a correção a partir de fora da sua própria infraestrutura depois de recarregar, já que um navegador ou o sistema operacional na sua máquina pode manter o certificado antigo em cache por uma sessão.

Como prevenir o ERR_CERT_DATE_INVALID

Um certificado prestes a expirar não avisa ninguém que não esteja vigiando isso especificamente: o site continua funcionando até o exato segundo em que a janela se fecha, e então todo visitante vê o mesmo aviso ao mesmo tempo. Uma verificação de SSL programada que lê as datas do certificado e alerta antes do prazo, em vez de depois que os visitantes começam a reclamar de um site quebrado, transforma uma falha silenciosa de renovação num chamado corrigível com dias de antecedência. As verificações de SSL e expiração de domínio da HostTracker acompanham a janela de validade real do certificado a partir de fora da sua infraestrutura e alertam por e-mail, SMS, chamada de voz, Slack, Telegram e mais antes que ele vença; rode uma agora com a verificação de certificado SSL. O guia complementar sobre como checar a expiração do certificado SSL cobre essa configuração com mais detalhe.

Erros relacionados

• ERR_CERT_AUTHORITY_INVALID - as datas do certificado estão corretas, mas o navegador não confia em quem o emitiu.
• ERR_CERT_COMMON_NAME_INVALID - o certificado é válido e confiável, mas não foi emitido para o nome de host que está na barra de endereço.
• ERR_SSL_PROTOCOL_ERROR - o handshake falhou antes de qualquer certificado sequer ser alcançado, geralmente uma incompatibilidade de versão de TLS, de porta ou de configuração.

Perguntas frequentes

É seguro clicar para continuar num aviso de ERR_CERT_DATE_INVALID?

Só se você tiver certeza de que a causa é o relógio do seu próprio dispositivo, já que isso dá para verificar de forma independente. Se o certificado em si realmente expirou, clicar para continuar remove a única checagem que confirma que você está falando com o servidor de verdade, por um canal criptografado e verificado.

Por que isso acontece logo depois que eu reseto ou desembalo um dispositivo?

Um reset de fábrica ou um dispositivo que ficou muito tempo sem uso costuma iniciar com o relógio interno voltado para uma data padrão, às vezes anos no passado. Até que ele se conecte à internet e sincronize o horário automaticamente, todo site HTTPS pode falhar com erro de data, não só um.

Limpar o cache do navegador corrige o ERR_CERT_DATE_INVALID?

Raramente. Esse erro é uma comparação feita na hora, entre as datas do certificado e o relógio atual, avaliada de novo a cada conexão, então limpar o cache não muda o resultado. Corrigir o relógio ou o certificado, sim.

Por que meu certificado da Let's Encrypt expirou sem nenhum aviso?

Porque a renovação é feita para ser totalmente automática, ninguém checa manualmente, então um cron job quebrado, uma credencial de API DNS expirada, ou uma regra de firewall alterada podem parar as renovações silenciosamente por semanas, sem nenhum sintoma visível até o certificado realmente vencer.

Um CDN ou load balancer pode mudar o que o visitante vê nesse erro?

Sim. Se a borda do CDN guarda um certificado expirado, todo visitante vê o erro independentemente do certificado que o servidor de origem tem, então confira qual camada está de fato encerrando o TLS na requisição que falhou.

Com que frequência devo checar a data de expiração do meu certificado?

Uma verificação automática diária já é suficiente para pegar uma falha de renovação com semanas de antecedência, já que os certificados da Let's Encrypt valem 90 dias e a maioria dos outros certificados fica entre 90 dias e um ano.