<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">On 12/5/17 12:18 PM, Peter Schober

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:20171205171836.7eulvvo632wehdcu@aco.net">

      <pre wrap="">I'm not saying the incorrect trust chain is the very reason for what

you're experiencing, just that I'd get it fixed while you're at it.

The TLS server sending out the CA root cert does not make anything

more secure (or much sense) -- the TLS client is supposed to have the

trust anchor (e.g. the CA root) available to verify the chain

transmitted by the TLS server (which in your case is just the LDAP

server's own cert as you have no intermediate certs).</pre>

    </blockquote>

    <br>

    I don't believe that including the root CA (aka trust anchor) is

    incorrect. From RFC 5246 (TLS 1.2), section 7.4.2 ("Server

    Certificate") -- <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc5246#section-7.4.2">https://tools.ietf.org/html/rfc5246#section-7.4.2</a><br>

    <br>

    <blockquote>

      <pre class="newpage">certificate_list

      This is a sequence (chain) of certificates.  The sender's

      certificate MUST come first in the list.  Each following

      certificate MUST directly certify the one preceding it.  Because

      certificate validation requires that root keys be distributed

      independently, the self-signed certificate that specifies the root

      certificate authority MAY be omitted from the chain, under the

      assumption that the remote end must already possess it in order to

      validate it in any case</pre>

    </blockquote>

    <br>

    <br>

    The draft of TLS 1.3 appears to relax the ordering of certificates,

    though in either version, the sender's/end-entity certificate must

    be first.<br>

    <br>

    -Phil<br>

  </body>

</html>