Windows Server 2003 Root CA – what can cause root CA cert to update

certificate-authoritywindows-server-2003

I am specifically referring to a self-created Root CA on our domain controller (Windows Server 2003 SP2) that all our domain clients trust for internal use, not GoDaddy, Verisign, etc Root CA. Maybe there is a relation between them.

I've witnessed it updating twice in the last year or so. I'd like to understand what circumstances cause it to update, aside from expiration… I've checked, and in neither case was it up for expiration, that is still a year out.

How did I observe this? This CA is also used for LDAPS clients – when the cert changes, they cease working – more specifically, Apache2 mod_ldap ldaps:// auth breaks when this happens, until the domain controller (also Root CA) is rebooted. Once said server is rebooted, Java LDAPS:// clients then cease to work and re-fetching the root CA cert solves the problem – but prior to reboot, Java clients are perfectly happy and only Apache stops working.

I am just looking to understand what things can cause a windows server 2003 Root CA certificate to update. This server is very old (deployed almost 7 years) and is being phased out as we speak (it is nerve wracking to reboot!). Several services (RADIUS, Print Spooler, etc) cease working correctly after 2-3 months uptime, so I'm almost tempted to write it off to that…

  • Do Windows updates cause this?
  • Updates to the Windows list of Trusted CA's cause this certificate to update? (is there a relation?)
  • Other reasons?

UPDATE: Actual symptom of Java failing LDAPS auth until its certificate is updated (either root CA or LDAP cert – still determining…) :

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

More clarification:
Java LDAPS client is on a Linux server that is NOT a member of the domain, but is tunneled into our private network. Apache is on a Windows server that is a member of the domain.

Best Answer

Does the certificate actually.. update? Does it build a brand new root cert with a new hash, new expiration date, etc? Or just the observed "broken until rebooted" problem?

My hunch on that issue is that autoenrollment isn't happening for the domain controller that the LDAP/S clients are pointing to. Keep in mind that the certificate used for LDAP/S is either a Domain Controller or Kerberos Authentication certificate - these will be automatically enrolled by each domain controller, and will be up for renewal on your default renewal schedule. Check in the Certificates snap-in on the domain controller to see when it'll expire, and plan accordingly.

This failure to enroll could be for a number of reasons, including a misconfiguration on the certificate template or the CA itself (not allowing autoenrollment), issues with the CRL publishing, or simply a service failure like the RADIUS and spool services.

The first thing to check is the Enterprise PKI MMC snap-in, pkiview.msc. It will tell you if there's a failed service, or if a CRL hasn't updated, or anything else that's causing an issue with the trust chain.

Related Topic