cosign verify 报“no matching signatures”通常因未用镜像digest验证或registry路径不一致;需用registry/repo@sha256:xxx格式,检查digest有效性、公钥格式、tls配置及签名存储模式。

cosign verify 命令报 “no matching signatures” 是最常见的误判
这通常不是签名没做,而是验证时没指定对的镜像 digest 或者 registry 路径不一致。cosign 只认 registry/repo@sha256:xxx 这种带 digest 的格式,用 tag(比如 myapp:v1.2)直接验几乎必失败——因为 tag 可能被覆盖,而 cosign 签名绑定的是不可变 digest。
实操建议:
- 先用
docker pull拉镜像,再用docker inspect --format='{{.Id}}' <image></image>或crane digest获取准确 digest - 验证命令必须写成:
cosign verify --key cosign.pub registry.example.com/app@sha256:abc123... - 如果镜像来自私有 registry,确保
COSIGN_REPOSITORY环境变量没意外覆盖默认行为,或显式传--repository
签名存储位置和镜像 registry 不是同一个地方
cosign 默认把签名推到和镜像同名但加 .sig 后缀的 repository(例如镜像在 ghcr.io/user/app,签名就存 ghcr.io/user/app.sig)。但有些 registry(比如 Harbor 2.8+ 启用 OCI artifact 支持后)会把签名存在同一 repo 下不同 mediaType 的 artifact 中,这时 cosign 需要加 --force-upload 或适配 registry 的 artifact 模式。
常见错误现象:
立即学习“Python免费学习笔记(深入)”;
-
cosign verify找不到签名,但cosign download signature却能取到——说明签名存对了,但 verify 时 registry 返回的 artifact 列表没包含它(权限或 mediaType 过滤问题) - 私有 Harbor 上 verify 失败,但用
cosign verify --insecure-ignore-tls-verify成功——说明 TLS 证书校验阻断了 artifact 发现流程 - 签名上传成功,verify 却提示
no signature found for index:多见于 multi-arch 镜像,cosign 默认只签 manifest list 的 digest,没签每个子平台镜像,需加--recursive
Python 项目里调用 cosign 验证得绕过 subprocess 硬编码陷阱
别在 Python 里拼接字符串调 subprocess.run("cosign verify ..."),容易因 shell 字符(如 registry 密码含 $、&)、空格路径、未转义的 digest 引发静默失败。cosign 本身没有官方 Python SDK,所以得靠严谨的参数传递。
实操建议:
- 用
subprocess.run的 list 形式:["cosign", "verify", "--key", key_path, f"{registry}/{repo}@{digest}"] - 提前检查
digest是否以sha256:开头,否则 cosign 直接报错退出,不给详细提示 - 捕获
stderr并检查是否含"no matching signatures"或"certificate has expired"——这两类错误不会导致 returncode != 0,但实际验证失败 - 若集成进 CI/CD,注意 cosign 二进制版本兼容性:
cosign verify在 v2.0+ 默认启用 TUF 验证,老签名可能被拒,可加--tlog-url=""关闭
公钥格式不对会导致 “x509: certificate signed by unknown authority”
cosign 支持两种密钥体系:ECDSA(默认)和 Fulcio 签发的证书。如果你用 cosign generate-key-pair 生成的是 cosign.key / cosign.pub,那 cosign.pub 是 PEM 格式公钥,不是证书——但很多人误把它当证书传给 --cert,结果报 x509 错误。
关键区别:
-
--key和--cert是给 Fulcio 场景用的(需要完整证书链),普通 key pair 验证只用--key指向cosign.pub -
cosign.pub文件开头是-----BEGIN PUBLIC KEY-----,不是-----BEGIN CERTIFICATE----- - 如果用了
cosign sign --id-token走 Fulcio,验证时就得用--cert+--cert-identity,且 identity 必须和签名时的 OIDC sub 完全一致(包括邮箱大小写)
最容易被忽略的一点:cosign 对公钥文件内容极其敏感——末尾多一个空行、BOM 字节、Windows 换行符,都可能导致解析失败且错误信息毫无提示。用 file cosign.pub 确认是 “PEM certificate” 还是 “PEM public key”,比猜靠谱得多。










