解决boost.asio certificate failed error -without- access源代码，找出Philips Hue Bridge分享了什么信息
Solve boost.asio certificate failed error -without- access to source code, to find out what information Philips Hue Bridge shares
这是一个有点超级骗子的具体问题，但谁知道有人可以帮助我呢。
我恰好有飞利浦 Hue Bridge，我很想知道它与外界分享了哪些个人信息。在我的路由器上使用 tcpdump，我发现 Hue Bridge 具有相当健谈的个性。但是因为它通过 SSL 隧道进行通信，所以我不知道它说的是什么。所以我所做的是我设置了一个带有 CA 的 SSL-DPI 的 SonicWall，获得了对 Hue Bridge 的根访问权限，并找到了与 wws://ws.meethue.com（它称为 websocketcd）进行对话的应用程序。然后我更换了 Hue Bridge 上的根证书，调整了密码以匹配 Sonicwall，现在由于 boost.asio 我的证书验证错误而被卡住了：
error:14090086:lib(20):func(144):reason(134)
对于那些不太熟悉错误代码的人，这就是它们的意思：
lib(20) is ERR_LIB_SSL
func(144) is SSL_F_SSL3_GET_SERVER_CERTIFICATE
reason(134) is SSL_R_CERTIFICATE_VERIFY_FAILED
为了验证不是我的 SonicWall 或证书导致了问题，我从 Hue Bridge 执行了 openssl s_client -connect ws.meethue.com:443 -CAfile ca.pem 并且验证链完全正常，与原始证书相同。我还验证了该应用程序正在正确加载我的根证书和密码（因为如果更改密码，我会收到密码错误错误）。同样在我的浏览器中，我可以访问 https://ws.meethue.com without certificate errors. Here's my self made certificate chain, in case someone wants to check it: https://gofile.io/d/5msjoJ（download/key 1020304050 的密码，它是一个临时密钥，仅存在于我的本地测试环境中。因此可以安全地共享 ;-)
如果 websocketcd 不是二进制文件，使用 set_verify_mode 解决问题非常容易，但不幸的是它是二进制文件，这让事情变得更加复杂。
有没有人可以给我建议如何使这个名为 websocketcd 且其中包含 boost.asio 的 blob 接受我的根证书？我也尝试过：让它在没有 ssl 的情况下和没有加密的 ssl 进行通信（eNULL：aNULL 密码）。我有点犹豫要不要分享这个 blob，但对于那些也有 Hue Bridge 的人来说，它位于 /usr/bin/websocketcd.
也许您可以使用 strace（或者甚至 ltrace）来识别它为根权限使用的证书路径。
如果它使用单个文件，您可能会通过将其替换为验证您的 MITM 证书的 CA 来破解它。
有时文件可以包含多个证书，所以值得 appending/prepending 你的。
如果幸运的话，在包含证书的目录中会有一个 readdir。如果是这样，您应该能够在那里添加您的根证书（以 PEM 形式）并**记住在该目录上 运行 c_rehash。
对于那些感兴趣的人：大约 20 小时后，我发现 websocketcd 需要链中每个 CA 的证书吊销列表（不必有任何吊销的序列号）。这些 CLR 需要包含在使用 ca-filename 参数加载的根 CA 文件中。我不知道 Boost Asio 可以要求每个 CA 都有一个 CLR，但显然，他们 (Signify) 设法做到了。
这是一个有点超级骗子的具体问题，但谁知道有人可以帮助我呢。
我恰好有飞利浦 Hue Bridge，我很想知道它与外界分享了哪些个人信息。在我的路由器上使用 tcpdump，我发现 Hue Bridge 具有相当健谈的个性。但是因为它通过 SSL 隧道进行通信，所以我不知道它说的是什么。所以我所做的是我设置了一个带有 CA 的 SSL-DPI 的 SonicWall，获得了对 Hue Bridge 的根访问权限，并找到了与 wws://ws.meethue.com（它称为 websocketcd）进行对话的应用程序。然后我更换了 Hue Bridge 上的根证书，调整了密码以匹配 Sonicwall，现在由于 boost.asio 我的证书验证错误而被卡住了：
error:14090086:lib(20):func(144):reason(134)
对于那些不太熟悉错误代码的人，这就是它们的意思：
lib(20) is ERR_LIB_SSL
func(144) is SSL_F_SSL3_GET_SERVER_CERTIFICATE
reason(134) is SSL_R_CERTIFICATE_VERIFY_FAILED
为了验证不是我的 SonicWall 或证书导致了问题，我从 Hue Bridge 执行了 openssl s_client -connect ws.meethue.com:443 -CAfile ca.pem 并且验证链完全正常，与原始证书相同。我还验证了该应用程序正在正确加载我的根证书和密码（因为如果更改密码，我会收到密码错误错误）。同样在我的浏览器中，我可以访问 https://ws.meethue.com without certificate errors. Here's my self made certificate chain, in case someone wants to check it: https://gofile.io/d/5msjoJ（download/key 1020304050 的密码，它是一个临时密钥，仅存在于我的本地测试环境中。因此可以安全地共享 ;-)
如果 websocketcd 不是二进制文件，使用 set_verify_mode 解决问题非常容易，但不幸的是它是二进制文件，这让事情变得更加复杂。
有没有人可以给我建议如何使这个名为 websocketcd 且其中包含 boost.asio 的 blob 接受我的根证书？我也尝试过：让它在没有 ssl 的情况下和没有加密的 ssl 进行通信（eNULL：aNULL 密码）。我有点犹豫要不要分享这个 blob，但对于那些也有 Hue Bridge 的人来说，它位于 /usr/bin/websocketcd.
也许您可以使用 strace（或者甚至 ltrace）来识别它为根权限使用的证书路径。
如果它使用单个文件，您可能会通过将其替换为验证您的 MITM 证书的 CA 来破解它。 有时文件可以包含多个证书，所以值得 appending/prepending 你的。
如果幸运的话，在包含证书的目录中会有一个 readdir。如果是这样，您应该能够在那里添加您的根证书（以 PEM 形式）并**记住在该目录上 运行 c_rehash。
对于那些感兴趣的人：大约 20 小时后，我发现 websocketcd 需要链中每个 CA 的证书吊销列表（不必有任何吊销的序列号）。这些 CLR 需要包含在使用 ca-filename 参数加载的根 CA 文件中。我不知道 Boost Asio 可以要求每个 CA 都有一个 CLR，但显然，他们 (Signify) 设法做到了。