O início de sessão PIV falha no Windows EAP-TLS? Verifique o percurso de assinatura
Um certificado no cartão pode estar visível e o início de sessão falhar na mesma. Percorra as quatro fases: perfil, seleção, assinatura local e validação remota.
Mostre o certificado de um cartão PIV em todas as caixas de diálogo do Windows e o início de sessão VPN pode continuar a falhar, porque visibilidade e utilizabilidade são propriedades diferentes. O certificado é um objeto público; o início de sessão exige uma operação de chave privada executada pelo cartão segundo as suas próprias regras de acesso. Entre estes dois factos situam-se quatro fases que falham de quatro maneiras diferentes: seleção do perfil, seleção do certificado, assinatura local e validação do lado do servidor. Percorrê-las por ordem transforma um erro genérico de handshake numa pergunta concreta para quem detém a peça seguinte.
Comece pelo perfil e pelo método EAP
Abra as propriedades da ligação e leia qual método EAP o perfil utiliza realmente, depois leia qual certificado o método está configurado para selecionar. Muitas implementações têm tanto um método exterior baseado em certificado como um método interior, e um certificado configurado ao nível da ligação não é automaticamente o que é apresentado dentro do EAP-TLS. Se o perfil escolhe um certificado por emissor ou por filtro de sujeito, esse filtro seleciona a partir do que o Windows consegue ver no arquivo relevante, e não a partir do que o cartão contém por acaso. Um filtro que não corresponde a nada recorre a um pedido ou a uma falha silenciosa, conforme a configuração do perfil, e é por isso que vale a pena registar a impressão digital selecionada antes de qualquer alteração.
Estabeleça também se a ligação corre como o utilizador com sessão iniciada ou como a máquina. Esse único facto determina que arquivos de certificados estão no âmbito e que contexto de segurança executa a assinatura.
Confirme que certificado foi selecionado
Compare a impressão digital que o Windows escolheu com o requisito: utilização para autenticação de cliente, uma cadeia que termina numa raiz fidedigna, uma identidade que a política do servidor de autenticação mapeia e um período de validade que cobre o momento efetivo da tentativa. São verificações separadas e a última apanha mais surpresas do que as pessoas esperam, sobretudo com certificados emitidos de forma rotativa e perfis em cache que ainda apontam para a seleção de ontem.
O contexto de utilizador e de máquina é a outra metade da verificação. Um certificado no arquivo pessoal do utilizador é invisível para um serviço que corre como a máquina, e um certificado de máquina não é apresentado por uma troca EAP em modo de utilizador, a menos que o perfil o diga. Reimportar um certificado para o arquivo errado produz um certificado visível e uma credencial de início de sessão invisível. Leia o caminho do arquivo no perfil, não o da caixa de diálogo que por acaso se abriu.
Teste a operação da chave sem adivinhar o PIN
Uma vez assente a seleção, a questão é se o cartão executará a assinatura. O Windows precisa de um fornecedor de cartão ou minidriver suportado para chegar à chave privada, e o dispositivo aplica as suas próprias regras de PIN e de presença à operação. Um cartão configurado para exigir um toque em cada assinatura comporta-se de forma diferente de um que guarda em cache uma verificação durante uma sessão, e ambas são configurações legítimas que mudam o momento em que surge um pedido. Essa diferença explica um início de sessão que tem êxito após uma inserção recente e falha depois de um retomar, sem que nenhum certificado esteja errado.
certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'
O primeiro comando inventaria o cartão e relata o estado do leitor e do fornecedor, o que está documentado nas orientações da Microsoft para depuração de cartões inteligentes. O segundo lista o que o contexto de utilizador consegue realmente ver. Nenhum deles prova uma autenticação bem-sucedida; ambos estreitam o ponto onde parou.
Não adivinhe o PIN. Os cartões impõem limites de tentativas, e algumas tentativas otimistas convertem um problema de permissões numa credencial bloqueada que exige recuperação administrativa. Se uma assinatura local falhar, registe o estado do fornecedor e o estado do cartão em vez de experimentar variantes. Repita a tentativa uma vez com o mesmo perfil, o mesmo certificado e um caminho de leitor reconhecidamente bom, e compare depois os dois registos; alterar várias variáveis ao mesmo tempo produz uma história e não um resultado.
Leia os dois lados do handshake
Uma assinatura concluída ainda não é admissão. O servidor de autenticação tem de aceitar a cadeia, verificar a revogação, mapear a identidade segundo as suas regras atuais e autorizar o pedido; o cliente tem, por sua vez, de validar o certificado do servidor como o perfil exige. Um alerta TLS gerado pelo servidor parece idêntico no registo do cliente ao gerado localmente, e é por isso que o lado que o emite importa mais do que o texto do alerta.
Recolha os eventos do Windows e os eventos do lado do servidor com marcas temporais alinhadas e identifique depois que lado produziu a primeira falha. O RFC 5216 descreve o passo de prova de posse no EAP-TLS, e um alerta genérico de handshake não nomeia por si só uma causa local da chave. A comparação das marcas temporais é o que transforma dois registos numa sequência.
Mantenha as fronteiras direitas no relatório
Escreva o relatório como quatro fases com um veredicto cada: que perfil e contexto correram, que certificado o Windows selecionou, se o cartão assinou e o que o servidor decidiu. Essa estrutura torna o passo seguinte óbvio e evita a reparação comum de desativar a validação para passar uma fase que ninguém identificou.
Um certificado de software como comparação temporária é um teste administrativo legítimo, mas altera o modelo de credencial e de garantia, pelo que pertence a uma alteração aprovada e não a um contorno silencioso em produção. A mesma disciplina aplica-se às tentativas de PIN e à reemissão de credenciais antes de se conhecer a fase que falha. Um cartão de substituição que falha de forma idêntica é prova dispendiosa de que o problema nunca esteve no cartão.