我们通过 Windows 证书存储中的受信任根证书在防火墙中使用 HTTPS 深度数据包检查。Chrome 最近推出了一项功能，对证书颁发进行额外检查，称为“证书透明度”，其中使用的每个证书（在某个日期之后颁发的）都会根据已知的 CA 列表进行检查。
使用 HTTPS 深度数据包检测（又名 HTTPS 代理/卸载/MiTM）现在会导致 Chrome 出现错误，如下所示这个例子。
是否可以禁用 Chrome 中唯一的审计日志检查功能？
更新回应womble 的回答。
此更新是错误的。 Womble 的答案是正确的，见下文。
我原本也是这么想的，但显然不是。
以下是过于正义的 Chrome 的截图：
无中间人攻击：
中间人攻击：
看起来它与证书透明度/审计日志检查直接相关，而不是使用 SHA-1 和保姆 Chrome 即将贬值。值得注意的是，我们的内部 CA 证书确实会在 2017 年后过期。
更新 2，womble 是对的：
感谢womble的回答，我重新审查了Chrome 团队的通知，并注意到任何使用 SHA-1 且证书有效期在 2017 年及以后的站点都会收到“肯定不安全”警告（划掉的红色锁图标）。
为了证明我的 MiTM/代理是罪魁祸首，我使用了salesforce 测试站点（通过躲避定位知识库文章）
无中间人攻击：
中间人攻击：
*note that even with no MiTM Chrome detects this site as "secure, but with minor errors" (that yellow icon) because the cert expires within the 2016 calendar year, not 2017+.
我的代理/中间人正在将算法从 SHA-256 降级为 SHA-1。啧啧啧！Chrome 的行为完全符合通知中的预期，我相信一旦我解决了中间人/代理的问题，我的用户就不会收到“肯定不安全”的通知。
谢谢！
更新 3： 记得检查固件更新/发行说明... 现在支持 SHA-256。更新定于周五进行。应该没问题。
答案1
假设您所指的例子实际上是关于“该网站正在使用过时的安全设置”，而不是“没有公共审计记录”，那么 99.99% 可以确定您的问题不是 CT，原因如下：
- 据我了解，只有系统信任库中的 CA 证书才需要经过 CT 验证；本地管理的 CA 证书不需要 CT 处理（原因与您完全一样）。
- 目前，CT 验证失败仅对 EV 证书有影响，唯一的负面影响是该证书失去 EV“绿条”待遇。
关于“使用过时的安全设置”的错误实际上意味着您的 MitM 代理正在颁发基于 SHA-1 的证书，其到期日期在遥远的未来，这可能不是一个好主意。