PKIView com erro após migrar CA no Windows Server: ajuste de AIA/CDP, limpeza no AD e renovação da CA (guia completo)

Após migrar a sua Autoridade Certificadora (AD CS) para um novo servidor, o PKIView pode exibir erros porque entradas de AIA/CDP ainda apontam para o host antigo. Este guia mostra como ajustar extensões, limpar resíduos no AD, renovar a CA e normalizar o Enterprise PKI de ponta a ponta.

Índice

Visão geral e contexto

Mudar a CA de servidor (alterando o nome do host) não altera o nome lógico da CA nem a sua chave. Porém, as referências de publicação — AIA (Authority Information Access, onde clientes obtêm a cadeia da CA) e CDP (CRL Distribution Point, onde clientes obtêm CRL/Delta CRL) — frequentemente permanecem com URLs do servidor antigo. Isso provoca alertas no PKIView, falhas de validação de cadeia e erros de download de CRL.

No caso relatado, a correção veio ao renovar o certificado da CA após ajustar as extensões. A renovação republicou metadados nos locais corretos e o PKIView ficou verde. O sufixo “(1)” que aparece no certificado da CA indica apenas a nova instância do certificado no repositório (nova versão), não muda o nome do serviço ou causa problemas por si.

Sintomas típicos no PKIView

Entradas de AIA/CDP em vermelho ou amarelo, apontando para URLs do servidor antigo.
Mensagens de “Unable to download CRL/Delta CRL”, “Authority Information Access location error” ou “Cannot build a chain to a trusted root”.
Datas de publicação/expiração inconsistentes (CRL expirada ou próxima de expirar).
Objetos duplicados ou órfãos em CN=Public Key Services no Active Directory.

Causa raiz mais provável

Extensões de AIA e CDP da CA ainda contendo caminhos HTTP/LDAP/arquivo do servidor antigo.
Resíduos de objetos da CA anterior no AD (AIA, CDP, Enrollment Services, Certification Authorities), confundindo clientes e o PKIView.
Publicação de CRL/Delta CRL falhando por permissões ou por apontar para diretórios não mais existentes.

Plano de correção recomendado

Revisar e corrigir AIA/CDP nas propriedades da CA.
Limpar resíduos no Active Directory em CN=Public Key Services.
Renovar o certificado da CA (após ajustes) e reiniciar o serviço.
Publicar CRLs e confirmar acessos.
Validar tudo no PKIView e com certutil.

Mapa rápido de onde corrigir e o impacto

Onde ajustar	O que verificar	Ferramenta	Efeito esperado
Extensões AIA	Remover URLs do host antigo; manter HTTP/LDAP válidos	`certsrv.msc → Propriedades → Extensões`	Clientes baixam a cadeia da CA no novo servidor
Extensões CDP	Remover URLs antigos; garantir publicação de CRL/Delta CRL	`certsrv.msc`	Clientes baixam CRL/Delta CRL atualizadas
Objetos AIA/CDP no AD	Excluir objetos que apontam para a CA antiga	`adsiedit.msc`	Metadados limpos e consistentes no diretório
Renovação da CA	Renovar após ajustar extensões; reiniciar serviço	`certsrv.msc`	Republicação de AIA/CDP com referências corretas
Publicação de CRL	Forçar publicação e verificar acessibilidade	`certutil -crl`	PKIView verde e validação de revogação ok

Passo a passo detalhado

Revisar e corrigir AIA/CDP na CA

Abra certsrv.msc, clique com o botão direito na sua CA → Propriedades → guia Extensões.
Em AIA:
- Remova entradas HTTP/LDAP/arquivo que mencionem o nome do servidor antigo.
- Garanta que existam apenas caminhos válidos, por exemplo (exemplos genéricos):
  - HTTP: pki.seudominio/CertEnroll/<variáveis padrão>
  - LDAP: CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=seudominio,DC=com
- Mantenha marcadas as opções de publicação adequadas (ex.: “Publicar o certificado da CA em AD”).
Em CDP:
- Remova entradas que referenciam o host anterior ou caminhos de arquivo antigos.
- Valide que as opções de publicação para CRL e Delta CRL estão marcadas nos locais corretos (HTTP/LDAP).
- Confirme que o diretório local (ex.: C:\Windows\System32\CertSrv\CertEnroll) existe e tem permissões para a conta do serviço da CA.
Não altere manualmente as variáveis automáticas (%1, %3, %8, %9) a menos que saiba exatamente o efeito. Em geral, preserve os padrões e apenas troque o host/caminho base.

Limpar resíduos no Active Directory

Abra adsiedit.msc e navegue até:

CN=Public Key Services, CN=Services, CN=Configuration, DC=SeuDominio, DC=com

Verifique e limpe objetos em:
- AIA – certificados de CA publicados.
- CDP – CRLs publicadas (inclui Delta CRL se usada).
- Enrollment Services – instâncias de CA Enterprise.
- Certification Authorities – autoridades confiáveis.
Exclua apenas os objetos que claramente apontam para o servidor antigo. Em ambientes críticos, exporte um LDIF de backup antes.

Renovar o certificado da CA e reiniciar o serviço

No certsrv.msc, selecione a CA → All Tasks → Renew CA Certificate.
Escolha se renova com a mesma chave (mais simples, mantém a âncora de confiança) ou com nova chave (rotação planejada, requer atenção à cadeia e publicação). Para a maioria dos cenários de correção de AIA/CDP, renovar com a mesma chave é suficiente.
Ao concluir, reinicie o serviço da CA.
Resultado esperado: os metadados (AIA/CDP) serão republicados conforme as extensões atualizadas. O PKIView deve refletir os novos locais.
Sobre o sufixo “(1)”: é apenas a nova instância do certificado da CA no repositório (ou seja, a segunda emissão do mesmo nome). Não altera o nome do serviço nem é um erro.

Publicar CRL/Delta CRL e validar acessos

certutil -crl

Garanta que a CRL e, se aplicável, a Delta CRL foram copiadas para os mesmos destinos anunciados em CDP (HTTP/LDAP).
Teste o download direto das URLs configuradas (em um navegador ou via Invoke-WebRequest) a partir de um workstation comum do domínio.

Validar com Enterprise PKI (PKIView)

Abra pkiview.msc.
Confirme:
- Não há mais referências ao nome antigo do servidor.
- Todos os itens AIA/CDP/CRL/Delta CRL aparecem em verde.
- Datas de Next Publish e Expiration são razoáveis para a sua política.

Exemplos práticos de configuração de AIA/CDP

AIA típicos (exemplos genéricos; preserve as variáveis padrão):

HTTP: pki.seudominio/CertEnroll/&lt;variáveis padrão&gt;
LDAP: CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=seudominio,DC=com

CDP típicos:

HTTP: pki.seudominio/CertEnroll/&lt;variáveis padrão&gt;.crl
LDAP: CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=seudominio,DC=com

Mantenha apenas os caminhos efetivamente utilizáveis e remova qualquer entrada herdada do servidor antigo.

Parâmetros de publicação e prazos de CRL

Ajuste períodos e sobreposição para evitar “janelas de falha” em que a CRL expira antes da próxima publicação. Alguns comandos úteis:

rem Ver caminhos de publicação e extensões
certutil -getreg ca\CACertPublicationURLs
certutil -getreg ca\CRLPublicationURLs

rem Forçar publicação imediata de CRL
certutil -crl

Considere configurar um tempo de sobreposição (overlap) suficiente para CRL/Delta CRL, de modo que a próxima CRL seja publicada antes da atual expirar. Planeje agendamentos (Tarefas Agendadas) para publicar CRL com folga.

Checklist de validação no PKIView

AIA aponta para o novo servidor e para o AD (se usado): OK.
CDP contém apenas caminhos válidos: OK.
CRL e Delta CRL acessíveis via HTTP e via LDAP: OK.
Sem objetos duplicados/órfãos em CN=Public Key Services: OK.
“CA Certificate validity” e “CRL validity” em verde, com prazos confortáveis: OK.

Erros comuns no PKIView e como corrigir

Erro/Alerta	Causa provável	Correção
Unable to download CRL	CDP aponta para host antigo ou pasta inacessível	Atualize CDP; publique CRL; verifique permissões e conectividade
Delta CRL not found	Opção de publicar Delta CRL marcada, mas arquivo não publicado	Habilite/ajuste publicação ou desmarque se não usar Delta CRL
Authority Information Access location error	AIA tem URL inválida ou objeto antigo no AD	Corrija AIA nas extensões e limpe objetos em AIA no AD
Cannot build a chain to a trusted root	Cadeia incompleta no AIA; certificado da CA não publicado	Publique/valide o certificado da CA em AIA e em AD
CRL expired or about to expire	Agendamento falhou; falta sobreposição	Publicar CRL com `certutil -crl` e ajustar prazos/overlap

Boas práticas para migração de CA

Ordem segura: Ajuste AIA/CDP → Limpe AD → Renove CA → Publique CRL → Valide no PKIView.
HTTP + LDAP: Mantenha ambos, garantindo que o local HTTP esteja publicamente acessível internamente (sem proxies obrigatórios que quebrem o download).
Permissões: A conta do serviço da CA precisa gravar no diretório de publicação local/compartilhado.
Documentação: Registre os novos URLs de AIA/CDP, janela de CRL, data da renovação e quem aprovou a mudança.
Monitoramento: Alarme para expiração de CRL e falhas de publicação.
Compatibilidade: Mesmo sem clientes ativos, mantenha CRLs acessíveis para evitar falhas futuras.

Perguntas frequentes

Renovar a CA novamente resolve?
Resolverá se e somente se as extensões de AIA/CDP estiverem corretas antes da renovação. A renovação usa as extensões atuais para republicar metadados. Ajuste primeiro, renove depois.

O sufixo “CA(1)” é um problema?
Não. Ele indica uma nova instância/versão do certificado da CA (por exemplo, após renovação). Não altera o nome do serviço nem quebra clientes.

Posso renomear a CA?
Renomear o servidor é diferente de renomear a CA. O nome da CA é parte do certificado emitido e não deve ser alterado fora de um processo de migração/rotação adequado. O caminho correto é ajustar AIA/CDP e publicar novamente.

Devo renovar com a mesma chave?
Para ajustes de publicação, renovar com a mesma chave reduz impacto. Rotações de chave exigem planejamento de cadeia e, possivelmente, certificados cruzados.

E se eu uso CA raiz offline?
Mantenha a publicação HTTP/LDAP dos certificados/CRLs da raiz em repositórios acessíveis. Para a raiz offline, publique manualmente quando necessário.

Troubleshooting complementar

Ver o que o cliente está tentando baixar: certutil -url <certificado do emissor ou CRL>
Verificar cadeia e URLs: certutil -verify -urlfetch <certificado do usuário/servidor>
Limpar cache de CRL local para novos testes: certutil -urlcache * delete
Logs: cheque Event Viewer → Applications and Services Logs → CertificationAuthority.

Fluxo recomendado de migração consistente

Planeje os novos destinos HTTP/LDAP e permissões.
Migre a CA para o novo host (mantendo nome lógico e chave conforme estratégia).
Ajuste AIA/CDP nas extensões e remova entradas antigas.
Limpe objetos AIA/CDP/Enrollment Services antigos no AD.
Renove o certificado da CA e reinicie o serviço.
Publique CRL/Delta CRL e teste acessos.
Valide no PKIView e com certutil.
Implemente monitoramento e documentação.

Exemplo de rotina pós-ajuste

rem Checar extensões
certutil -getreg ca\CACertPublicationURLs
certutil -getreg ca\CRLPublicationURLs

rem Renovar a CA (após validar extensões)
rem (A ação de renovação é feita na console da CA)

rem Forçar publicação de CRL imediatamente
certutil -crl

rem Validar cadeia e download de CRL/AIA
certutil -verify -urlfetch \

Resumo do caso real

O PKIView indicava erros após a migração porque AIA/CDP ainda referenciavam o servidor antigo e havia resíduos no AD. Depois de ajustar as extensões e renovar o certificado da CA, o serviço republicou as informações nos locais corretos e o PKIView normalizou imediatamente.

Conclusão

Quando a CA é movida para um novo servidor, o componente crítico é onde os clientes buscam certificados e CRLs. Alinhe AIA/CDP com os novos destinos, limpe objetos antigos no AD e então renove a CA para forçar a republicação. Valide com o PKIView e certutil. Seguindo esse fluxo, sua PKI volta a operar de forma íntegra e previsível.

Comandos úteis (referência rápida)

certutil -getreg ca\CACertPublicationURLs
certutil -getreg ca\CRLPublicationURLs
certutil -crl
certutil -urlcache * delete
certutil -verify -urlfetch &lt;certificado.cer&gt;

Estruturas do Active Directory para revisar

CN=Public Key Services, CN=Services, CN=Configuration, DC=SeuDominio, DC=com
  ├─ AIA
  ├─ CDP
  ├─ Enrollment Services
  └─ Certification Authorities

Revise cuidadosamente cada container e remova apenas as entradas que apontam explicitamente para o servidor antigo.