eMudhra证书事件提醒了一个容器部署细节：镜像里的CA包更新了，运行中的应用仍可能读着宿主机挂载进来的旧文件。尤其是Compose把证书目录标成:ro以后，容易让人误以为这份信任材料已经无需再管。
Cloudflare在2026年10月20日披露8张eMudhra中间CA证书的私钥受损，并将自带或定制信任库列为单独检查对象。本文聚焦证书挂载与实际读取路径，以下为配置示例和只读检查方法，没有声称已在云主机完成修复。
1. 只读挂载保护写入，不负责更新内容
Docker的bind mount会遮住容器目标路径原来的内容。假设新镜像已经带有更新后的/etc/ssl/certs，Compose仍把宿主机旧目录挂到这里，应用看到的就是挂载后的目录。
read_only: true限制容器写入挂载内容，不会让宿主机文件自动更新，也不会证明常驻进程已经重新加载。问题需要拆成三问：挂了什么，应用读哪里，文件由谁维护。
这也解释了事件与Docker的关系：风险涉及远端身份验证依赖的信任材料，不代表镜像本身被攻破，更不代表TLS加密算法失效。更新信任源时应遵循维护者方案，避免自行按名字批量删除证书。
2. 先认清三个配置名的边界
| 配置名 | 常见用途 | 核对重点 |
|---|---|---|
SSL_CERT_FILE |
OpenSSL默认CA文件的环境入口 | 运行时是否加载默认路径；代码是否另建上下文 |
SSL_CERT_DIR |
OpenSSL默认CA目录的环境入口 | 应为符合其查找要求的证书目录，不能当任意PEM文件夹 |
REQUESTS_CA_BUNDLE |
Requests环境设置中的CA文件或目录入口 | 实际调用是否读取环境；是否显式指定verify |
它们不是跨语言通用开关，也不应为了保险全部填一遍。Python标准库的默认OpenSSL路径，与Requests默认附带的CA包可以不同；PreparedRequest流程若没有合并环境设置，也可能不采用预期的环境配置。目录形式还要按相应库要求处理哈希索引。
3. 显式挂一个文件，保留维护责任
若应用确实使用Requests，且团队已有经过核验的完整信任包，可以用单文件挂载说明对应关系。下面是骨架，不能覆盖现有项目直接运行；APP_IMAGE应填业务镜像，CA包应保留业务所需的有效信任链。
services:
app:
image: ${
APP_IMAGE:?填写已核验的业务镜像引用}
environment:
REQUESTS_CA_BUNDLE: /run/trust/ca-bundle.pem
volumes:
- type: bind
source: ./trust/ca-bundle.pem
target: /run/trust/ca-bundle.pem
read_only: true
bind:
create_host_path: false
长语法明确了源、目标与只读属性；源文件不存在时，不自动创建同名目录。这样比遮住整套系统证书目录更容易检查，也把自定义包的更新责任留在可见位置。
业务若基于Python镜像构建，获取路径可写成docker.1ms.run/library/python:<已确认标签>，不猜本次修复标签。基础镜像更新后，仍需检查上面的独立CA包；镜像入口不改变挂载内容。
4. 用运行容器核对实际挂载
先确认目标容器，只取Mounts字段，避免把完整inspect中的其它配置一起贴进工单：
CID='替换为目标容器ID'
docker inspect --format '{
{json .Mounts}}' "$CID"
逐项比对Source、Destination、Type和RW。只读bind通常应看到Type为bind、RW为false；再看目标是否覆盖了系统目录、依赖包目录或代码指定的路径。
对已有Python的容器，可只读取这三个路径变量。业务使用虚拟环境时，应换成相同解释器；输出仍是新诊断进程的线索。
docker exec -i "$CID" python3 -B - <<'PY'
import os
for name in ("SSL_CERT_FILE", "SSL_CERT_DIR", "REQUESTS_CA_BUNDLE"):
print(name, os.environ.get(name, "<未设置>"))
PY
不要用整份env替代这一步。变量未设置不等于没有自定义CA，代码参数、配置文件和SDK也可能另行指定。下一步应检查业务客户端创建位置，找到真正交给校验器的文件或目录。
5. 留下文件证据，再验业务路径
给最终采用的CA包登记维护者、更新公告、版本或内容摘要、宿主机源路径、容器目标路径及装载时机。把CA_SOURCE设为已核实的Mounts.Source绝对路径后，在对应Docker守护进程所在的Linux主机读取两侧摘要：
: "${CA_SOURCE:?填写已核实的Mounts.Source绝对路径}"
sha256sum -- "$CA_SOURCE"
docker exec "$CID" sha256sum /run/trust/ca-bundle.pem
这要求主机和容器已有sha256sum。宿主机原子替换单文件后，现有bind挂载可能仍引用旧文件；若容器摘要仍旧，按项目变更流程重新创建目标容器以重建挂载，再核对摘要并重载应用。只检查已确认的公开CA包，不要上传服务端或客户认证私钥；摘要相同只能证明文件内容一致，不能证明应用已经加载。
验收还要经过实际客户端：在获准环境确认受影响链按维护者预期被拒绝，正常链仍可通过，且证书校验保持开启。如果应用启动时缓存信任材料，按其说明重新加载后再核。最终记录应能明确区分：镜像内的CA、挂载后的CA、应用实际使用的CA。
资料依据：Cloudflare事件公告（2026-10-20）；Docker bind mounts与Compose services、Python ssl、Requests官方文档（2026-10-22核验）。
