GitHub Action中使用Sectigo证书为Electron应用签名时Mac作业报错

报错中提到的chrome_crashpad_handler是Electron应用包内的内置辅助程序，electron-builder会对app包内所有可执行文件逐个完成签名，第一个触发签名失败的程序就会抛出对应报错，和该程序本身无关。

整体报错的本质原因有两点：

• 信任链不完整：GitHub Runner的macOS系统钥匙串没有内置Sectigo代码签名证书对应的中间CA证书，无法验证从叶子签名证书到系统信任根的完整路径，因此抛出unable to build chain to self-signed root警告
• 权限拦截：非交互的CI环境下，临时钥匙串没有给codesign工具开放私钥访问权限，触发系统安全机制拦截，进而抛出errSecInternalComponent错误

Windows作业能正常完成签名，是因为Windows系统证书存储默认内置了Sectigo全链路信任根，哪怕你只导出了叶子证书，也能通过系统内置的中间证书补全信任链完成验证，和你配置的仓库密钥本身的有效性、证书是否自签名完全无关。

1. 重新导出带完整信任链的p12证书 #

在你本地能正常完成签名的Mac实体机上，通过「钥匙串访问」操作：

• 找到「我的证书」分类下对应的Sectigo代码签名证书条目（注意要展开看到条目下嵌套的中间证书，不是单独导出的.cer格式证书文件）
• 右键导出为p12格式，导出时必须勾选包含所有证书链选项，不要仅导出签名证书本身的私钥
• 为导出的p12文件设置访问密码，将文件转成base64编码后，替换GitHub仓库原来的CSC_LINK密钥内容，对应的密码替换为CSC_KEY_PASSWORD密钥
• 此前如果导出的p12仅包含叶子签名证书，在CI的干净环境下必然出现信任链缺失报错

2. Mac作业显式配置专用临时钥匙串 #

在GitHub Action执行electron-builder的步骤前，增加钥匙串初始化流程，解决CI环境下的权限拦截问题，可直接复用如下命令：

# 创建临时专用钥匙串，TEMP_KEYCHAIN_PWD可设为任意固定临时字符串
security create-keychain -p "$TEMP_KEYCHAIN_PWD" build.keychain
# 将该钥匙串设为当前会话默认钥匙串
security default-keychain -s build.keychain
# 解锁钥匙串，避免非交互环境的权限拦截
security unlock-keychain -p "$TEMP_KEYCHAIN_PWD" build.keychain
# 解码仓库存储的p12证书
echo "$CSC_LINK" | base64 --decode > cert.p12
# 导入证书到钥匙串，显式授权codesign工具访问私钥
security import cert.p12 -k build.keychain -P "$CSC_KEY_PASSWORD" -T /usr/bin/codesign
# 放行所有签名工具的私钥访问权限
security set-key-partition-list -S apple-tool:,apple: -s -k "$TEMP_KEYCHAIN_PWD" build.keychain

如果导出p12时没有勾选完整证书链，可额外将Sectigo颁发证书时邮件附件里提供的中间CA证书单独导入到该钥匙串，补全从叶子证书到根证书的信任路径。

3. 常见避坑点 #

• 不要依赖GitHub Runner默认的系统钥匙串，默认钥匙串的权限配置不适合CI非交互场景，很容易触发errSecInternalComponent权限报错
• 不要将仅包含公钥的.cer格式证书存入CSC_LINK，必须是包含私钥、完整证书链的p12格式文件
• 不要仅依赖electron-builder的自动证书导入能力，框架默认的导入逻辑没有完成CI环境下的钥匙串权限配置，很容易触发权限类报错，必须显式完成上述钥匙串初始化流程
• 部分旧版本的macOS Runner内置的信任链不覆盖最新的Sectigo根CA，哪怕证书是有效的，也需要手动导入对应的中间证书补全链路

内容的提问来源于stack exchange，提问作者zmbq