Web PKI RDS exige Chrome como administrador? A causa real (e a correção)

Equipe Thompsontech

Web PKI RDS travado — só funciona quando alguém abre o Chrome como administrador para autenticar no SIARE (ou qualquer outro portal) a partir de um Terminal Server? Neste post mostramos como identificamos e corrigimos essa causa em um ambiente RDS real, sem precisar dar privilégio elevado a ninguém.

O sintoma

Web PKI instalado e funcionando — mas só para o usuário que fez a instalação, inclusive quando esse mesmo usuário abria o Chrome com privilégio administrativo. Para os demais usuários do RDS, o site (SIARE, e-CAC, qualquer portal que use o Web PKI) não encontra o conector e pede reinstalação, mesmo com o programa já presente na máquina.

O Web PKI está longe de ser um componente raro: a extensão oficial na Chrome Web Store soma atualmente cerca de 4 milhões de usuários. Em um computador de uso individual, o local exato do registro do Native Messaging Host não costuma importar. Em um servidor RDS, vários perfis de usuário compartilham a mesma máquina, e esse detalhe passa a ser decisivo.

Passo 1 — garanta que a instalação foi feita no modo correto do RDS

Em um Terminal Server/RDS, instalar um programa clicando duas vezes no instalador — mesmo como administrador — não é o caminho recomendado quando ele vai ser usado por vários usuários. O Windows tem um modo específico pra isso: pelo Painel de Controle é a opção “Instalar Aplicativo no Servidor de Área de Trabalho Remota”; via linha de comando, o equivalente é o comando change user. Foi assim que reinstalamos o Web PKI no ambiente deste caso, antes de chegar na correção de registro mostrada mais abaixo.

Se o Web PKI já estiver instalado fora desse modo (como estava no nosso caso), o primeiro passo é identificar e remover a instalação atual:

Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Web PKI*"}

Resultado real: IdentifyingNumber : {FC074490-21C0-7DBF-2AA5-3469FA54066A} Name : Web PKI Version : 2.16.0.0

Com o IdentifyingNumber em mãos, desinstale (troque pelo código encontrado no seu ambiente):

Start-Process msiexec.exe -ArgumentList '/x', '<IdentifyingNumber>', '/qn', '/L*v', 'C:\Temp\webpki_uninstall.log' -Wait

Resultado real (no log): Product: Web PKI — Removal completed successfully. Status de erro ou êxito da remoção: 0.

Depois, instale de novo já no modo correto de RDS:

change user /install

msiexec /i "C:\caminho\para\WebPkiSetup_2.16.0_pt.msi" /qn /L*v C:\Temp\webpki_install.log

change user /execute

Resultado real (no log): Product: Web PKI — Installation completed successfully. Status de erro ou êxito da instalação: 0.

Importante: instalar dessa forma é boa prática para qualquer software multiusuário em RDS, mas não é garantia isolada de que os demais usuários já vão enxergar o Web PKI. No ambiente que testamos, mesmo depois desse fluxo, a chave do Native Messaging Host continuou restrita ao HKCU do usuário que instalou. Trate essa reinstalação como preparação — e confirme depois se a chave apareceu em HKLM, ou aplique a correção mostrada na seção “Ambiente testado” a seguir.

A causa raiz

O Web PKI não roda como serviço do Windows. Ele é um aplicativo comum (Lacuna.WebPKI.ChromeWin.exe) que o Chrome inicia sob demanda, toda vez que uma página pede um certificado — pelo protocolo Native Messaging, documentado oficialmente pela Chrome for Developers como comunicação via entrada e saída padrão (stdin/stdout).

Para o Chrome saber qual executável chamar, ele consulta uma chave no Registro do Windows dentro de NativeMessagingHosts, que aponta para um arquivo de manifesto (native-host-chrome.json). Essa chave pode existir em dois lugares: HKEY_CURRENT_USER (visível só para quem instalou) ou HKEY_LOCAL_MACHINE (visível para todos os usuários da máquina).

Na instalação que investigamos, encontramos essa chave apenas em HKCU, no perfil do usuário que instalou o Web PKI. Tentamos primeiro o caminho padrão de instalação multiusuário do RDS — desinstalar, rodar change user /install, reinstalar e voltar com change user /execute. O sintoma continuou para os usuários comuns depois disso.

Uma ressalva técnica importante aqui: o Windows Server documenta que, em modo /install, chaves criadas em HKCU durante a instalação ficam “sombreadas” em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install — um local específico para esse mecanismo de compatibilidade, diferente da chave em HKLM que registramos na correção abaixo — e só são copiadas para o HKCU de um usuário quando esse usuário (ou o próprio Chrome) tenta ler a chave pela primeira vez e não a encontra. Não testamos esse gatilho isoladamente com um usuário comum — como a correção definitiva abaixo (registrar direto em HKLM, no caminho que o Chrome já consulta nativamente) resolve de forma imediata, sem depender de nenhum evento de “primeira leitura”, seguimos por ela em vez de investigar se o modo de instalação do RDS teria funcionado com mais tempo ou outro gatilho de logon.

Vale reforçar: os componentes nativos do Web PKI, segundo a documentação oficial de segurança da Lacuna Software, não necessitam de privilégios de administrador para sua execução. O requisito de elevação nunca foi do programa — foi um efeito colateral de qual perfil de registro o Chrome conseguia enxergar.

Como confirmamos a causa antes de alterar o servidor

• Web PKI funcionava normalmente quando o Chrome era aberto no contexto do usuário que fez a instalação — inclusive via elevação administrativa.
• Falhava para qualquer outro usuário do RDS, mesmo com o Web PKI corretamente instalado.
• A chave com.lacunasoftware.webpki só existia em HKEY_CURRENT_USER, no perfil de quem instalou.
• O manifesto apontava, com caminho relativo, para o executável na mesma pasta — o que permitia mover a instalação inteira sem editar nada dentro dela.
• Criamos a mesma chave em HKEY_LOCAL_MACHINE, apontando para uma cópia da instalação em diretório compartilhado.
• Testamos de novo com o mesmo usuário comum que falhava antes — sem elevar o Chrome, sem senha de administrador.
• Autenticação no SIARE funcionou normalmente.

Ambiente testado

Este caso de Web PKI RDS foi documentado em Windows Server, ambiente RDS multiusuário, Web PKI 2.16.0.0, autenticação via SIARE (SEF/MG). Os comandos abaixo são exatamente os que aplicamos e confirmaram a correção. Onde aparecer o nome do usuário que fez a instalação original, substitua pelo usuário correspondente no seu ambiente.

Importante: os comandos abaixo (copiar arquivos, ajustar permissão, criar chave em HKLM) precisam ser executados em um PowerShell com privilégio administrativo. Isso não muda o resultado final — depois de aplicados, os usuários comuns do RDS passam a usar o Web PKI sem qualquer elevação, que é exatamente o problema que estamos corrigindo.

1. Confirmar onde está o registro (diagnóstico, não altera nada)

Antes de mexer em qualquer coisa, localize a chave existente no perfil de quem instalou — é dela que vamos copiar o caminho do manifesto:

Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" -ErrorAction SilentlyContinue

Resultado real: com.lacunasoftware.webpki (default) : C:\Users\<usuário que instalou>\AppData\Local\Lacuna Software\Web PKI\native-host-chrome.json

2. Copiar a instalação para uma pasta compartilhada

O manifesto usa caminho relativo para o executável — isso permite mover a pasta inteira sem editar nada dentro dela. Copiamos para ProgramData, que é acessível a qualquer usuário da máquina:

New-Item -ItemType Directory -Path "C:\ProgramData\Lacuna Software" -Force

Copy-Item -Path "C:\Users\<usuário que instalou>\AppData\Local\Lacuna Software\Web PKI" -Destination "C:\ProgramData\Lacuna Software\Web PKI" -Recurse

3. Liberar permissão de leitura/execução para todos os usuários

Usamos o SID do grupo (S-1-5-11 = “Usuários Autenticados”/”Authenticated Users”) em vez do nome — o SID é o mesmo em qualquer idioma do Windows, o que evita erro de “mapeamento não encontrado” em servidores em português:

icacls "C:\ProgramData\Lacuna Software\Web PKI" /grant "*S-1-5-11:(OI)(CI)RX" /T

Resultado real: Processados com sucesso 17 arquivos; falha no processamento de 0 arquivos.

Validação de segurança:/grant adiciona a permissão de leitura/execução para Usuários Autenticados, mas não remove nem substitui outras permissões explícitas ou herdadas que a pasta já tivesse. Antes de considerar o passo concluído, confira as permissões efetivas:

icacls "C:\ProgramData\Lacuna Software\Web PKI"

Confirme que usuários comuns aparecem só com RX (leitura/execução) — não com M (modificar) ou F (controle total) herdados de alguma ACL da pasta pai. É um executável chamado diretamente pelo Chrome — vale esse cuidado extra antes de liberar para todos os usuários do RDS.

4. Registrar a chave em HKLM apontando para o novo local

Esta é a correção central — a mesma chave que existia só em HKCU, agora visível para todos os usuários da máquina:

New-Item -Path "HKLM:\Software\Google\Chrome\NativeMessagingHosts\com.lacunasoftware.webpki" -Force

Set-ItemProperty -Path "HKLM:\Software\Google\Chrome\NativeMessagingHosts\com.lacunasoftware.webpki" -Name "(Default)" -Value "C:\ProgramData\Lacuna Software\Web PKI\native-host-chrome.json"

5. Validar

Get-ItemProperty "HKLM:\Software\Google\Chrome\NativeMessagingHosts\com.lacunasoftware.webpki"

Resultado real: (default) : C:\ProgramData\Lacuna Software\Web PKI\native-host-chrome.json

Teste final: logue com um usuário comum (sem admin), abra o Chrome sem elevar e autentique no portal com o certificado. Nenhuma senha administrativa envolvida.

O que acontece quando o Web PKI for atualizado?

Este procedimento cria uma cópia da instalação fora da pasta original (%LocalAppData% do usuário que instalou). Não validamos como uma atualização futura do Web PKI se comporta em relação a essa cópia em ProgramData — se o instalador vai atualizá-la junto ou não. Por isso, depois de qualquer atualização do Web PKI, recomendamos comparar a versão em uso pelo RDS com a versão em C:\ProgramData\Lacuna Software\Web PKI e repetir a cópia se necessário.

Prevenção — em instalações novas, vale avaliar a distribuição via GPO

O procedimento acima corrige uma instalação que já foi feita apenas no perfil de um usuário. A própria Lacuna Software documenta a distribuição centralizada do Web PKI em ambientes corporativos — extensão do Chrome via chave em HKLM e aplicativo nativo via MSI, ambos distribuídos por GPO a partir de um diretório compartilhado. Em servidores RDS novos, esse é o caminho que recomendamos avaliar antes de instalar manualmente a partir de um único perfil de usuário. A documentação não detalha explicitamente em qual hive o Native Messaging Host do aplicativo nativo é registrado nesse fluxo — por isso, mesmo optando pela distribuição via GPO, vale confirmar onde a chave foi criada e testar o funcionamento com um usuário comum antes de considerar o ambiente pronto.

O ponto central deste caso de Web PKI RDS não era liberar Chrome administrativo para os usuários. Era entender por que o Web PKI só aparecia quando o navegador rodava em outro contexto de perfil. Seguindo o caminho Chrome → Native Messaging → Registro → manifesto → executável, a causa ficou clara — e o componente passou a funcionar para todos os usuários do RDS sem transformar ninguém em administrador.

Perguntas frequentes

Por que o Web PKI só funcionava com o Chrome aberto como administrador?
Não é o Chrome que precisa de privilégio elevado — o requisito nunca foi do navegador nem do componente nativo (a própria Lacuna documenta que os componentes “Native App” não exigem privilégios de administrador). Faltava a chave de registro que aponta o Chrome para o executável, presente só no perfil de quem instalou. Rodar como administrador, por coincidência de contexto de perfil, fazia o Chrome enxergar essa chave.

Essa correção funciona em qualquer versão do Web PKI?
O procedimento foi validado na versão 2.16.0.0. A listagem oficial na Chrome Web Store já está em uma versão mais recente — confira a atual antes de aplicar, e valide também que o campo path do native-host-chrome.json continua relativo, já que é isso que viabiliza mover a pasta sem editar nada dentro dela.

Preciso reinstalar o Web PKI em cada usuário do RDS depois dessa correção?
Não. A chave em HKLM é lida por qualquer usuário que logar na máquina, atual ou futuro — não é por perfil.

Esse mesmo problema pode acontecer com outros conectores de certificado digital?
A arquitetura de registro HKCU/HKLM é do Native Messaging do Chrome, documentada oficialmente — não é exclusiva do Web PKI. Se outro conector (driver de token A3, outro middleware de assinatura) tiver o mesmo sintoma em RDS, vale checar a mesma chave em NativeMessagingHosts. O nome da chave e o caminho do manifesto mudam de produto para produto — confirme os valores específicos antes de aplicar o mesmo procedimento.

Fontes técnicas

Chrome for Developers — Native messaging (mecanismo de registro HKCU/HKLM e comunicação stdio do Native Messaging Host).

Microsoft Learn — comando change user (comportamento de sombreamento de registro em modo /install).

Lacuna Software — Atributos de Segurança do Web PKI (componentes nativos não exigem privilégio de administrador).

Lacuna Software — Instalação e distribuição do Web PKI via GPO.

Chrome Web Store — listagem oficial do Web PKI (base de usuários, número dinâmico consultado nesta publicação).

Veja também: Erro PJeOffice Indisponível: causa real e solução, outro caso real de navegador bloqueando a integração local com certificado digital.

Precisa de apoio especializado em um ambiente RDS/Terminal Server empresarial? Conheça o suporte gerenciado da Thompsontech.