Microsoft IIS: por que alguns clientes veem "certificado não confiável" e como resolver
Em servidores Microsoft IIS (Windows/SChannel), a cadeia de certificados enviada no handshake TLS é escolhida automaticamente com base no repositório de raízes confiáveis da máquina. Quando as raízes novas Sectigo Public Root R46/E46 estão confiáveis no servidor, a cadeia tende a finalizar nelas. Clientes atualizados confiam nessa cadeia; já clientes legados podem falhar, mesmo existindo cadeias cruzadas (cross-certificates) que permitiriam encerrar em USERTrust RSA/ECC, mais difundidas.
O IIS não permite escolher manualmente a cadeia a ser enviada. A Microsoft trata esse comportamento como “by design” e documenta alternativas em sua base de conhecimento:
https://learn.microsoft.com/pt-br/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails
Objetivo da correção
Forçar o servidor a não usar R46/E46 ao montar a cadeia do certificado servido pelo IIS, induzindo o Windows a usar a cadeia cruzada que converge para USERTrust RSA/ECC, ampliando a compatibilidade com clientes antigos sem prejudicar clientes novos.
Método recomendado (arquivos .reg)
Disponibilizamos dois arquivos .reg:
- Aplicar correção:
IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg
Move as raízes Sectigo Public Root R46 e Sectigo Public Root E46 para o repositório Disallowed/Untrusted (computador local), evitando que o servidor as use para montar a cadeia enviada.
- Reverter (se necessário):
IISFix-MoveSectigoSelfSignedRoots-Restore.reg
Restaura as raízes ao estado anterior.
Observação: essa alteração afeta a seleção de cadeia do servidor. Os clientes continuam validando com seus próprios repositórios de confiança.
ATENÇÃO: Antes de aplicar, faça backup/ponto de restauração do servidor.
Passo a passo (utilizando o .reg)
- Importar o .reg (como Administrador)
• Duplo clique em IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg e confirme
ou
• Prompt elevado:
reg import IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg
- Reiniciar serviços
iisreset /restart
Se a cadeia antiga persistir, considere reiniciar o serviço Cryptographic Services ou o próprio servidor para limpar cache de cadeia.
- Validar em uma máquina externa:
openssl s_client -connect seu-dominio:443 -showcerts
Verifique se a cadeia agora utiliza os cross-certs que encerram em USERTrust RSA/ECC (em vez de R46/E46).
- Testar nos clientes alvo
Acesse com os clientes legados que antes falhavam e confirme a confiança.
Reversão
reg import IISFix-MoveSectigoSelfSignedRoots-Restore.reg
iisreset /restart
Alternativa manual (sem .reg)
-
Executar mmc.exe
- Adicionar snap-in “Certificates (Local Computer)”
- Ir em “Untrusted Certificates” > “Certificates”
- Importar as raízes Sectigo Public Root R46 e Sectigo Public Root E46 nesse repositório
- Reiniciar o IIS e validar a cadeia.
Perguntas frequentes
-
• Isso reduz segurança?
Não. A mudança orienta apenas qual cadeia o servidor envia. Os clientes continuam seguindo suas próprias âncoras de confiança.
- • Posso remover R46/E46 do “Trusted Root”?
Mover para Disallowed é mais explícito e eficaz para forçar a seleção da cadeia cruzada adequada.
- • Devo desabilitar “Windows Automatic Root Updates”?
Não recomendado de forma geral, pois pode reduzir a segurança e a compatibilidade do Windows.
Quando usar este procedimento
-
• O site funciona em clientes modernos, mas falha em clientes antigos.
- • Não há como alterar manualmente a cadeia no IIS/SChannel.
- • É necessária compatibilidade ampla enquanto as novas raízes não estão presentes em todo o ecossistema.
Anexos
• IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg — 03/09/2025
• IISFix-MoveSectigoSelfSignedRoots-Restore.reg — 03/09/2025
