过去几年、我们一直使用 CC3220和 CC3235开发物联网应用。 我们知道在连接到 Amazon AWS IoT 时指定根 CA 证书的问题、因为您必须指定"Starfield"证书、而不是亚马逊提供的"AmazonRootCA1.pim"证书、因为 Starfield 交叉签署了亚马逊证书。 我们还(我们认为)遇到了与 Google GCP IoT 类似的问题、因为他们提供 了一个 LTS 域、其服务器证书保证由两个根 CA 之一签署、 CC3220在连接到 MQTT.200.LTsapis.goog 时无法使用 TLS、并声明它期望使用此处提供的"GlobalSign Root CA"证书：
e2e.ti.com/.../5758.GlobalSign-Root-CA.pem.txt
我怀疑主要证书和次要证书都是由 GlobalSign 证书交叉签署的。
我想我有两个问题：
1) 1)在阅读 此论坛帖子时、我是否正确回答 了连接到 GCP IoT 的另一位用户的问题、即 CC3220不会接受用于 TLS 目的的任意自签名根 CA 证书、除非该证书出现在受信任证书目录中(无论是由 TI 提供还是自定义和自定义签名)？
2)假设您有一个证书链、其中 A (服务器证书)由 B (中间证书)签名、B 由 C (供应商的根 CA 证书)签名、但 C 也由 D (替代/传统根 CA)交叉签名。 我们还假设证书 C 确实出现在证书目录中(可能是因为开发人员创建了自定义目录并在 CC3220中放置了新的目录信任密钥等)。 现在、我们尝试使用 TLS 连接到服务器。 使用 MQTT 客户端时、应用程序必须在"sectionFiles"参数中提供哪个根 CA 证书？ 它是证书 C (即它足以显示在目录中)还是证书 D (因为 CC3220坚持将交叉签名证书视为链的真正末端)？ 谢谢。
戴维·R.
