O certificado do gateway está bem: por que o login IKEv2 PEAP continua falhando

O certificado do seu gateway VPN está válido, a cadeia é validada, e o cliente IKEv2 ainda recusa o login com uma mensagem sobre um intervalo de validade de certificado. O primeiro impulso é reemitir o certificado do gateway ou mudar o método EAP, e ambos costumam estar errados. A tentativa de login carrega duas identidades de servidor separadas: o certificado do gateway usado pelo IKE, e o certificado apresentado por quem termina o PEAP. Uma delas está bem, e a outra é o motivo pelo qual o cliente parou.

Duas identidades, uma tentativa de login

O certificado no perfil VPN pertence à troca IKE: ele prova que o gateway é o par nomeado pelo perfil, sob a política IKE configurada. O certificado que falha aqui pertence a outra conversa, a sessão TLS que o PEAP abre com quem autentica o usuário, que muitas vezes é um servidor RADIUS como o NPS e não o próprio gateway. Uma terceira verificação, a credencial do usuário, acontece dentro dessa sessão. Uma senha válida não consegue reparar um certificado de servidor expirado, e um certificado de gateway válido não pode abonar o endpoint PEAP.

Esse empilhamento explica por que um erro de certificado aparece num lugar onde o único certificado configurado era o do gateway. Também explica por que reemitir esse certificado não muda nada.

Leia a linha do log em relação ao estágio

Encontre a mensagem que nomeia o motivo e as datas. Uma reclamação sobre o intervalo de validade ao lado de um erro de sujeito significa que o servidor rejeitou o certificado que recebeu, não que o usuário rejeitou o login. Depois encontre o estágio: um log charon do strongSwan mostra IKE_SA .* established antes de a troca EAP começar, então um erro de certificado depois dessa linha pertence à identidade EAP, enquanto um erro antes dela aponta para o gateway. O texto do estágio no painel de conexão de um cliente Windows diz o mesmo.

Verifique o relógio do cliente antes de tocar em qualquer certificado. Um dispositivo com horas de diferença produz o mesmo erro de validade que um certificado realmente expirado. Ajustar o relógio é uma correção de cinco segundos, e substituir um certificado que nunca foi o problema é uma queda.

Descubra qual endpoint termina o PEAP

Num desenho de gateway mais RADIUS, o gateway encaminha o EAP e não o termina. O plugin eap-radius do strongSwan entrega a troca ao servidor RADIUS, que possui a sessão TLS do PEAP e o certificado dela. Correlacione uma tentativa malsucedida nos dois logs e confirme qual processo realmente escolheu um certificado para essa sessão.

Para o NPS o certificado precisa estar no repositório do computador local, carregar a finalidade de autenticação de servidor, coincidir com o nome que os clientes esperam e ser legível pela conta de serviço. Os requisitos de certificado da Microsoft para o NPS listam essas condições. Outros servidores EAP têm regras de seleção próprias, então não copie particularidades do NPS para uma implantação FreeRADIUS nem o contrário. A regra que vale nos dois casos é que o endpoint que termina o PEAP é o dono do certificado que você está prestes a mudar.

Substitua o certificado onde o EAP termina

Renove ou substitua o certificado no endpoint que termina o PEAP, pelo processo suportado, mantendo a finalidade de autenticação de servidor e o nome esperado. Instale a cadeia completa onde o serviço a procura e conceda ao serviço acesso à chave privada. Reinicie ou revincule o serviço, porque muitos serviços mantêm o certificado antigo na memória e continuam a apresentá-lo. Um arquivo copiado para a máquina não prova nada sobre qual certificado o serviço realmente apresenta.

Confirme a mudança correlacionando a próxima tentativa com o log do próprio serviço, ou inspecionando o certificado que a sessão apresentou. Se esse log ainda mostra a impressão digital antiga, a reinicialização não pegou.

Não presuma que o arquivo mais recente de um diretório é o que está em uso. Uma cópia com o nome certo e as permissões erradas não muda nada. Julgue a mudança pela identidade apresentada, não pelo carimbo de data de um arquivo.

O que não fazer

Não desative a validação do PEAP nem force um método interno mais fraco para contornar o erro. Isso muda a política e remove a propriedade de autenticação de servidor que flagrou o certificado expirado em primeiro lugar. Você trocaria uma verificação que funciona por uma conexão que funciona, e o próximo certificado expirado chegaria sem nada que o anunciasse.

Não tome uma conexão bem-sucedida de outro sistema operacional como prova de que o certificado é aceitável. Esse cliente pode usar outro método EAP, outro repositório de confiança ou nenhuma validação de servidor, então o sucesso dele não diz nada sobre a verificação que falhou aqui. Mantenha um teste negativo deliberado, como um certificado com o nome errado ou uma cadeia não confiável, que falhe conforme o esperado. Se esse teste agora passa, você removeu uma verificação em vez de consertar um certificado. Anote qual identidade falhou, para que a próxima pessoa não comece de novo pelo certificado do gateway.