We have several Linux and Windows servers using LDAPS authentication to a MS AD controller for the applications they host, that is presenting a certificate signed by our internal root CA.

Recently, the AD controllers renewed their certs automatically. From this point on, most of the Linux hosted servers failed to authenticate to this AD controller, while Windows hosted server continued to work.

Nothing on these servers changed during that time, only the AD controller certificate, sub and root certs are unchanged.

Our first thought was that the Linux hosts might not have the internal root cert imported as trusted, but why did it work before then?

Some digging revealed that this AD controller is not presenting the full certificate chain, which means the root CA cert is missing.

Importing the root CA cert to most of the systems fixed it.

How can it have been working before the renewal on these Linux machines that do NOT have the root / sub certificates trusted? Even with a correctly presented certificate chain, this connection shouldn´t be trusted, as the root CA is not known by the system.

Unfortunately, I have no access to the certificate and chain that has been used before, so I cannot compare them, but there was no key length change or similar.

closed as unclear what you're asking by StackzOfZtuff, Xiong Chiamiov, Steffen Ullrich, Serge Ballesta, Steve Mar 9 '18 at 23:50

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Could you post the error message in full and the command that triggered the error? – StackzOfZtuff Jan 3 '18 at 22:04
  • it happens on several systems using different technilogies, so hard to summarize better than “PKIX path building failed” – parampam Jan 5 '18 at 14:54

Depending on the actual software that is doing the certificate chain validation, there are several possibilities how this might have worked before the renewal:

  • The old certificates were directly trusted locally w/o basing trust on a CA at all.

    While this is strictly not possible (as valid certificate chains must start with a root certificate), most implementations allow for this options (such that, for example, self-signed certificates can be trusted without adding the overhead of a CA setup).

  • The software does not use the trust store you are looking at.

Obiter Dictum:

Even with a correctly presented certificate chain, this connection shouldn´t be trusted, as the root CA is not known by the system.

That does not exactly hold true. Even though the root CA might be untrusted, a intermediate CA might be cross signed by another CA that the system in question has established trust in.

  • none of the certs within the internal chain from server to root had been added as trusted, and I´ve also verified which e.g. cacerts or similar keystore / config file etc the running application is configured to use. but thanks for your answer, I don´t think it is cross signed, but still a point to think of generally. We´ll investigate further – parampam Jan 5 '18 at 14:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.