Guia prático e completo para migrar sua Autoridade de Certificação do Windows Server 2012 R2 para 2019 (ou posterior) com segurança, mantendo a mesma identidade da CA, sem quebrar a cadeia de confiança e com plano de rollback simples.
Visão geral e decisões que importam
Quando o assunto é Public Key Infrastructure (PKI) corporativa, cada detalhe conta. O objetivo aqui é mover o serviço Active Directory Certificate Services (AD CS) do servidor de origem para um servidor de destino mais novo, evitando indisponibilidade, mantendo políticas e modelos de certificado e preservando a confiança dos clientes. A abordagem consagrada é a migração lado‑a‑lado, isto é, instalação limpa no novo Windows Server e transferência metódica da Autoridade de Certificação (CA) e de seus pontos de distribuição.
| Decisão‑chave | Motivo | Observações práticas |
|---|---|---|
| Realizar migração lado‑a‑lado, não atualização in‑place | Instalação limpa reduz risco de corrupção, facilita rollback e evita arrastar problemas do sistema antigo. | Suba um novo Windows Server e transfira a CA usando backup e restauração oficiais do AD CS. |
| Manter o mesmo nome da CA; hostname do servidor pode mudar | O nome lógico da CA é gravado em todos os certificados emitidos. Alterá‑lo quebra a cadeia. | O servidor pode ter hostname novo, desde que CRL e AIA antigos e novos permaneçam publicados durante a transição. |
| Seguir o procedimento oficial de mudança de servidor | Evita lacunas de configuração e garante restauração suportada pela Microsoft. | Passos incluem backup do banco, chaves, registro e restauração assistida no destino. |
Arquitetura e nomenclatura da autoridade
Nome da CA é a identidade da Autoridade de Certificação (ex.: CONTOSO‑Issuing‑CA) e precisa permanecer idêntico. Hostname do servidor é o nome de máquina do Windows (ex.: SRV‑PKI‑02) e pode mudar sem afetar a confiança, desde que os pontos de distribuição da CRL e os locais AIA continuem válidos para os certificados já emitidos.
O mesmo procedimento vale para diferentes perfis de CA:
- CA raiz offline: geralmente fora do domínio e desligada; a cópia de chaves e a republicação do certificado raiz/CRL são cruciais.
- CA subordinada empresarial: unida ao domínio; garante publicação no Active Directory e integração com autoinscrição via GPO.
- Funcionalidades adicionais: NDES, Inscrição via Web e APIs de terceiros exigem reapontamentos e testes dedicados.
Pré‑requisitos e preparação
Antes de tocar na produção, valide em laboratório. Em seguida, confirme os pré‑requisitos abaixo.
| Item | Detalhe | Comprovação |
|---|---|---|
| Acesso | Conta com direitos de Administrador local e permissões de gerenciamento da CA. | Abrir certsrv.msc e listar propriedades. |
| Backup | Banco da CA, logs de transação, chave privada e certificado da CA em PFX com senha forte. | Assistente de backup do console da CA e cópia verificada do PFX. |
| Registro | Exportar HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration | Arquivo .reg em cofre. |
| CRL e AIA | Inventariar locais atuais de CDP/AIA (HTTP, LDAP, file share), inclusive permissões. | Captura de tela e exportação das extensões. |
| Templates | Lista de modelos publicados e ACLs de emissão. | MMC certsrv.msc → Certificate Templates. |
| Janela | Planejar sobreposição de CRL para cobrir o período de migração. | Configurar CRL Overlap e publicar previamente. |
| Rede | Portas e DNS prontos no destino (RPC/DCOM, LDAP/GC, SMB, HTTP/HTTPS para CRL/AIA). | Teste com Test‑NetConnection e validação de DNS/CNAME. |
| Antivírus | Exceções para diretórios do banco e logs da CA. | Pastas %windir%\System32\CertLog e CertSrv. |
Planejamento de revogação e continuidade
Para evitar falhas de verificação durante a migração, publique CRLs com folga e ative sobreposição:
certutil -setreg CA\CRLOverlapUnits 12
certutil -setreg CA\CRLOverlapPeriod "Hours"
net stop certsvc && net start certsvc
certutil -crl
Se usar Delta CRL, garanta que o período de delta cubra a janela. Publique CRL antecipada no servidor antigo e copie para os mesmos pontos de distribuição no novo servidor, se for reciclar paths.
Backup completo no servidor de origem
- Abrir Autoridade de Certificação → clique direito no nome da CA → Fazer backup.
- Selecione Private key and CA certificate e Certificate database and log. Proteja o PFX com senha forte.
- Exporte o registro:
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" C:\Backup\CA-Config.reg /y - Liste extensões CDP/AIA atuais para conferência posterior.
certutil -getreg CA\CRLPublicationURLs certutil -getreg CA\CACertPublicationURLs - Se houver CAPolicy.inf no sistema, copie‑o (pode estar em
%windir%). - Opcional: pausar novas emissões por curto período (ex.: despublicar templates temporariamente) para manter o estado estável durante a cópia.
Provisionamento do novo servidor
- Unir o servidor ao mesmo domínio da CA subordinada (se aplicável). Atualize o sistema e sincronize horário.
- Crie as pastas de dados:
mkdir D:\ADCS\DB mkdir D:\ADCS\Log mkdir D:\ADCS\CertEnroll - Instalar a função Active Directory Certificate Services com o mesmo papel que existia (raiz, subordinada, corporativa ou autônoma). Não selecione componentes desnecessários.
- Na configuração pós‑instalação, escolha Usar certificado e chave privada existentes e aponte para o PFX exportado.
- Defina os caminhos do banco e dos logs para os diretórios criados (precisam existir antes da restauração).
- Se a CA usar HSM, instale o driver/provedor (CSP/KSP) do fabricante e importe a chave com a ferramenta apropriada antes de prosseguir.
Restauração e alinhamento de configuração
- No console da CA, execute Restore CA e selecione Private key and CA certificate e Certificate database and log.
- Importe o arquivo de registro:
reg import C:\Backup\CA-Config.reg - Recrie paths de publicação usados anteriormente (pastas, compartilhamentos, permissões NTFS/SMB).
- Confirme as extensões CDP/AIA e ajuste, se necessário. Exemplo típico:
CDP HTTP: http://pki.contoso.com/pki/<CaName><CRLNameSuffix>.crl CDP LDAP: ldap:///CN=<CATruncatedName>,CN=<CaName>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base AIA HTTP: http://pki.contoso.com/pki/<ServerDNSName>_<CaName>.crt - Republique o certificado da CA e CRLs no AD quando aplicável:
certutil -dspublish -f "C:\Backup\CA.cer" certutil -dspublish -f "C:\Backup\CA.cer" NTAuthCA
Publicação de listas de revogação
- Gerar CRL e delta CRL no novo servidor:
certutil -crl - Verificar se os endpoints antigos e novos estão servindo as CRLs. Durante a transição, mantenha ambas as localizações ativas para que clientes com certificados antigos consigam baixar a CRL referenciada.
- Para endpoints HTTP, considere usar DNS CNAME e redirecionamento controlado (ex.: pki.contoso.com) para simplificar a continuidade.
Hostname igual ou diferente
Ambas as estratégias são válidas. Escolha com base em seu padrão de gestão de nomes e em restrições de DNS/segurança.
| Estratégia | Como fazer | Riscos e mitigação |
|---|---|---|
| Reaproveitar o mesmo hostname do servidor | Desligar o servidor antigo, remover do AD/DNS, juntar o hostname ao novo servidor, atualizar registros A/CNAME. | Janela de corte curta. Garanta que CRL/AIA sejam publicados antes de reativar o serviço. |
| Hostname novo para o servidor | Manter a identidade da CA idêntica, mas usar nome de máquina diferente. Publicar CRL/AIA nos locais antigos e também nos novos. | Clientes antigos continuarão buscando CRL no caminho antigo; mantenha publicação dupla até a expiração desses certificados. |
Validação pós‑migração
- Emitir um certificado de teste e validar a cadeia:
certutil -verify -urlfetch teste.cer - Testar conectividade do serviço:
certutil -ping -config "SRV-PKI-02\CONTOSO-Issuing-CA" - Confirmar autoinscrição em estações por GPO:
gpupdate /force certutil -pulse - Monitorar o Visualizador de Eventos → Applications and Services Logs → Microsoft → Windows → CertificateServices*.
- Checar publicação no AD e cache de CRL:
certutil -url <endereco-do-certificado-da-CA-ou-CRL>
Plano de rollback simples
- Parar o serviço no novo servidor:
net stop certsvc. - Restaurar a publicação de CRL/AIA para o servidor antigo.
- Reativar o serviço no servidor antigo:
net start certsvc.
Como não há alteração no nome lógico da CA, o retorno é imediato, desde que os pontos de distribuição permaneçam válidos.
Boas práticas e modernização
- Criptografia atual: use SHA‑256 e RSA 2048 bits ou superior. Avalie CNG e ECDSA em ambientes modernos, considerando compatibilidade.
- Renovação da CA: se o certificado da CA estiver perto do vencimento, planeje a renovação “com a mesma chave” para reduzir impacto, ou com chave nova se a política exigir.
- Templates: mantenha apenas os modelos em uso. Utilize Superseded Templates para forçar renovação automática controlada.
- Auditoria: habilite eventos de emissão, revogação e alteração de configuração.
- Governança: substitua scripts antigos, documente o novo hostname, atualize runbooks e crie rotinas de backup periódico com testes de restauração.
- Serviços auxiliares: se usar NDES/inscrição via Web, reinstale os componentes e reconfigure URLs e certificados de servidor.
Automação de verificação
Alguns comandos úteis para acelerar a checagem:
:: Exportar parâmetros principais
certutil -getreg > C:\Backup\CA-Registry.txt
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
\:: Publicar certificado da CA no AD
certutil -dspublish -f "C:\Backup\CA.cer" NTAuthCA
\:: Publicar CRL manualmente
certutil -crl
\:: Testar cadeia e endpoints
certutil -verify -urlfetch teste.cer
certutil -url "[http://pki.contoso.com/pki/CONTOSO-Issuing-CA.crl](http://pki.contoso.com/pki/CONTOSO-Issuing-CA.crl)" Checklist operacional
Antes
- Backup completo do banco, logs, certificado e chave privada em PFX.
- Exportação do registro da CA.
- Inventário de CDP/AIA e templates.
- CRL publicada com sobreposição adequada.
- Destino preparado, atualizado e com permissões e paths criados.
Durante
- Instalação do papel AD CS no destino usando chave existente.
- Restauração do banco e importação do registro.
- Verificação e ajuste das extensões de CDP/AIA.
- Publicação de CRL e validações iniciais.
Depois
- Testes com certificados de prova e autoinscrição.
- Monitoramento de eventos e de falhas de revogação.
- Manutenção temporária de publicação de CRL nos paths antigos e novos.
- Desativação do servidor antigo quando o ambiente estiver estável.
Perguntas frequentes e problemas comuns
É obrigatório manter o mesmo nome da CA?
Sim. A identidade da CA é parte dos certificados emitidos. Mudar o nome exigiria reemitir toda a hierarquia.
Posso mudar o hostname do servidor?
Sim. Garanta a publicação de CRL/AIA para atender certificados antigos e novos durante a transição. Use CNAMEs para simplificar.
O que acontece com os certificados já emitidos?
Continuam válidos até expirar, porque a CA e seus pontos de distribuição permanecem os mesmos. O cliente confia na mesma cadeia.
E se eu precisar renovar o certificado da CA?
Pode renovar com a mesma chave para menor impacto ou com chave nova conforme política. Planeje a republicação no AD e em AIA.
Como lidar com HSM?
Instale o CSP/KSP do fabricante no novo servidor e importe/associe a chave antes de restaurar a CA. Teste a proteção de chave e operações de assinatura.
Qual a recomendação sobre suporte do sistema antigo?
Ambientes baseados no sistema legado (2012 R2) estão fora de suporte geral há anos. Migrar reduz risco e custo de manutenção estendida.
Tenho web enrollment habilitado, preciso replicar?
Só se ainda houver requisito real. Ambientes modernos preferem autoinscrição por GPO, SCEP/NDES ou APIs de gerenciamento de dispositivos.
Exemplos de configuração de extensões
Abaixo, um exemplo de extensões para cobrir legado e novo hostname durante a transição:
CDP:
http://pki.contoso.com/pki/<CaName><CRLNameSuffix>.crl
http://pki-antigo.contoso.com/pki/<CaName><CRLNameSuffix>.crl (transitório)
AIA:
[http://pki.contoso.com/pki/<ServerDNSName>\<CaName>.crt](http://pki.contoso.com/pki/<ServerDNSName><CaName>.crt)
ldap\:///CN=\,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?base Assim, clientes com certificados antigos ainda conseguem baixar CRL/AIA do endereço anterior, enquanto novos certificados passam a referenciar o endereço consolidado.
Encerramento
Seguindo este playbook, a operação resulta em continuidade total: o inventário de certificados permanece válido, novos pedidos passam a usar a CA no Windows Server moderno, e a confiança dos clientes é preservada porque a identidade da CA e seus pontos de distribuição continuam íntegros. A migração lado‑a‑lado oferece um caminho seguro, reversível e alinhado às melhores práticas.