Certificado VPN ainda não válido: três causas, uma ordem de verificação
Ainda não válido significa que o relógio do dispositivo está atrasado, que a janela começa mesmo mais tarde ou que um certificado intermédio ainda não abriu. Verifique-os nessa ordem.
Abre o cliente, escolhe o perfil que usa há meses e ele para com "certificate is not yet valid". Nada no seu início de sessão mudou, e o armazenamento de confiança está provavelmente bem: o certificado apresentado no handshake tem uma janela de validade que começa mais tarde do que o instante usado pelo verificador. Três situações diferentes produzem exatamente essa mensagem, e exigem ações diferentes. A ordem abaixo diz-lhe qual tem antes de tocar num relógio ou num ficheiro de certificado.
Qual das três causas está a ver
A primeira causa é local: o dispositivo que faz a verificação tem um relógio anterior à data de início do certificado. Vê-se em hardware com uma bateria CMOS morta, em máquinas virtuais restauradas de um instantâneo antigo, em equipamentos que estiveram desligados tempo suficiente para perder a hora e em redes onde o NTP de saída está bloqueado e ninguém reparou. O certificado pode ser totalmente válido e ainda assim falhar desta forma.
A segunda causa pertence ao emissor, porque o certificado começa mesmo no futuro: emitido cedo, gerado com uma hora de início explícita ou assinado como parte de um passo de ativação que ainda não correu. A terceira causa é a que mais tempo faz perder, porque o certificado folha está atual enquanto outro certificado da cadeia apresentada não está, pelo que o erro nomeia material que nunca instalou.
Uma pergunta separa-as. A falha segue o dispositivo ou o serviço? Duas máquinas na mesma rede a comportarem-se de forma diferente apontam para relógios. Todos os clientes a falharem da mesma forma apontam para a janela do certificado e para a cadeia por trás dela.
Leia a janela a partir do certificado que foi realmente apresentado
Não inspecione um ficheiro PEM que sobrou de uma implementação anterior; peça ao serviço a cadeia que ele envia agora. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts imprime cada certificado da cadeia. Guarde o bloco que lhe interessa e execute openssl x509 -noout -subject -issuer -dates; o último imprime notBefore e notAfter, e são esses dois valores que decidem. No Windows, a caixa de diálogo do certificado da ligação e certutil -dump num ficheiro exportado mostram os mesmos campos.
Leia as duas extremidades da janela, não só o início. Um certificado que abre dentro de duas horas e outro que fecha dentro de duas horas falham com mensagens diferentes e envolvem equipas diferentes. Anote que certificado o erro nomeia — folha, intermédio ou raiz —, porque isso decide se algo do lado do cliente pode ser reparado.
Também pode testar a janela sem esperar por ela. A verificação aceita uma hora explícita: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem avalia a cadeia nesse timestamp. Execute-o com a hora atual para reproduzir a falha e depois com a hora de início do certificado para confirmar que a mesma cadeia passa quando a janela abre. RFC 5280 define o campo de validade e a regra de que um certificado não deve ser usado fora dele, e é exatamente essa a regra que o seu cliente acabou de aplicar.
O seu relógio ou o deles
Compare o relógio do dispositivo com o início do certificado em UTC, a partir de uma fonte em que confie. date -u dá o instante, e timedatectl status num anfitrião systemd também indica se o relógio está sincronizado. No Windows, w32tm /query /status mostra a fonte atual e a última sincronização bem-sucedida. O fuso horário mostrado na bandeja é uma escolha de apresentação, não um relógio errado; o verificador compara instantes UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Se o relógio está atrasado, ressincronize e teste novamente antes de alterar qualquer material de certificado. Um dispositivo desviado em minutos ou horas rejeita todos os certificados emitidos recentemente que encontra, não apenas um serviço, pelo que uma explicação de um único serviço é normalmente a errada. Se o relógio está correto e sincronizado, pare de olhar para o dispositivo: a janela pertence ao emissor, e nenhuma definição local deve ser ajustada para a fazer passar.
Essa tabela é toda a decisão. Mover o relógio para o que o certificado espera não é uma reparação, e desativar as verificações de hora também não é, porque ambas escondem a condição que produziu o erro.
Porque a cadeia falha enquanto a folha parece bem
As folhas renovadas e os intermédios de substituição são normalmente enviados juntos, e nem sempre chegam no mesmo momento. Um serviço pode enviar uma folha nova assinada por um intermédio cuja própria janela começa mais tarde, ou continuar a servir um intermédio mais antigo sob uma folha nova. De qualquer forma a cadeia falha enquanto as datas da própria folha parecem razoáveis.
Os pontos finais com balanceamento de carga transformam isto de avariado em inconsistente. Se uma nova tentativa tiver sucesso, ou uma rede funcionar e outra não, registe qual par respondeu e que cadeia enviou antes de alterar definições. openssl s_client imprime o endereço ligado, pelo que algumas tentativas revelam se cada nó serve a mesma cadeia.
Caminhos de reparação que mantêm a verificação intacta
Um problema de relógio corrige-se no dispositivo com a verificação ativada. Um problema de certificado é corrigido pelo operador com material emitido para uma janela que já inclui o agora. Nenhuma definição do cliente torna válido um certificado ainda não válido; os sinalizadores que saltam as verificações de hora existem para confirmar um diagnóstico, não para serem implementados.
Quando o certificado está preparado para uma ativação planeada, siga o plano de transição. Instale-o quando a sua janela abrir, ou use o procedimento de sobreposição que o fornecedor documenta, em vez de o instalar cedo e ensinar os utilizadores a clicar através dos avisos. Os avisos que as pessoas aprendem a ignorar custam mais do que um curto atraso.
Por fim, teste novamente tal como a falha aconteceu: uma sessão nova, o mesmo cliente, o recurso de que realmente precisa. As bibliotecas TLS podem guardar em cache uma cadeia verificada durante toda a vida de uma ligação, e uma sessão retomada não a verifica necessariamente outra vez, pelo que uma sessão antiga pode continuar a falhar após a correção ou continuar a funcionar após uma regressão. Um ficheiro que abre num visualizador só prova que o ficheiro é legível; um handshake concluído prova que a cadeia valida.
Antes de fechar o ticket, confirme quatro coisas: a hora UTC e o estado de sincronização do dispositivo que falha, o notBefore e o notAfter de cada certificado na cadeia apresentada, a mesma cadeia a partir de um segundo cliente e o nome que o erro dá ao certificado. Se o relógio estiver correto e a janela não tiver aberto, o resto é trabalho do operador, e o movimento correto do seu lado é esperar pela janela em vez de enfraquecer a verificação.