Renovar CA AD CS e mudar o algoritmo de assinatura de SHA‑1 para SHA‑256 no Windows Server

Guia prático e seguro para renovar o certificado de uma Enterprise Root CA no AD CS e mudar o algoritmo de assinatura de SHA‑1 para SHA‑256 sem interromper serviços. Inclui checklist, comandos, critérios para reutilizar a chave ou gerar nova, testes de validação e plano de reversão.

Índice

Visão geral

É totalmente viável migrar uma autoridade certificadora raiz empresarial de um único nível no Active Directory Certificate Services (AD CS) do algoritmo de assinatura SHA‑1 para SHA‑256. A mudança passa a valer apenas para novos certificados e novas CRLs emitidos após a alteração. Os certificados já emitidos com SHA‑1 não são reemitidos; continuam válidos até expirarem, desde que a cadeia e a revogação permaneçam íntegras.

Para realizar a transição com segurança e previsibilidade, o caminho mais direto é: ajustar o algoritmo de hash preferido da CA para SHA‑256, renovar o certificado da CA (preferencialmente same key, quando suportado), publicar as listas de revogação e distribuir a nova âncora de confiança. Este artigo traz um passo a passo completo, além de tabelas de decisão, comandos testáveis e dicas de monitoramento.

Como funciona a assinatura na CA

O algoritmo de hash empregado pela CA (ex.: SHA‑1 ou SHA‑256) é usado para compor a assinatura digital do certificado e da CRL emitidos pela própria autoridade. Alterar o hash não muda a chave pública da CA quando você renova com a mesma chave; a identidade criptográfica (Subject e SKI) permanece. Se optar por gerar chave nova, você cria uma nova identidade de raiz e precisará distribuir a nova âncora de confiança de forma controlada.

Elemento	O que muda ao adotar SHA‑256	O que permanece
Assinatura de novos certificados	Passa a usar sha256RSA	Sujeitos, extensões e políticas definidas no modelo
CRL e Delta CRL	Novas listas saem assinadas com SHA‑256	CDPs, periodicidade e janelas de validade (se não alteradas)
Certificados já emitidos	Não se alteram	Continuam válidos até o NotAfter
Chave privada da CA	Igual, se renovar com a mesma chave	Algoritmo e tamanho originais (ex.: RSA 2048)

Motivos para abandonar o hash legado

SHA‑1 não atende boas práticas de segurança atuais e sofre com colisões viáveis em cenários de ataque sofisticados.
Sistemas e navegadores modernos priorizam ou exigem SHA‑256 para cadeias de confiança.
Manter uniformidade de assinaturas simplifica auditorias, relatórios de conformidade e integrações.

Pré-requisitos e compatibilidade

Antes de iniciar, confirme que clientes, servidores, appliances e aplicações do ambiente aceitam SHA‑256. A maioria das plataformas compatíveis com AD modernas já suporta SHA‑256 há anos. Equipamentos legados, sistemas sem atualizações e dispositivos embarcados antigos podem apresentar limitações. Se necessário, planeje exceções temporárias e janelas de migração específicas.

Garanta janela de manutenção para a renovação da CA e publicação de CRLs.
Confirme permissões administrativas no servidor da autoridade certificadora.
Assegure espaço em disco para backups e para o diretório de publicação (AIA/CDP).
Se usar HSM, verifique firmware e suporte a SHA‑256 no provedor criptográfico.

Checklist rápido

Compatibilidade com SHA‑256 confirmada.
Ferramenta pkiview.msc sem erros.
Backups do banco e da chave privada concluídos.
Provedor criptográfico com suporte a SHA‑256 (ou plano para chave nova).
Parâmetro de hash ajustado para SHA‑256 e serviço reiniciado.
Certificado da autoridade renovado.
CRL publicada e nova raiz distribuída.
Testes validados e monitoramento ativo.

Fluxo resumido

Avaliar impacto e compatibilidade em sistemas e apps.
Verificar a saúde da PKI pelo pkiview.msc.
Executar backup completo do banco e da chave da CA.
Checar provedor e hash atuais via certutil -getreg CA\CSP.
Ajustar o algoritmo de hash para SHA‑256 no provedor.
Renovar o certificado da CA, preferindo reutilizar a chave quando suportado.
Publicar CRL e distribuir a nova âncora de confiança.
Validar emissões, cadeia e revogação em cenários reais.
Monitorar e, se necessário, executar plano de reversão baseada em backups.

Procedimento detalhado

Avaliação de impacto e compatibilidade

Mapeie serviços críticos: TLS de servidores internos, autenticação baseada em certificados, S/MIME, VPN, clients de banco, impressão segura, IoT e afins. Em ambientes com legados rígidos, reduza risco realizando um ensaio em laboratório com cópias de configuração.

Verificação da saúde da infraestrutura

Abra pkiview.msc no servidor de CA ou em uma estação administrativa. Resolva alertas de publicação AIA/CDP, falhas de CRL, acessos a HTTP/LDAP e erros de permissão. Corrija tudo antes da mudança para evitar diagnósticos confusos posteriormente.

Backup completo da autoridade

Faça backup do banco, da chave privada e das CRLs vigentes. Se possível, armazene uma cópia fora do servidor:

certutil -backupdb C:\BackupCA\DB
certutil -backupKey C:\BackupCA\Key
mkdir C:\BackupCA\CRL
copy %windir%\System32\certsrv\certenroll\*.crl C:\BackupCA\CRL\

Documente o thumbprint do certificado atual da CA e o caminho dos repositórios de publicação (HTTP/LDAP/DFS). Considere um snapshot do servidor, se a política permitir.

Verificação do provedor e do hash

Identifique o provedor criptográfico em uso e o hash atual:

certutil -getreg CA\CSP

Se o provedor for Microsoft Base Cryptographic Provider v1.0 (CSP legado), ele não dá suporte a SHA‑256 para assinar certificados da CA com a mesma chave. Nesse caso, você deverá renovar com nova chave em um provedor compatível, como Microsoft Enhanced RSA and AES Cryptographic Provider ou um KSP/CNG (por exemplo, Microsoft Software Key Storage Provider ou HSM equivalente).

Configuração do novo algoritmo

Defina SHA‑256 como algoritmo de hash da autoridade, respeitando o tipo de provedor:

Para KSP/CNG (chaves CNG)

certutil -setreg CA\CSP\CNGHashAlgorithm SHA256

Para CSP legado

certutil -setreg CA\CSP\HashAlgorithm SHA256

Reinicie o serviço da autoridade para aplicar:

net stop certsvc
net start certsvc

Renovação do certificado da autoridade

Use o console Certification Authority: clique com o botão direito sobre a CA → All Tasks → Renew CA Certificate…. Escolha Same key para manter a continuidade criptográfica quando o provedor suportar SHA‑256. Alternativamente, pela linha de comando:

certutil -renewCert ReuseKeys

Se o provedor atual não suportar SHA‑256, selecione New key e opte por um provedor compatível (Enhanced RSA and AES ou KSP/CNG). Essa opção exige planejamento extra de distribuição de confiança, pois você estará criando uma nova raiz no ambiente.

Publicação de listas de revogação e distribuição da raiz

Após a renovação, publique uma nova CRL (agora assinada com SHA‑256) e distribua o novo certificado raiz conforme a topologia:

certutil -crl

Em ambientes com Active Directory, publique a nova raiz no diretório:

certutil -dspublish -f C:\Caminho\RootCA_SHA256.cer RootCA

Para dispositivos fora do domínio, exporte o certificado e importe manualmente no repositório Trusted Root Certification Authorities. Em larga escala, utilize GPO, MDM ou ferramentas de gerenciamento de configuração.

Validação pós mudança

Emita um certificado de teste e confirme, nos detalhes do certificado ou com a ferramenta de linha de comando, que o algoritmo de assinatura é SHA‑256:

certutil -dump C:\Caminho\cert_teste.cer | findstr /i "Signature Algorithm"

Teste fluxos críticos: negociação TLS entre clientes e servidores internos, autenticação de usuários/dispositivos, S/MIME, VPN e integrações com aplicações. Verifique a validação de revogação (CRL e, se houver, Delta CRL).

Monitoramento e reversão

Acompanhe event logs do serviço certsrv, métricas de publicação (HTTP/LDAP), reclamações de usuários e alarmes de aplicações. Diante de comportamento inesperado, você pode:

Restaurar o banco e a chave a partir dos backups (certutil -restoredb, certutil -restoreKey), se necessário.
Revisitar o parâmetro de hash e renovar novamente a autoridade (não recomendado voltar a SHA‑1, salvo exceções controladas em laboratório).

Impacto em certificados e listas de revogação existentes

Os certificados emitidos antes da migração continuam válidos até expirar, assinados com SHA‑1. A partir da mudança, novos certificados e novas CRLs virão com SHA‑256. Se você renovar com a mesma chave, o Subject Key Identifier permanece, simplificando confiança e evitando múltiplas âncoras de raiz. Se optar por nova chave, haverá duas raízes distintas e você deverá garantir que todos os dispositivos confiem em ambas durante a transição.

Decisão entre mesma chave e nova chave

Cenário	Recomendação	Observações
Provedor atual suporta SHA‑256 e chave com tamanho adequado	Reutilizar a chave	Preserva SKI e reduz impacto operacional
Provedor sem suporte a SHA‑256 ou chaves hospedadas em CSP obsoleto	Gerar nova chave	Migrar para Enhanced RSA and AES ou KSP/CNG; planejar distribuição da nova raiz
Exigência de rotação periódica de chaves por conformidade	Gerar nova chave	Aproveite a mudança para elevar tamanho e fortalecer proteções
Necessidade de padronizar em HSM ou KSP	Gerar nova chave	Alinhar governança de chaves, backup e auditing

Estratégia de distribuição

Para ambientes com diretório, distribua a nova raiz via GPO e publicação no AD, garantindo replicação antes das janelas de maior uso. Em ambientes híbridos, combine GPO, MDM e instalações manuais para clients externos. Verifique se os pontos AIA e CDP (HTTP/LDAP) estão acessíveis a todos os segmentos e, quando necessário, publique cópias em DMZ ou repositórios internos com alta disponibilidade.

Ensaios em laboratório

Monte um laboratório representativo com cópias da configuração de CA e modelos principais. Execute a sequência completa: ajuste do hash, renovação, emissão de certificados de teste, publicação de CRL e validação de cadeia. Incremente com smoke tests de TLS, autenticação e line of business. Valide também o tempo de propagação de GPO e a acessibilidade dos repositórios.

Comandos úteis de verificação

Para consultar o estado do provedor e hash configurados:

certutil -getreg CA\CSP

Para confirmar o algoritmo de assinatura do certificado da autoridade:

certutil -dump &quot;C:\Windows\System32\certsrv\certenroll\NomeDaCA.crt&quot; | findstr /i &quot;Signature Algorithm&quot;

Para listar certificados no repositório da autoridade no servidor:

certutil -store CA

Em PowerShell, uma verificação rápida do algoritmo de assinatura dos certificados da autoridade local:

Get-ChildItem Cert:\LocalMachine\CA |
  Select-Object Subject, Thumbprint,
                @{n='Assinatura';e={$_.SignatureAlgorithm.FriendlyName}},
                NotBefore, NotAfter

Erros frequentes e correções

Mensagem ou código	Causa provável	Como corrigir
NTEBADALGID ou erro ao renovar	Provedor da chave não suporta SHA‑256	Migrar para Enhanced RSA and AES ou KSP/CNG e renovar com nova chave
Falha ao publicar CRL	Permissões ou caminho CDP/AIA inválido	Corrigir ACLs e caminhos de publicação; republish com `certutil -crl`
Cadeia inválida em dispositivos	Nova raiz não distribuída ou cache desatualizado	Distribuir via GPO/MDM; limpar cache e reiniciar serviços
Aplicação rejeita certificados novos	Dependência em SHA‑1 hardcoded	Atualizar aplicação; em último caso, exceção temporária enquanto migra

Boas práticas

Se a chave da autoridade tiver tamanho inferior ao recomendado, avalie a rotação com chave nova aproveitando a migração para SHA‑256.
Evite janelas longas sem CRL nova após a renovação; publique e valide distribuição imediatamente.
Documente o procedimento e capture hashes, thumbprints, versões de provedor e prints do pkiview.msc.
Automatize verificações periódicas de integridade dos repositórios AIA e CDP.

Resumo final

Migrar a assinatura de uma autoridade certificadora empresarial de SHA‑1 para SHA‑256 é direto quando o provedor da chave suporta o novo hash: ajuste o parâmetro, renove same key, publique CRL, distribua a raiz e valide. Se o provedor não suportar, renove com chave nova em um provedor moderno e execute um plano de distribuição cuidadoso. Com backups, validações objetivas e comunicação clara, a transição ocorre sem impacto perceptível para usuários e aplicações.

Passo a passo completo

Avaliar impacto e compatibilidade
Confirme o suporte a SHA‑256 em sistemas, apps e dispositivos, priorizando itens legados em que você suspeita de limitações.
Verificar saúde da PKI
Abra pkiview.msc e garanta que CA, CRLs, pontos de distribuição e publicações apareçam sem erros.
Backup completo da CA
Execute: certutil -backupdb C:\BackupCA\DB certutil -backupKey C:\BackupCA\Key Armazene também as CRLs vigentes.
Checar provedor e hash atual
Use: certutil -getreg CA\CSP Se o provedor não suportar SHA‑256 (ex.: Base v1.0), planeje new key em provedor compatível (Enhanced RSA and AES ou KSP/CNG).
Configurar SHA‑256 como hash
KSP/CNG: certutil -setreg CA\CSP\CNGHashAlgorithm SHA256 CSP: certutil -setreg CA\CSP\HashAlgorithm SHA256 Reinicie o serviço: net stop certsvc & net start certsvc
Renovar o certificado da CA
GUI: Certification Authority → All Tasks → Renew CA Certificate… → Same key quando suportado.
CLI: certutil -renewCert ReuseKeys Se precisar de new key, selecione um provedor compatível e prepare a distribuição da nova raiz.
Publicar CRL e distribuir a nova raiz
certutil -crl certutil -dspublish -f C:\Caminho\RootCA_SHA256.cer RootCA Em dispositivos fora do domínio, importe manualmente no repositório de raízes confiáveis.
Validar emissão e confiança
Emita um certificado de teste e verifique Signature algorithm = SHA‑256 (MMC → Detalhes ou certutil -dump). Teste TLS, S/MIME, VPN e autenticação.
Monitorar e, se necessário, reverter
Monitore logs e feedback. Em último caso, use os backups para restaurar o estado anterior.

Tabela de referência rápida

Ação	Comando	Finalidade
Ver estado do provedor	`certutil -getreg CA\CSP`	Confere provedor e parâmetros de hash
Definir hash para SHA‑256 em KSP	`certutil -setreg CA\CSP\CNGHashAlgorithm SHA256`	Ajusta algoritmo em CNG
Definir hash para SHA‑256 em CSP	`certutil -setreg CA\CSP\HashAlgorithm SHA256`	Ajusta algoritmo em CSP legado
Reiniciar o serviço	`net stop certsvc & net start certsvc`	Aplica parâmetros
Renovar mantendo a chave	`certutil -renewCert ReuseKeys`	Gera novo certificado da autoridade com SHA‑256
Publicar CRL	`certutil -crl`	Emite e publica CRL atualizada
Publicar raiz no diretório	`certutil -dspublish -f <arquivo.cer> RootCA`	Distribui a nova âncora de confiança via AD

Seguindo este roteiro, sua autoridade certificadora empresarial passará a assinar com SHA‑256 de forma controlada, consistente e alinhada às melhores práticas de segurança, sem exigir reemissão massiva de certificados já emitidos e com mínimo risco operacional.