OpenSSL 1.1.1l RPM升级全流程实战：构建、依赖检查与回滚

后台收到一个升级工单：把一批存量服务器的 OpenSSL 从 1.1.1 系列升到 1.1.1l，采用 RPM 方式。这个操作看起来简单——下载个包、rpm -Uvh 一把梭，但实际上坑不少。OpenSSL 是系统最底层的加密库，一半以上的服务都链着它，升级不当轻则服务起不来，重则 sshd 都连不上。这篇文章把整个升级流程从头到尾拆一遍，包括怎么判断当前版本、怎么选升级方案、怎么构建 RPM、怎么处理依赖、怎么验证和回滚，以及我实际踩过的几个典型问题，给准备做同样操作的同学一个参考。

1. 升级前的版本确认与方案选型

1.1 先搞清楚“升的是什么”

在动手之前，第一步永远是确认现状。很多机器上跑着的 OpenSSL 版本五花八门，有的是系统自带的基础版本，有的是某个应用自编译的版本，甚至同一个系统里可能存在多份 OpenSSL。如果不先摸清楚，升级完发现业务用的根本不是系统这个库，那就白忙活一场。

确认当前版本用一条命令就够了：

openssl version -a

这条命令不只是显示版本号，还会把编译参数、OpenSSLDir、证书路径、引擎目录等信息一并打出来。比如你要看它链接的是哪个 libcrypto、前缀目录是什么，都能在这里看到。配合which openssl和ldd /usr/bin/openssl，基本能定位出系统默认的 OpenSSL 到底是从哪来的、依赖哪些库文件。

在 RHEL/CentOS 系系统里，正常情况下/usr/bin/openssl对应的是openssl这个 RPM 包，核心库文件则分别在openssl-libs和openssl-devel里。用下面一组命令可以快速理清包归属：

rpm -qf /usr/bin/openssl rpm -qf /usr/lib64/libssl.so.1.1 rpm -q openssl openssl-libs openssl-devel

1.2 升级方案选哪个

OpenSSL 升级常见的有三种路线：第一种是用发行版软件源里的更新包直接更新，第二种是到官网下载源码自己编译安装到 /usr/local 下，第三种就是把官网源码打成 RPM 包再替换系统包。我这次选的是第三种，原因很直接：用 RPM 管理可以让系统的 rpm 数据库始终知道 OpenSSL 的状态，后续查询、升级、卸载都方便，而且不会污染到 /usr/local 这种独立目录。

源码编译装到 /usr/local 的方案我最早也试过，但它有几个问题很麻烦：一是系统原有 RPM 包还在，库里同时存在多个 OpenSSL，ldd检查时到底链到哪个会出现混乱；二是 /usr/local 路径的库不在系统的默认搜索路径里，很多服务加载不到，或者需要手工改 ld.so.conf 和 PATH，运维上非常难管理；三是卸载时没有统一记录，收尾很啰嗦。RPM 方式把这些都规避了——它和系统自带的包是同一套管理机制，升级、依赖、回滚都一起管了。

不过 RPM 方案也有代价：官网源码的 RPM 打包 spec 文件需要自己维护，编译参数也得自己确认。后面我会把 spec 的关键写法展开讲。如果现场情况不允许自己构建 RPM，也可以先查一下发行版自带的较新版本包是否能满足需求——比如某些仓库里自带 1.1.1k 或 1.1.1l 的更新，直接yum update openssl就完事。但前提是仓库里有这个版本，而且你的系统还在维护期内。没有现成包的时候，自己构建 RPM 就是最可控的路。

2. 升级前必做的依赖与风险体检

2.1 找出“谁在依赖 OpenSSL”

OpenSSL 几乎和系统里一半以上的服务都有关系。升级前必须知道哪些东西链着它，否则新包装上去，旧服务的动态链接若指向旧库，很可能直接起不来。我在实际操作中发现，最容易被忽略的是那些并不直接调用openssl命令、但在内部使用 libcrypto 或 libssl 的程序，比如 Python、Perl、curl、wget、各种数据库客户端和中间件。

收集依赖关系我通常用rpm的反查功能：

rpm -q --whatrequires openssl-libs rpm -q --whatrequires libssl.so.1.1()(64bit) rpm -q --whatrequires libcrypto.so.1.1()(64bit)

--whatrequires会把所有声明依赖这些包的 RPM 都列出来。输出结果通常很长，关键是关注那些静态编译、通过网络对外提供服务、或者配置了开机自启的组件。systemctl list-units --type=service --state=running配合上面列出的包名交叉比对，基本能圈出高风险服务。

另外那些用源码编译装到/usr/local的 Nginx、Apache、MySQL 不在 RPM 数据库里，rpm 反查看不到。这些要手工用ldd去检查链接目标：

ldd /usr/local/nginx/sbin/nginx | grep ssl

如果看到libssl.so.1.1 => /usr/lib64/libssl.so.1.1，说明它链接的是系统库，升级会影响它；如果是/usr/local/openssl/lib/libssl.so.1.1这类路径，那它走的是自己的版本，升级系统库不直接冲击它，但证书路径和加密套件兼容性仍要留意。

2.2 预判升级风险点

OpenSSL 升级最怕的是 ABI 不兼容和符号缺失。1.1.1 系列内部的小版本升级（比如 1.1.1a 升到 1.1.1l）基本保持 ABI 稳定，风险比跨大版本低很多，但不是零风险。服务如果用了比较冷门的 API，或者直接调用了部分内部符号，小版本升级也可能出现运行时报错。

此外还有几个容易被忽略的点：

• 证书路径问题：新版 OpenSSL 的默认证书目录是/etc/pki/tls/certs，如果之前手动改过编译参数或环境变量，升级后可能找不到 CA 证书，导致 HTTPS 请求失败。
• 引擎模块不匹配：有些系统加载了硬件加速引擎或第三方引擎模块，这些引擎是和 OpenSSL 版本编译绑定的，升级后引擎加载不上会直接报错。
• 编译期的宏定义：部分应用在编译时会自动探测 OpenSSL 版本并启用新特性，升级后行为变化，比如某些加密套件默认开关发生变化。

为了尽量降低风险，我在实际操作前会做两件事：一是找一台配置相同、业务量较小的测试机完整走一遍升级流程；二是把当前 OpenSSL 的编译参数完整保存下来：

openssl version -a | tee /tmp/openssl_before_upgrade.txt

后面构建 RPM 时，配置参数尽量兼容原有环境的路径和一些关键编译选项，避免服务在依赖路径上发生意外变化。

3. 构建 OpenSSL-1.1.1l RPM 包的完整过程

3.1 准备构建环境和目录结构

在 RHEL/CentOS 系系统上构建 RPM 时，需要安装 rpm-build、gcc、make、perl 等工具。通常用这个命令一次装齐：

yum install -y rpm-build gcc gcc-c++ make perl-core

有了 rpm-build 之后会自动生成家目录下的rpmbuild目录结构。如果没生成或想调整，可以手动创建标准布局：

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

从官网下载 OpenSSL 1.1.1l 的源码包（tar.gz 格式）放到~/rpmbuild/SOURCES里。这里需要重点注意：源码包的校验值一定要核对，和官方公布的 SHA256 比对一致后再使用，省得建筑过程中被注入额外代码或文件损坏导致编译失败。

如果直接用官网 tar.gz 自带的 spec 配置，通常还需要额外处理许可证文件、docs 目录等，比较繁琐。我实际用的方式是把系统自带的 openssl 源 RPM 里的 spec 文件提取出来，然后在此基础上改版本号、修改编译参数，这样能最大程度保留系统原有的安装路径和目录习惯。

yum install -y yum-utils yumdownloader --source openssl rpm -ivh openssl-*.src.rpm

解包后~/rpmbuild/SPECS/下就会出现现成的 openssl.spec。这个文件继承了系统已有的安装习惯，比从零写 spec 稳得多。

3.2 spec 文件的几个关键改动点

提取出来的 spec 文件里，需要修改的内容主要有以下几处。

版本号位置通常长这样：

Version: 1.1.1l Release: 1%{?dist}

如果是自己打的测试包，Release 可以保持1，生产环境建议单独加上自定义标记，比如1.el7_sec，避免和官方未来的升级包冲突。

%configure段落里的编译参数是核心。我用的参数尽量贴近系统默认，同时又补了几个常用的安全增强项：

%configure \ --prefix=/usr \ --openssldir=/etc/pki/tls \ --libdir=/usr/lib64 \ shared \ zlib-dynamic \ enable-cms \ enable-md2 \ enable-ec_nistp_64_gcc_128 \ no-mdc2 \ no-ec2m \ no-sm2 \ no-sm4 \ no-ssl3 \ no-ssl3-method \ enable-tls1_3 \ enable-rfc3779 \ enable-idea \ enable-camellia

这些参数的含义逐个说清楚：

• --prefix=/usr和--libdir=/usr/lib64保证安装目录和系统原包一致，服务不用改路径就能找到库。
• --openssldir=/etc/pki/tls保持系统原有的 OpenSSL 数据目录，证书路径不变化。
• shared表示构建共享库，这是绝大多数应用加载 OpenSSL 的前提。如果只编译静态库，后面一堆服务都会出问题。
• zlib-dynamic让 OpenSSL 动态链接系统的 zlib，避免静态链入导致潜在兼容性问题。
• enable-tls1_3显式开启 TLS 1.3。1.1.1 默认就支持 TLS 1.3，但显式写出来能保证编译配置清晰。
• no-ssl3和no-ssl3-method禁用 SSLv3，这个是安全和合规双重要求。如果公司内部有老客户端必须走 SSLv3，这里要评估后再改，不过业界早就不再建议使用了。
• enable-ec_nistp_64_gcc_128是在 64 位平台对特定椭圆曲线做优化，让 ECDHE 性能更好，实测新一点的 CPU 上握手性能会有改善。

%install段里要注意保留 openssl 命令和 man page 的安装。有些精简 spec 会漏装文档，后续排查问题时 man 手册全没了，很不方便。

%post和%postun脚本段一般要执行ldconfig -p或ldconfig来刷新共享库缓存。这个细节特别容易被忽略，不执行的话即使 RPM 装好了，运行时也可能加载不到新的 libssl 库。

3.3 使用 rpmbuild 构建并解决卡点

一切配置完成后开始构建：

cd ~/rpmbuild/SPECS rpmbuild -ba openssl.spec

-ba表示同时构建二进制 RPM 和源码 RPM。如果你只是想要二进制包，也可以改成-bb。构建过程中最常遇到的几个问题我顺便列一下，遇到了能少走弯路：

• 缺少 perl 模块。OpenSSL 的构建脚本会用到一些 Perl 模块，最常见的报错是找不到Text::Template。安装对应 perl 模块包就能解决。
• 缺少which命令。别笑，这个在精简容器环境里真是坑。装一下 which 即可。
• spec 默认要求某些测试依赖，可以先临时注释掉%check段跳过测试，等主流程跑通后再决定是否补充测试。

rpmbuild完成后，RPMS/x86_64/目录下通常会有这几个文件：

openssl-1.1.1l-1.x86_64.rpm openssl-devel-1.1.1l-1.x86_64.rpm openssl-libs-1.1.1l-1.x86_64.rpm openssl-perl-1.1.1l-1.x86_64.rpm

3.4 验证 RPM 包的基本信息

安装之前，用 rpm 工具验证包结构、依赖和签名：

rpm -K openssl-1.1.1l-1.x86_64.rpm rpm -qp --requires openssl-libs-1.1.1l-1.x86_64.rpm rpm -qpl openssl-libs-1.1.1l-1.x86_64.rpm

这里的-qp是在不安装的情况下查询包信息。重点确认两件事：一是依赖项是否都能在当前系统满足；二是包里包含的.so.1.1文件是否覆盖了原有系统包的文件列表。如果新包缺少某些原包包含的符号链接文件，安装后会留下隐患。

4. 执行升级安装与系统级验证

4.1 安装前的备份和快照准备

升级 OpenSSL 这种底层的库，必须做好随时回退的准备。建议按下面几层来做：

第一层，弄个虚拟机快照或者容器镜像快照，这是最快速的回滚手段。第二层，把当前的安装包原样备份出来：

mkdir -p /root/openssl_backup for pkg in openssl openssl-libs openssl-devel; do rpm -q "$pkg" >/dev/null 2>&1 && rpm -e --nodeps --justdb "$pkg" --noscripts 2>/dev/null || true rpm -qa | grep "^$pkg-" | xargs -r -n1 rpm -ql >/dev/null 2>&1 done

其实更稳妥的是直接保留原版本的 RPM 文件。先查出当前版本对应哪个 RPM：

rpm -qa | grep -E '^(openssl|openssl-libs|openssl-devel)-'

然后到系统安装源或者 /var/cache/yum 里把对应版本的原 RPM 包拷出来留好。万一升级失败，直接rpm -Uvh --oldpackage装回旧包即可。

生产环境我还会额外停掉非关键业务、降低负载后再操作，尽量避免在业务高峰期做这种底层库升级。

4.2 安装顺序和依赖处理

升级 OpenSSL 推荐的顺序是openssl-libs先行，然后是openssl命令包，最后是openssl-devel。原因很简单：libs 是基础，命令依赖库，devel 依赖前面两个。一次性安装更省事：

cd ~/rpmbuild/RPMS/x86_64 rpm -Uvh openssl-libs-1.1.1l-1.x86_64.rpm \ openssl-1.1.1l-1.x86_64.rpm \ openssl-devel-1.1.1l-1.x86_64.rpm

如果报依赖错误，比如error: Failed dependencies: openssl-libs(x86-64) = 1.1.1k is needed by ...，通常是旧包的某些子包没一起升级。这里不建议直接--nodeps强装，强装会把系统中依赖旧版本的服务裸奔在“库已经换了但 RPM 校验还不知道”的状态，后面想查清楚都难。正确做法是看看报错里缺的依赖是哪个子包，把它也加进升级列表里一次装齐。

遇到openssl命令正在被占用时，rpm 会报file /usr/bin/openssl conflicts或者文本文件冲突。这时先确认是否有进程正占用旧文件、把相关服务暂停，再继续升级。

4.3 升级后的核心验证项

包装完不等于升级完。我用一套标准流程验证，确保系统关键功能正常。

第一步，确认版本和链接库：

openssl version -a ldd /usr/bin/openssl

ldd输出里应该指向/usr/lib64/libssl.so.1.1和/usr/lib64/libcrypto.so.1.1，并且这些库能被正常加载，不能出现not found。

第二步，用openssl命令做一次基础加解密和连通性测试：

echo "test" | openssl enc -aes-256-cbc -e -pass pass:secret | openssl enc -aes-256-cbc -d -pass pass:secret openssl s_client -connect www.example.com:443 -brief < /dev/null

第一条命令验证加解密功能没有缺失，第二条验证 TLS 握手能成功访问公网站点。实际生产环境建议用你的真实业务域名：openssl s_client -connect your-api.example.com:443 -servername your-api.example.com，同时关注握手协议版本和加密套件是否正常。

第三步，检查动态链接有没有异常：

ldconfig -p | grep -E 'libssl|libcrypto'

确保 ldconfig 缓存已把新库路径登记好。如果这里看不到新版库，赶紧跑一遍ldconfig刷新缓存。

第四步，检查关键服务状态。优先检查 sshd、Nginx、Apache、Postfix 等与加密链路关系重的服务：

systemctl status sshd nginx postfix ss -lntp | grep -E ':(443|22|25)'

如果服务启动失败，先看日志：

journalctl -u sshd --since "10 minutes ago" --no-pager tail -n 50 /var/log/messages | grep -i error

第五步，回归测试核心业务接口。这一步必须做，不能省。即使是同一版本大版本内的升级，加密套件和证书处理也可能出现细微差异。

4.4 升级后的一些收尾处理

升级完成后，还要确认新版 OpenSSL 的配置文件路径不变、证书目录正常。检查一下：

ls -l /etc/pki/tls/certs/ca-bundle.crt openssl version -d

如果OPENSSLDIR变成了/usr/local之类，说明编译参数里的--openssldir没设对或没生效，需要回看 spec。此时证书链验证大概率会出问题，因为系统默认 CA 包路径在/etc/pki/tls，新版却去/usr/local找证书。

如果系统原本在某些应用里手工配置了自定义 CA 证书路径，升级后也要逐个检查，别指望默认目录能自动覆盖所有场景。

5. 升级过程中遇到的常见问题与排查实录

5.1 升级后服务报“libssl.so.1.1: cannot open shared object file”

这是升级 OpenSSL 后最常见的错误。用systemctl启动某个服务时报错，提示找不到 libssl 的共享库。出现这个问题的原因通常是 ldconfig 缓存没有刷新，或者新装的 libssl 文件路径不在动态链接器的搜索范围内。

排查步骤如下：

• 用find /usr/lib64 /lib64 -name 'libssl.so.1.1'确认库文件是否真实存在。
• 用ldconfig -p | grep libssl看缓存里是否有该库的登记。
• 如果没有登记，执行ldconfig刷新；如果刷新后还是没有，检查文件的符号链接是否完整，正常应该存在libssl.so.1.1这个文件，libssl.so则通常指向它。
• 最后用ldd /path/to/service_binary | grep ssl逐个检查服务二进制。

快捷测试命令：

ldconfig openssl version -a

如果在刷新缓存后依然报错，就要看看是不是服务的 systemd unit 里设置了私有/tmp或受限的LD_LIBRARY_PATH，这种配置会阻止服务加载系统库。检查/etc/systemd/system/下对应 unit 文件里是否有PrivateTmp=true、Environment=LD_LIBRARY_PATH=...等配置，结合实际情况调整。

5.2 编译其他软件时提示找不到 OpenSSL

升级之后，某些软件在从源码编译时会报类似：

checking for openssl... no configure: error: OpenSSL not found

但明明/usr/bin/openssl存在，版本也正确。这里要明白：./configure脚本找 OpenSSL 不是靠命令，而是靠头文件和库文件。找不到头文件往往是openssl-devel包没装或没升级，需要确认/usr/include/openssl/ssl.h是否存在，位置是否正确。如果头文件存在，那就是库路径问题，要把/usr/lib64加进LD_LIBRARY_PATH或者明确指定--with-ssl=/usr参数。

在 CentOS 7 之类系统上编译某些软件还会遇到openssl-devel依赖旧版本库的怪圈，比如error: openssl-devel(x86-64) = 1.1.1k is needed by ...。这时把openssl-devel也一起升级到 1.1.1l，问题就迎刃而解。

5.3 证书校验失败，提示 unable to get local issuer certificate

升级后如果客户端访问自己公司内部系统时出现证书链验证失败，多半是 CA 证书路径或证书格式问题。新版 OpenSSL 对证书链校验更严格，对证书扩展项的检查也更仔细，以前“能用就行”的证书可能在新版这里就过不去了。

排查方向：

• 确认当前 OpenSSL 的OPENSSLDIR指向哪里，openssl version -d查看。
• 把系统 CA 包更新到最新：update-ca-trust。
• 如果是自建 CA 签发的内部证书，确认服务器下发了完整的证书链，而不仅是站点证书。

5.4 多个 OpenSSL 并存时的版本之争

系统里同时存在/usr/bin/openssl和/usr/local/bin/openssl时，shell 到底执行哪个取决于 PATH 顺序。/usr/local/bin在 PATH 里排在前面时，你运行openssl version看到的可能还是旧版本。这类问题看起来像是升级失败，其实只是工具路径的问题。

解决方式是统一管理，不建议长期保留两套平台。如果业务确实需要一个新版 OpenSSL 单独测试，把它放到独立目录并通过环境变量引用即可，不要把/usr/local/bin直接加到全局 PATH 里。我见过某些同事图省事把/usr/local/bin放到/etc/profile的全局 PATH，结果全系统命令版本混乱，排查浪费了好几天。

5.5 常见问题速查表

6. 升级后还需要关注的几个细节

OpenSSL 升级不是装完包就结束的。它像一个底层地基，影响范围比表面上看到的广。

第一件要关注的是密码学策略。1.1.1 系列对旧加密算法的容忍度比 1.0.2 低得多，不少老的 RC4、3DES 套件被移到低位或被禁用。如果系统里还有老旧的客户端程序，升级后可能出现握手失败。排查时可以用openssl ciphers -v 'DEFAULT'查看当前默认支持的套件列表，对比业务需求做微调。

第二件要关注的是应用自身是否缓存了加密库。像 Apache 的 mod_ssl，Nginx 的 http_ssl_module，Python 的一些 C 扩展，这些模块在编译时链了 OpenSSL，但很多是动态加载的，升级系统库后会自动使用新库。可有些应用会把自己的私有 OpenSSL 副本静态链进去，这时候升级系统库实际影响不到它，需要单独升级应用本身。

第三件要关注的是监控。升级后一周内建议把涉及 TLS 握手成功率、证书过期、加密协议版本分布的指标盯一下。我之前遇到过一次升级后某些老用户的内网浏览器访问失败，就是因为新版默认不再支持 TLS 1.0，而客户端浏览器配置还停留在老版本上。这个问题在升级前没暴露，升级完第二天就爆发了，还好有灰度窗口及时处理。

7. 给准备做 OpenSSL 升级的运维同学的一些体会

做了几次 OpenSSL RPM 升级之后，我的整体感受是：这个事真的不能急，也不能图省事直接一条 rpm -Uvh 了事。升级前把环境摸清楚的时间绝对值得花，尤其是搞清楚系统里有哪些服务在依赖 OpenSSL、它们各自链的是哪个库。这个东西不出问题则已，一出问题就是大面积瘫痪。

几个经验性的建议：

• 先在完全等价的测试环境完整走一遍，包括升级、验证、回滚三个环节都测试，不要只测升级不测回滚。
• 构建 RPM 时优先从系统源码包提取 spec，在此基础上改版本和参数，这样能在最大程度上保留系统原有的目录结构和编译习惯。
• 升级安装时把openssl、openssl-libs、openssl-devel作为一个整体来更新，不要只更新其中一个，版本错位是最常见的依赖报错来源。
• 装完后不要急着退出，把ldconfig、openssl version -a、关键服务systemctl status都过一遍，确认链路完整了再继续下一步。
• 回滚方案在动手之前就写好。RPM 方式升级的回滚相对简单，保留好旧包，发现重大问题后用rpm -Uvh --oldpackage装回去，再重启相关服务即可。

最后再提一个小细节：升级完成后顺手把旧版本的源码包和新构建的 RPM 归档到一个固定目录，标注好日期和版本。下次再遇到环境排查、等保检查之类的事情时，这些记录能帮你省不少事。个人维护的服务器尤其建议这么做，两个月后你可能完全忘了当时升的是什么版本、用了什么参数，但归档文件不会骗人。