- Manifest集成证书与吊销证书列表，能同时进行两个厂商的验签吗？
目前默认集成的是我们自己的der和crl，然后在manifest.yml里重命名为rootca.der和cms.crl。有伙伴的证书和签名路径，支持默认验签不通过时，验证另一套签名吗？
答案内容由AI生成，仅供参考：
总结与建议
| 问题 | 回答 | 建议 |
|---|---|---|
| 1. 是否可同时集成两厂商证书？ | 可以，但需合并为单个信任链 | 合并两家 .der 根证书为一个 PEM 文件并内置于镜像 |
| 2. 是否支持默认失败后尝试另一套签名？ | 不支持自动轮询 | 修改脚本或提前集成双证书 |
| 3. SP 从哪个版本支持 1712？ | 无明确版本号，但 >=25.03/TR6 应支持 | 检查官网 SP 发行说明，确认是否包含 1712 的 ProductID |
点击此处查看详细分析解答
关于烧片问题的详细解答
您提出的三个问题涉及 固件签名校验机制、多厂商证书支持能力，以及 SP版本对1712机型的支持情况。以下将逐项基于现有知识进行分析和解答。
一、manifest.yml 集成证书与吊销列表，能否同时支持两个厂商的验签？
结论：默认不支持自动轮询或并行验签，但可通过集成多个根证书实现多厂商支持。
1. 签名验证机制说明
- 固件升级过程中的签名验证由脚本
validate_sign.lua（或Validate_Sign_Lua）负责。 - 该脚本使用 CMS（Cryptographic Message Syntax）机制 来验证 HPM 包的数字签名。
- 验证依赖于：
- 根证书（如
rootca.der或RootCA DER） - 证书吊销列表（CRL，如
cms.crl.pem） - 工具链如
Hpm Verify使用Rootca.pem进行可信链校验。
- 根证书（如
关键点：固件管理组件（
firmware_mgmt）通常只加载一个默认的信任锚点（即一个根证书）。如果签名证书链无法追溯到该根证书，则直接报错：
verify signature error, code 88200004
此错误码的含义是 “证书发布者不存在”，即签名未由预置根证书签发或不在信任链中。
2. 是否可同时支持两个厂商验签？
默认机制不支持“默认失败后尝试另一套证书”
- 当前系统在验签失败时，不会自动尝试第二个根证书。
- 如果当前使用的
rootca.der是厂商A的根证书，则只能验证由A签名的固件包；无法自动切换到厂商B的证书进行第二轮验证。
但可通过 提前集成多个根证书 实现多厂商兼容
解决方案如下：
| 方法 | 说明 |
|---|---|
| 方法一：使用证书链文件（PKCS#7 / PEM chain） | 构建一个包含多个根CA的证书链文件（如 Rootca.pem 包含厂商A和厂商B的根证书），并在构建环境中将其作为信任锚。Hpm Verify 和 validate_sign.lua 支持读取完整的信任链。 |
方法二：场内定制 validate_sign.lua 脚本 |
修改验签逻辑，在原有验证失败后加载第二个 Custom_Ca_Certificate 进行二次验证。但由于 firmware_mgmt 组件未完全开源，需官方支持或场内制作。 |
| 方法三：通过过渡包预先植入双证书 | 制作一个“过渡固件包”，在其中预置双根证书（例如分别放在 /opt/bmc/trust/partner/ 和 /opt/bmc/trust/vendor/），然后通过配置使 validate_sign.lua 支持动态选择。 |
建议操作步骤：
- 将厂商A和厂商B的根证书（
.der）转换为 PEM 格式；- 合并为一个 PEM 文件（顺序无关）；
- 在
manifest.yml构建时指定该合并后的证书为rootca.der；- 使用此固件升级后即可同时验证两家签名。
二、是否支持“默认验签失败 → 自动尝试另一套签名”？
结论：目前不支持自动轮询或多路径验签。
原因分析：
validate_sign.lua是单次验证入口，一旦CMS_verify失败即返回错误码88200004，不继续尝试其他证书。- 当前设计遵循“单一信任源”原则，除非主动修改脚本逻辑或信任库。
可行替代方案：
手动集成双证书（推荐）
将两家厂商的根证书都纳入信任库，本质不是“轮询”，而是“统一信任”。
示例做法：
# 将两个 DER 证书合并为一个 PEM 信任链
openssl x509 -inform der -in huawei_rootca.der >> trust_chain.pem
openssl x509 -inform der -in partner_rootca.der >> trust_chain.pem
然后在打包时：
signature:
certificates:
rootca_der: trust_chain.der # 先转回 DER
如此即可实现对 华为签名 和 伙伴签名 固件的同时支持。
三、官网上的 SP 在哪个版本开始支持 1712 机型？
结论：根据上下文无法确定具体 SP 版本号，但可推断需满足以下条件：
1. 关于 “1712机型” 的理解
假设 “1712” 指某服务器型号（如华为某款机架式服务器），那么其 SP（Service Pack）支持需满足：
- BMC 固件支持该硬件平台的设备树（Device Tree）；
- 南向驱动适配对应 CPLD、FRU、传感器等；
- SP 包中包含
1712的ProductID或BoardID信息。
2. 从知识库线索分析支持情况
- 多份文档提及通过 白牌包（HPM格式） 预置证书、适配新机型；
- 白牌包可携带特定平台的配置（见
web_custom.xml中的PlatformType）； manifest.yml支持通过options裁剪适配不同产品。
因此，只要 SP 包构建时指定了
1712的平台标识，并正确配置硬件抽象层，即可支持。
3. 官方 SP 支持起点版本
虽然当前资料未明确指出哪个 SP 版本开始支持 1712，但可参考：
| 判断依据 | 推论 |
|---|---|
| openUBMC 25.03 版本已支持 HPM 标准化升级、CSR 配置检查、多厂商部件适配 | >= openUBMC 25.03 的 SP 很可能已支持主流新机型 |
| 需要支持 PSS 填充模式证书（而非仅 PKCS#1 v1.5） | 若 1712 使用 PSS 签名，至少需要支持 G2 根证书的版本 |
| “Huawei Integrity Root CA - G2” 在论坛中被频繁引用 | 包含 G2 证书验证能力的 SP 版本（如 TR6 及以后）才可支持 |
合理推测：
官网 SP 包从 TR6 或 openUBMC 25.03 之后 的版本开始支持 1712 机型。
总结与建议
| 问题 | 回答 | 建议 |
|---|---|---|
| 1. 是否可同时集成两厂商证书？ | 可以，但需合并为单个信任链 | 合并两家 .der 根证书为一个 PEM 文件并内置于镜像 |
| 2. 是否支持默认失败后尝试另一套签名？ | 不支持自动轮询 | 修改脚本或提前集成双证书 |
| 3. SP 从哪个版本支持 1712？ | 无明确版本号，但 >=25.03/TR6 应支持 | 检查官网 SP 发行说明，确认是否包含 1712 的 ProductID |
推荐实践路径：
- 获取两家厂商的
.der根证书； - 合并为
combined_rootca.pem→ 转为combined_rootca.der； - 在
manifest.yml中配置：signature: certificates: rootca_der: build/product/BMC/openUBMC/rootfs/opt/bmc/trust/combined_rootca.der rootca_crl: path/to/combined.crl - 使用
hpm_signer打包，并测试能否升级华为和伙伴各自签名的固件。
如有进一步需求，建议向 bmc_core SIG 提出“多根证书自动识别”或“多信任源轮询”的功能诉求。
这里的验签是指安全启动，还是安全升级？
安全启动不支持 “或” 形式的验签，只能选择一个可信根
安全升级，实际上是支持一个CA集合，在集合中的均可以校验
hpm包升级的验签，不知道是不是安全升级。
另外按AI答复的这种，这个集合是不是没法把两个厂商的证书合在一起？
如果是hpm包升级，就是我说的安全升级场景
这种场景是支持多ca的，理论上把ca拼接起来也可以，但实际没有这么用过，可能得测试一下
拼接这个有什么资料参考看下吗？不太懂证书和CRL怎么进行拼接
我之前是打算做子ca，再终端证书，但是代码实现没有这么搞。但是如果我自己适配了，那不确定和社区升级逻辑有没有什么差异，所以我也不敢单独乱适配。
本身你构建BMC是不认的，升级是认子ca的吧，这个也许安全sig做了。但是我看了代码因为校验代码只做了一层。而且这种不合适啊，如果说校验认，那做一层还是几层，你做了一层，别人还会做二层，还有的人更激进做三层，那就是源源不断的要从构建这块适配代码了，所以构建这块只封了一层。代码这块可以去看，。代码实际里面签名端没有携带中间证书，校验端也只喂了一个 CA 和一个 CRL
cms = CMS_sign(scert, skey, NULL, in, flags);这里第三个参数是 NULL。
校验端只暴露了一个 -r rootca.pem 和一个 -C crl，内部也是只往 X509_STORE 里加了一张 CA 证书和一张 CRL：
-
ca_cert = "rootca.pem" -
X509_STORE_add_cert(st, cacert) -
X509_STORE_add_crl(st, crl)
没有任何“多 CA 链”“多中间证书”“多 CRL”的装载逻辑。
CMS_verify(cms, NULL, st, cont, NULL, flags)
这里第二个参数也是 NULL，表示它没有额外提供一组 untrusted/intermediate certs
这只是其中一个问题，你如果构建你还要再验别的厂商，我相信你们适配肯定没问题，但是这块安全性呢？rootca，和终端证书，全都要在构建做。你需要拿到别人的私钥吧，除了构建校验，还有升级校验，那安全启动呢？