安装 Jenkins 时，下载阶段的 TLS 错误与安装阶段的 RPM 签名错误，属于不同信任层。升级软件、导入密钥或关闭校验，都不应在没有分层定位时一起尝试。

curl 35 说明握手失败，不直接说明根因

curl: (35) SSL connect error

35 对应 SSL/TLS 握手过程中的问题，不是“curl 版本太旧”的专用错误码。libcurl 错误码

先记录客户端和 TLS 后端版本：

curl --version

再核对目标主机、代理、系统时间、信任材料和服务端要求。使用一个已确认的官方地址做限时连接检查，例如：

curl --head --connect-timeout 5 --max-time 15 https://pkg.jenkins.io/

这是诊断命令示例，不安装软件。HEAD 返回的 HTTP 状态与 TLS 是否建立也要分开判断。需要详细握手日志时，应保护代理凭据、请求头和内部地址；不要用 —insecure 跳过证书检查来“修好”连接。

若确实是客户端或 TLS 库不受支持，应按系统维护流程更新或迁移，而不是下载来历不明的二进制替换。

RPM 公钥缺失与签名无效不是一回事

现象继续确认
找不到验证公钥，如 NOKEY包签名对应哪把密钥，来源及指纹是否可信
包没有签名是否来自预期渠道，该渠道是否应提供签名
签名或摘要不正确包是否损坏、被修改，或使用不匹配的验证材料

对已经通过受信任渠道取得的包，可以只检查、不安装：

rpmkeys --checksig --verbose ./jenkins-package.rpm

文件名为示例，命令能力和输出以本机 RPM 版本为准。校验工具利用密钥环验证包中的摘要与签名；有一个本地公钥并不代表其身份已经被你确认。RPM 密钥及签名检查

从官方通道核对仓库与密钥

按目标发行版与 Jenkins 发布通道，核对仓库地址、密钥指纹和安装流程。密钥可能轮换，不把 2018 年的一条地址当作永久配置。Jenkins Linux 安装说明

全局关闭 gpgcheck 或加 —nogpgcheck，只会停掉验证，不能证明这个包安全。若无法验证来源，应停止安装并重新取得可信包，而不是为了通过安装而绕过安全检查。