CA raiz do Windows Server 2003 - o que pode fazer com que o certificado da CA raiz seja atualizado?

2

Estou me referindo especificamente a uma CA Raiz auto-criada em nosso controlador de domínio (Windows Server 2003 SP2) em que todos os nossos clientes de domínio confiam para uso interno, não para a CA raiz do GoDaddy, Verisign, etc. Talvez haja uma relação entre eles.

Eu testemunhei a atualização duas vezes no último ano. Eu gostaria de entender quais circunstâncias fazem com que ele seja atualizado, além da expiração ... Eu verifiquei, e em nenhum dos dois casos foi para a expiração, que ainda está um ano fora.

Como eu observei isso? Essa CA também é usada para clientes LDAPS - quando o certificado muda, eles param de funcionar - mais especificamente, o Apache2 mod_ldap ldaps: // auth quebra quando isso acontece, até que o controlador de domínio (também a CA Raiz) seja reinicializado. Quando o servidor for reinicializado, os clientes Java LDAPS: // então deixarão de funcionar e buscar novamente o certificado raiz da CA resolverá o problema, mas antes da reinicialização, os clientes Java ficarão perfeitamente satisfeitos e somente o Apache deixará de funcionar.

Estou apenas procurando entender o que as coisas podem fazer com que um certificado da CA raiz do Windows Server 2003 seja atualizado. Este servidor é muito antigo (implantado há quase 7 anos) e está sendo desativado enquanto falamos (é difícil destruir o sistema!). Vários serviços (RADIUS, Spooler de Impressão, etc) deixam de funcionar corretamente após 2-3 meses de atividade, então estou quase tentado a escrevê-lo para isso ...

  • As atualizações do Windows causam isso?
  • Atualizações na lista do Windows de CA Confiáveis fazem com que esse certificado seja atualizado? (existe uma relação?)
  • Outras razões?

UPDATE : Sintoma real de falha na autenticação LDAPS do Java até que seu certificado seja atualizado (certificado raiz da CA ou LDAP - ainda determinando ...):

sun.security.validator.ValidatorException: falha na criação do caminho PKIX: sun.security.provider.certpath.SunCertPathBuilderException: não foi possível encontrar o caminho de certificação válido para o destino solicitado

Mais esclarecimentos: O cliente Java LDAPS está em um servidor Linux que NÃO é membro do domínio, mas é encapsulado em nossa rede privada. O Apache está em um servidor Windows que é membro do domínio.

    
por Joshua McKinnon 19.05.2011 / 02:10

2 respostas

3

O certificado realmente atualiza? Ele cria um novo certificado raiz com um novo hash, nova data de validade, etc? Ou apenas o problema observado "quebrado até reinicializar"?

Meu palpite sobre esse problema é que o registro automático não está acontecendo para o controlador de domínio para o qual os clientes LDAP / S estão apontando. Lembre-se de que o certificado usado para o LDAP / S é um certificado Domain Controller ou Kerberos Authentication . Eles serão inscritos automaticamente por cada controlador de domínio e serão renovados em sua programação de renovação padrão. Faça check-in no snap-in Certificados no controlador de domínio para ver quando ele expirará e planeje de acordo.

Esta falha no registro pode ser por vários motivos, incluindo uma configuração incorreta no modelo de certificado ou na própria autoridade de certificação (não permitindo registro automático), problemas com a publicação da CRL ou simplesmente uma falha de serviço como os serviços RADIUS e de spool.

A primeira coisa a verificar é o snap-in Enterprise PKI MMC, pkiview.msc. Ele informará se há um serviço com falha ou se uma CRL não foi atualizada ou qualquer outra coisa que esteja causando um problema na cadeia de confiança.

    
por 19.05.2011 / 02:39
0

A única coisa em que consigo pensar é que a permissão foi atribuída para que o CA Server se inscrevesse automaticamente (e se registrasse automaticamente), e o GP habilitou o registro automático. Eu teria que olhar para um servidor para ter certeza.

    
por 19.05.2011 / 02:36