开启NuGet签名验证后OpenShift构建过慢及NU3018/NU3034报错问题

问题根源 #

• NU3018错误是因为证书吊销列表（CRL）服务器无法访问，导致签名验证时的吊销检查超时，这直接造成了构建耗时暴增。
• NU3034错误则是NuGet无法信任包的签名，要么是你配置的可信签名者指纹未生效，要么是构建环境缺少签名对应的根/中间证书链。

运维侧解决步骤 #

1. 先解决构建耗时问题（同时保留签名验证） #

直接在OpenShift构建配置中添加环境变量：

DOTNET_NUGET_SIGNATURE_VERIFICATION_MODE=accept

这个模式会跳过吊销检查，但仍会验证签名本身的有效性，既能满足签名验证要求，又能把构建时间压缩回正常水平。如果业务强制要求必须检查CRL，需要排查集群网络是否能访问证书里的CRL分发地址，可能要调整网络策略或代理配置。

2. 修复NU3034签名信任问题 #

• 获取证书束文件：objsign-ca-bundle.pem是包含可信签名者证书及其根/中间证书的组合文件，你需要找开发团队要：
  • 他们配置的可信签名者的证书（.cer或.pem格式）
  • 如果是内部NuGet源的签名，还要拿到内部CA的根证书
• 部署证书到构建环境：
  • 方式一：自定义S2I构建镜像，在镜像构建阶段把合并好的pem文件拷贝到/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
  • 方式二：在OpenShift中创建包含该pem文件的Secret，然后在构建配置里挂载这个Secret到对应路径；或者用构建的postBuild脚本临时把证书拷贝到目标位置
• 注意设置证书文件权限为644，所有者为root，确保NuGet能正常读取。

3. 确认可信签名者配置有效性 #

检查你配置的可信签名者指纹是否完全正确，必须和签名证书的SHA256指纹完全匹配（NuGet一般用小写格式）。可以让开发团队先在本地测试他们的签名配置是否能正常验证，避免配置本身出错。

关于nuget.config的需求 #

需要开发者提供项目使用的nuget.config文件，里面包含<trustedSigners>节点的可信签名者配置。你可以通过以下方式集成到构建环境：

• 让开发者把nuget.config放到应用源码根目录
• 或者创建包含该文件的Secret，挂载到构建镜像的/opt/app-root/src/.nuget/NuGet/路径（对应S2I镜像的用户主目录）
  这样构建时NuGet会自动读取配置，应用可信签名规则。

内容的提问来源于stack exchange，提问作者Ondřej Kareš