SafeNet Token Servidor: Por Que o Driver Não Funciona no Windows Server 2022 (e Como Resolver)

Token SafeNet plugado, driver instalado, e mesmo assim o Windows Server não detecta o certificado A3? Se você caiu aqui buscando SafeNet token servidor não funcionando, o problema quase certamente não é o token — é a versão do driver. Vamos direto ao diagnóstico e à correção real, testada em ambiente de produção.

O cenário: certificado A3 físico, sistema fiscal na nuvem

Esse problema aparece toda vez que uma empresa move seu sistema fiscal/ERP para um servidor em nuvem (Windows Server, acessado via RDP), mas o certificado digital A3 do responsável continua em um token físico — geralmente um SafeNet eToken 5110/5100 distribuído por uma Autoridade Certificadora (Certisign, Serasa, Soluti, etc).

Isso não é caso raro. Segundo dados oficiais do ITI (Instituto Nacional de Tecnologia da Informação), a ICP-Brasil soma atualmente mais de 14,7 milhões de certificados digitais ativos, dos quais mais da metade (50,3%) pertence a pessoas jurídicas — a maioria delas, empresas sem infraestrutura própria de TI, dependendo de MSPs ou de si mesmas para resolver esse tipo de integração.

O erro mais comum: achar que basta instalar o driver

A primeira reação de quem enfrenta isso é: “só preciso instalar o SafeNet Authentication Client no servidor”. Parcialmente certo, mas isso sozinho não resolve — e tentar “exportar a chave privada” para o servidor, como algumas pessoas cogitam, é tecnicamente impossível por design: certificados A3 são gerados dentro do chip do token e a chave privada nunca sai do hardware. Não existe opção de export de chave privada em um token A3 íntegro — só do certificado público, que sozinho não assina nada.

A arquitetura correta é: o token continua fisicamente no cliente. O servidor “enxerga” o token através do redirecionamento de smart card do próprio protocolo RDP.

[Token no cliente] → [RDP com redirecionamento de smart card] → [Servidor: SafeNet Authentication Client + serviço Smart Card] → [Sistema fiscal assina remotamente]

Diagnóstico: por que o driver “antigo” não funciona no Server 2022

Se o cliente já usa o token normalmente na própria máquina, é comum que a Autoridade Certificadora tenha distribuído uma versão antiga do SafeNet Authentication Client (SAC) — vimos casos reais com a versão 10.6, lançada ainda em 2015/2016. Rodando essa versão no servidor, o token simplesmente não aparece.

A causa raiz está documentada oficialmente pela Thales (fabricante atual da linha SafeNet, ex-Gemalto):

“O Windows Server 2022 usa por padrão um novo driver CCID (UMDF2) para tokens USB. Tokens Thales não são detectáveis quando esse driver está em uso.” — Thales, nota de lançamento do SAC 10.9 R1

Para resolver isso, a Thales criou o Thales UMDF2 CCID Service, incluído a partir da versão 10.9 R1, que redireciona o token de volta para o driver correto. Sem essa versão, o driver instala, o serviço sobe, mas o Windows nunca associa o token a ele.

Comando de verificação — e por que ele pode não encontrar nada

Antes de baixar qualquer driver, é tentador tentar identificar o token via PowerShell, filtrando pelo nome do dispositivo:

Get-PnpDevice -PresentOnly | Where-Object {$_.Class -eq "SmartCardReader" -or $_.FriendlyName -like "*Smart Card*" -or $_.FriendlyName -like "*Token*"} | Select FriendlyName, InstanceId, Status, Class

Atenção: esse comando pode voltar vazio mesmo com o token corretamente plugado. O FriendlyName que o Windows atribui ao leitor depende do fabricante — em um caso real, o leitor SafeNet apareceu identificado apenas como AKS ifdh 0, um nome que não contém nem “Token” nem “Smart Card”. Resultado vazio nesse comando não é diagnóstico de ausência do token — só significa que o nome do dispositivo é diferente do esperado.

Método confiável, que sempre funciona: abra o SafeNet Authentication Client Tools já instalado no cliente (ou o software rebrandeado da Autoridade Certificadora, ex: Certisign) → clique com o botão direito no token → View Token Info. Essa tela mostra modelo, firmware, nome do leitor e versão do applet — é a fonte de verdade, e foi assim que o modelo exato foi confirmado no caso real que originou este artigo.

Onde baixar a versão correta

Não use o instalador que já está “guardado” há anos na pasta de instalação do cliente, nem confie cegamente na tabela pública de downloads da sua Autoridade Certificadora — algumas ainda listam compatibilidade só até Windows 10, mesmo já distribuindo internamente builds mais novas. Confirme a versão real do pacote antes de instalar.

Download oficial (Thales, via mirror DigiCert), versão 10.9 R1 GA, com suporte confirmado a Windows Server 2022, 2019, 2016 e 2012 R2:

https://www.digicert.com/StaticFiles/Windows_SAC_10.9_R1_GA.zip

Se sua CA já distribuir a mesma versão (10.9 R1) rebrandeada, pode usar a dela — o motor é idêntico, muda só o instalador visual.

Solução passo a passo (testado em produção)

1. Backup antes de qualquer coisa

Servidor em produção multiusuário: não pule esse passo. Snapshot da VM (ou snapshot do provedor de nuvem) antes de instalar qualquer driver.

2. Padronize a pasta antes de instalar

Antes de rodar qualquer comando, extraia o .zip baixado sempre no mesmo lugar — evita erro de caminho truncado ou digitado errado na hora de montar o comando. Crie uma pasta fixa para isso, por exemplo:

mkdir C:\Certisign\SAC

Extraia o conteúdo do .zip do driver dentro dela. Com isso, você já sabe de cabeça qual caminho usar no comando — sem precisar copiar nome de arquivo do Explorer, que costuma truncar nomes longos e gerar erro de “arquivo não encontrado” no msiexec.

Se já extraiu em outro local (ou não seguiu esse padrão), descubra o caminho exato assim: no Explorer, segure Shift e clique com o botão direito na pasta onde está o .msi → “Copiar como caminho”. Cole esse caminho direto no lugar do .msi no comando — isso garante que o nome do arquivo venha exato, sem truncamento.

Alternativa via terminal, caso prefira confirmar por comando (varre o disco procurando o instalador):

Get-ChildItem -Path "C:\" -Filter *.msi -Recurse -ErrorAction SilentlyContinue | Where-Object {$_.Name -like "*SafeNet*"} | Select FullName

3. Instalação em servidor RDS multiusuário

Se o servidor tem múltiplos usuários conectados simultaneamente (Remote Desktop Session Host), use change user /install antes de instalar e change user /execute depois — isso garante que as configurações de interface do SAC sejam replicadas corretamente para o perfil padrão, não só para o usuário administrador que fez a instalação:

change user /install
msiexec /i "C:\Certisign\SAC\SafeNetAuthenticationClient-x64-10.9.msi" /qn /norestart
change user /execute

⚠️ Atenção com o copy-paste no CMD: se colar os três comandos de uma vez em terminais que “engolem” quebra de linha, eles podem se concatenar (change user /executechange user /install) e o segundo comando falha silenciosamente com “Parâmetro(s) inválido(s)”. Rode linha por linha, confirmando o retorno de cada uma antes de ir para a próxima — ou use a versão em linha única abaixo, que evita esse problema por completo, já que o && garante a ordem de execução independente de como o terminal tratar a quebra de linha do paste:

change user /install && msiexec /i "C:\Certisign\SAC\SafeNetAuthenticationClient-x64-10.9.msi" /qn /norestart && change user /execute

Se você padronizou a pasta no passo anterior, o caminho já sai pronto — só ajustar o nome exato do arquivo .msi (confirme com dir C:\Certisign\SAC\*.msi antes de rodar). Com &&, cada comando só roda se o anterior terminar sem erro — se o msiexec falhar, o change user /execute nem chega a ser executado, o que também funciona como proteção extra.

3. Validar se o msiexec realmente instalou

%ERRORLEVEL% sozinho, rodado depois de outro comando (como change user /execute), não reflete o resultado do msiexec — ele mostra o código de saída do último comando executado. Para confirmar de verdade que o driver instalou, use o log real do Windows Installer:

Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-1)} | Where-Object {$_.ProviderName -like "*MsiInstaller*"} | Select TimeCreated, Id, Message | Format-List

Procure pela linha Installation operation completed successfully com Status de erro ou êxito da instalação: 0.

4. Reboot obrigatório

O driver CCID só é finalizado no primeiro boot após a instalação. Não pule o reboot achando que vai economizar tempo — sem ele, o serviço principal (SACSrv) nem aparece na lista de serviços do Windows.

shutdown /r /t 60 /c "Manutenção agendada - driver certificado digital"

5. Confirmar o serviço após o boot

Get-Service SACSrv, SCardSvr | Select DisplayName, Status, StartType

Se SCardSvr aparecer como Stopped mesmo com StartType Automatic: não é erro. É um serviço trigger-start — ele só sobe quando um leitor de smart card é detectado ativamente. Force o start manualmente se quiser validar antes do teste real:

Set-Service SCardSvr -StartupType Automatic
Start-Service SCardSvr

6. Habilitar redirecionamento de smart card na GPO

gpedit.msc → Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection → "Do not allow smart card device redirection" → Desabilitado

gpupdate /force

7. Habilitar redirecionamento no lado do cliente

Ao abrir a conexão RDP: Mostrar Opções → Recursos Locais → Mais… → marcar “Cartões inteligentes ou Windows Hello para Empresas”.

Se usa arquivo .rdp salvo, adicione a linha:

redirectsmartcards:i:1

8. Teste real — dentro da sessão RDP, não na máquina local

Esse é o erro mais comum de validação: testar o certificado na tela local do cliente (fora do RDP) só confirma o que já era sabido — que o token funciona ali. O teste que importa é dentro da sessão remota:

certutil -scinfo

Se o certificado aparecer listado, a cadeia está funcionando. Para confirmar de verdade que a chave privada responde (não só que o certificado é visível), force uma autenticação real — abrir o e-CAC (https://cav.receita.fazenda.gov.br) dentro da sessão RDP e selecionar o certificado. Se o Windows pedir o PIN do token e aceitar, a integração está validada ponta a ponta.

FAQ técnica

O driver antigo do site da Autoridade Certificadora sempre está desatualizado?

Não necessariamente — mas a tabela de compatibilidade exibida publicamente pode estar defasada mesmo quando o pacote real já foi atualizado internamente. Sempre confirme a versão exata dentro do instalador (.msi) antes de assumir que está com a build certa, independente do que a página de downloads afirma.

“change user /install” resolve o problema se eu esquecer de rodar?

Não é a causa da falha de detecção do token — isso afeta apenas onde ficam gravadas configurações de interface por usuário em servidores RDS multiusuário. Os componentes que fazem o token funcionar (driver CCID, minidriver, serviço UMDF2) são per-machine e instalam corretamente mesmo sem esse comando. Vale usá-lo como boa prática em RDS, mas não é a causa de um token não detectado.

Por que o serviço Cartão Inteligente (SCardSvr) aparece como “Stopped” mesmo depois de configurado como automático?

Porque é um serviço trigger-start do Windows: ele inicia sozinho quando um leitor de smart card é detectado em uso ativo e para quando não há nenhum conectado. Não é sinal de erro — é comportamento padrão do sistema operacional para economizar recursos.

Box de atenção: Redirecionar smart card via GPO no nível do servidor RDS habilita o recurso para todos os usuários conectados, não só para quem precisa assinar documentos com o token. Isso não expõe nenhum certificado alheio — só disponibiliza a possibilidade de redirecionamento — mas documente a mudança, porque outro técnico investigando o servidor no futuro vai encontrar essa política alterada e precisa saber o motivo.

Se esse tipo de detalhe técnico faz diferença no seu dia a dia — ou se sua empresa está enfrentando algo parecido com certificado digital em servidor de nuvem — fale com a gente no WhatsApp.