macos - Ensuring full certificate chains are provided to Secure Transport peers

Question

Apple's Secure Transport API defines a function, SSLSetCertificate, of which the certRefs parameter is an array of certificates. The documentation states (emphasis added):

You must place in certRefs[0] a SecIdentityRef object that identifies the leaf certificate and its corresponding private key. Specifying a root certificate is optional; 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.

Whilst it says "the root certificate…must be present", it's not clear 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).

1. How does one ensure that the full certificate chain (back to a self-signed root, or else a system trust anchor) is provided to the peer?

2. In particular, must all constituent certificates be included in this certRefs parameter (or does that have no bearing)?

_Background

^{This question follows an earlier post on ServerFault. Having now RTFS, it's clear that slapd calls SSLSetCertificate with only the host's identity certificate and at no stage attempts to furnish Secure Transport with the certificate chain—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.}

Answer 1

好的，我已经通过libsecurity_ssl并相信：

• SSLSetCertificate除其他外，设置上下文调用localCert...

• parseIncomingCerts其中（接收指向该变量的指针并）将其值设置为链表。虽然评论将此列表称为“证书链”——实际上，局部变量已命名certChain，并且评论描述了它的信任语义——但它实际上只是从数组中天真地创建的。 特别是，尽管有相反的评论，但既不检查也不验证信任链。

• 尽管进行了彻底的搜索，但在将证书链发送给对等方之前，我找不到任何地方可以在证书链上执行任何进一步的工作。这表明问题中的引用实际上是错误的：缺少根证书（当前）不需要在系统信任锚中。

我总结：

1. 如何确保向对等方提供完整的证书链（返回自签名根，或者系统信任锚）？

   传给SSLSetCertificate.

2. 特别是，所有组成证书是否必须包含在此参数certRefs中（或者没有影响）？

   从文档和代码注释来看，Apple 的意图可能是在未来改变这一点，但就目前而言……是的，他们必须这样做。