NTLS中没有构建加密证书证书链，没有校验加密证书是否来自可信根

[stardrift1]

@InfoHunter 是否有什么特殊考虑？

[InfoHunter]

#113 中提到了加密证书没有认证的问题，我们发现之前BabaSSL对签名和加密证书的校验行为不一致，所以我们在 #114 中修复了这个问题，对于服务器端校验客户端证书的修复正在进行中。

不过需要说明的是：标准的TLS协议握手只需要一个证书来进行认证，但是NTLS中由于双证书体系的问题，证书被拆成了具有独立功能的2个证书（签名和加密），其中签名证书用于认证，加密证书用于密钥交换。目前我们没有发现相关的技术标准对在这种情况下的对端身份认证应该如何实现，所以之前也没针对这块进行特殊处理，只是校验了签名证书（因为我们觉得签名证书是用于身份认证，而加密证书不一定是），后来由于 #113 的提出，我们觉得即使没有相关技术标准，但是BabaSSL至少可以把实现上做到尽量一致。

[stardrift1]

@InfoHunter 看了下当前的修复方案，似乎没有构建加密证书的证书了来传输到对端，只在本端做了加密证书链的构建和检查是吗

[InfoHunter]

不是太理解，你是说服务器或者客户端在Certifcate消息里没发送中间CA的证书么？我记得目前应该是：签名证书 加密证书 中间CA1 中间CA2 这种格式构建的服务器Certificate消息，所以对端应该自己来拼接加密和签名证书的证书链

[stardrift1]

不是太理解，你是说服务器或者客户端在Certifcate消息里没发送中间CA的证书么？我记得目前应该是：签名证书 加密证书 中间CA1 中间CA2 这种格式构建的服务器Certificate消息，所以对端应该自己来拼接加密和签名证书的证书链

是的，但是好像并没有考虑加密证书和签名证书来自不同CA的情况，也就是在拼接证书链的时候，证书链中的CA都是签名证书的CA，并没有加密证书的CA，不知道是否是我看的有遗漏

[InfoHunter]

是的，但是好像并没有考虑加密证书和签名证书来自不同CA的情况，也就是在拼接证书链的时候，证书链中的CA都是签名证书的CA，并没有加密证书的CA，不知道是否是我看的有遗漏

这个就是比较模糊的地方，根据实际情况来看，我们现有的非BabaSSL联调对象，比如一些国产浏览器或者其他密码厂商的设备，基本都是签名和加密证书都来自于相同的CA，所以相同CA的话就没必要重复构建证书链，证书链太长对性能有损。而且我不太了解是不是在实际应用中真正存在两个证书来自于不同CA的情况（如果你那有实际应用案例但是不方便公开，可以私聊下），我比较好奇这个 ;-)

[stardrift1]

这边暂时也没有这种情况，我们现有对接的浏览器和其他一些国密开源实现，现在都是默认两本证书来自相同CA

[InfoHunter]

所以可能问题的根源是，两个证书来自于不同的CA这总情况是否合规，不知道 @zhsnew 总是否了解？

[zhsnew]

所以可能问题的根源是，两个证书来自于不同的CA这总情况是否合规，不知道 @zhsnew 总是否了解？

现在CA系统会同时签发签名证书、加密证书，两个证书具有相同的有效期和上级签发CA。目前接触到的应用都是准确配对使用的，两个证书不是同时签发的情况在系统管理、技术处理上都会带来复杂性，建议应用中避免这种使用模式。