Docker 配置 CA 后仍 unknown authority：certs.d 目录要匹配仓库地址

私有仓库的 CA 已保存，curl --cacert 能验证连接，但 Docker 登录或拉取仍报 x509: certificate signed by unknown authority。先检查 CA 放在使用仓库的 Docker Engine 所在主机上，目录名是否与实际访问的仓库主机名和端口一致。curl 显式读取的一份 CA 文件，不会自动成为 Docker daemon 的信任配置。

下面的 /etc/docker/certs.d 示例针对以 root 权限运行的 Linux Docker Engine（rootful），用于 HTTPS 私有仓库。Rootless Linux Engine 使用 $XDG_CONFIG_HOME/docker/certs.d，默认是 ~/.config/docker/certs.d，应在运行 daemon 的用户配置目录中核对，不能照搬 rootful 路径。Docker Desktop、远程 daemon 和其他构建器的证书配置位置可能不同，先确认请求究竟由哪一个组件发起。

目录名是仓库地址，不是证书文件名

以下是访问 registry.example.net:5000 时的目录结构示例：

/etc/docker/certs.d/
└── registry.example.net:5000/
    └── ca.crt

子目录应是 registry.example.net:5000，不要写成 registry.example.net.crt，也不要在目录名中增加 https:// 或仓库路径。给另一台机器配置相同文件，并不能让当前 daemon 读取它。

如果实际使用 docker login registry.example.net，没有指定端口，则按该访问地址使用 registry.example.net 目录，不额外写 :443。同时核对镜像引用是否实际指向另一个域名、IP 或端口。

CA 文件需要是经可信渠道取得、用于验证这张服务证书的 PEM 证书。不要把服务器私钥复制到客户端，也不要把证书文件仅凭扩展名改成 .crt 就认为内容正确。

.crt 与 .cert 的用途不同

Docker 将 .crt 识别为 CA 证书，将 .cert 识别为客户端证书。把 CA 保存为 .cert 可能产生寻找对应私钥的错误，例如 Missing key ... for client certificate ...；此时应恢复正确的 CA 文件用途和扩展名，而不是为 CA 随意配一把客户端私钥。

只有仓库确实要求双向 TLS 时，才另外配置相应客户端证书与私钥。用户名、访问令牌和 TLS 信任也是不同层：证书验证失败还没有进入正常的仓库权限判断。

修改前记录现有信任文件及权限，只调整对应仓库目录。若使用远程 Docker context，要在远端 daemon 核对配置；本机客户端登录配置与远端证书信任不能混为一份文件。

信任正确后，仍须匹配证书名称

加入 CA 只解决信任关系，不会让证书自动适用于另一个域名或 IP。如果错误变成 cannot validate certificate ... because it doesn't contain any IP SANs，说明还要核对证书 SAN 与使用地址；仅增加 CA 不能解决这个错误。

服务器少发中间证书、证书过期或实际连接到了另一个代理，也可能造成验证失败。应检查服务器提供的证书链，不能把所有 unknown authority 都归为目录命名问题。

修正后重新尝试对预期仓库的认证或拉取，确认不再出现 TLS 信任错误。若当前版本和部署方式需要重新加载或重启 daemon 才读取变更，应先确认容器影响并安排窗口，不要无条件重启所有服务器。

成功标准是通过正常证书校验访问目标仓库，并完成所需的认证或镜像读取。回退时只恢复本次调整前的文件与目录，不删除其他仓库的信任配置，也不要用 insecure registry 代替这次证书修复。