title: Ensuring full certificate chains are provided to Secure Transport peers
body: <p>Apple's Secure Transport API defines a function, <a href="https://developer.apple.com/library/mac/documentation/Security/Reference/secureTransportRef/index.html#//apple_ref/c/func/SSLSetCertificate" rel="nofollow noreferrer"><code>SSLSetCertificate</code></a>, of which the <code>certRefs</code> parameter is an array of certificates.  The documentation states (emphasis added):</p>
  
  <blockquote>
    <p>You must place in <code>certRefs[0]</code> a <code>SecIdentityRef</code> object that identifies the leaf certificate and its corresponding private key. Specifying a root certificate is optional; <em>if it’s not specified, the root certificate that verifies the certificate chain specified here must be present in the system wide set of trusted anchor certificates.</em></p>
  </blockquote>
  
  <p>Whilst it says "<em>the root certificate&hellip;must be present</em>", it's not <strong>clear</strong> whether trust chains so found will actually be provided to the SSL peer (albeit it's difficult to think of any other reason for that requirement to exist).</p>
  
  <ol>
  <li><p>How does one <strong>ensure</strong> that the <em>full certificate chain</em> (back to a self-signed root, or else a system trust anchor) is provided to the peer?</p></li>
  <li><p>In particular, <strong>must</strong> all constituent certificates be included in this <code>certRefs</code> parameter (or does that have no bearing)?</p></li>
  </ol>
  
  <blockquote>
    <p><sub><strong>Background</strong></sub></p>
    
    <p><sup>This question follows <a href="https://serverfault.com/q/653419/">an earlier post on ServerFault</a>.  Having now RTFS, it's clear that slapd <a href="https://github.com/aosm/OpenLDAP/blob/ed3398e553abcb349419fdb038e489283feca6cd/OpenLDAP/libraries/libldap/tls_st.c#L1120" rel="nofollow noreferrer">calls</a> <code>SSLSetCertificate</code> with <a href="https://github.com/aosm/OpenLDAP/blob/ed3398e553abcb349419fdb038e489283feca6cd/OpenLDAP/libraries/libldap/tls_st.c#L1026" rel="nofollow noreferrer">only the host's identity certificate</a> and at no stage attempts to furnish Secure Transport with the certificate chain&mdash;perhaps that's okay (because Secure Transport is supposed to sort it all out), but I have a hunch this might be the cause of the problem.</sup></p>
  </blockquote>