Debian 11环境下apt update提示Docker仓库证书不受信，但curl验证SSL证书正常的原因是什么？
这个问题我之前帮朋友排查过类似的，咱们从几个核心差异点来拆解原因：
证书信任库的使用差异
curl默认调用的是系统全局的CA证书库（一般在/etc/ssl/certs/目录下的ca-certificates.crt），而apt在验证HTTPS仓库的SSL证书时，有可能使用独立的信任配置——比如你可以检查/etc/apt/apt.conf.d/目录下有没有自定义的Acquire::https::CaInfo项，要是强制指定了某个CA文件，而这个文件里没包含Docker证书签发方（Amazon RSA 2048 M02）的根证书，就会出现apt验证失败但curl正常的情况。哪怕你重装了ca-certificates，如果apt没同步这个更新，也会出问题。网络访问的协议差异
你看apt报错里的IP是IPv6地址（2600:9000:2113:5000:3:db06:4200:93a1），而curl可能默认用了IPv4去访问download.docker.com。部分CDN的IPv6节点可能存在证书链不完整的问题，或者你的网络环境对IPv6的证书解析有异常。这种情况下，curl用IPv4能拿到完整的证书链，apt用IPv6却拿不到，自然验证结果不一样。代理配置的不一致
如果你的系统用了代理工具，curl和apt的代理配置可能完全不同：curl可能读取的是~/.curlrc或者系统环境变量里的代理设置，而apt的代理是存在/etc/apt/apt.conf.d/下的配置文件里的。要是代理本身的SSL证书没被apt信任，就会导致apt在通过代理访问Docker仓库时证书验证失败，但curl用了信任代理证书的配置，所以能正常访问。SSL验证严格度的差异
apt的SSL验证规则有时候比curl更严格，比如它可能要求完整的证书链不能缺失任何中间证书，而curl会自动尝试补全缺失的中间证书。如果Docker仓库的CDN节点返回的证书链不完整，apt就会直接判定证书不受信，而curl能自动处理这个问题。
快速排查建议
- 先强制apt使用IPv4：创建
/etc/apt/apt.conf.d/99force-ipv4文件，写入Acquire::ForceIPv4 "true";，然后再跑apt update试试。 - 检查apt的CA配置：看看
/etc/apt/apt.conf.d/下有没有自定义的HTTPS配置，确保Acquire::https::CaInfo指向的是/etc/ssl/certs/ca-certificates.crt。 - 临时关闭代理（如果有的话），直接访问仓库验证是否正常。
备注：内容来源于stack exchange，提问作者Nir O.
