简介：OpenSSL 1.1.1m 是开源密码库项目于2021年12月发布的最新稳定版源码包，面向 Linux 环境下的开发者、系统管理员与安全运维人员，用于构建 SSL/TLS 加密通信、证书管理以及 RSA、DSA、ECC 等主流密码算法应用，是保障 Web、邮件、FTP 等服务数据安全的核心基础。压缩包采用 tar.gz 格式封装，大小约9.39MB，内含完整的源码与构建配置，已有532人学习/下载。该版本在上一版基础上进行了安全修复与性能优化，修复了若干已知漏洞，增强了密钥交换与防重放能力，可有效抵御中间人攻击等常见威胁。下载后既可直接编译安装到 Linux 系统，作为其他依赖服务的底层加密库，也可利用自带的 openssl 命令行工具完成 s_client 连接测试、genpkey 私钥生成、数字证书签发与验证、哈希计算及消息认证码生成等任务，对生产环境部署、故障排查与密码技术学习均具有参考价值。
1. 为什么我最终选择了 openssl-1.1.1m.tar.gz 源码包
openssl-1.1.1m.tar.gz 这个安装包，在 Linux 服务器运维和开发环境构建这个圈子里，算是相当经典的一个版本了。1.1.1m 是 OpenSSL 1.1.1 系列中一个非常稳定的维护版本，发布时间在 2021 年底左右，修复了当时一批已知的高危漏洞和稳定性问题。很多长期跑生产环境的 CentOS 7、Ubuntu 18.04 系统，默认自带的 OpenSSL 版本还停留在 1.0.2 甚至更早，遇到需要对 HTTPS 证书算法、TLS 1.3 协议支持做升级的场景，或者 PHP、Nginx、Python 等应用在编译时要求更高版本 OpenSSL 的情况，手动下载 tar.gz 源码包编译升级，就成了最直接、最可控的方案。
这个工作适合谁来做？我觉得至少有三类人非常需要：第一类是运维工程师，接手了老的 CentOS 7.6 服务器，需要把 OpenSSL 升级到 1.1.1+ 以支持新版安全协议；第二类是后端开发，编译 PHP 扩展或者自己写 C 程序需要链接新版 libssl/libcrypto；第三类是搞 Python 数据分析或深度学习环境的人，在 conda 环境里创建新环境时，因为部分包对 OpenSSL 有版本要求，被迫去折腾系统级 OpenSSL。我自己第一次折腾这个 tar.gz 的时候，就是因为在 CentOS 7.6 上装一个内部系统，对方明确要求 OpenSSL 必须大于 1.1.1，而系统自带的 yum 仓库里根本没有这个版本，这才不得不走源码编译这条路。
说实话，OpenSSL 源码编译安装本身不算特别复杂，真正坑人的是环境依赖、动态库链接、以及升级后对系统已有服务的影响。这篇文章我就以 openssl-1.1.1m.tar.gz 为线索，把从下载到编译、从安装到验证、从踩坑到修复的完整过程捋一遍，希望你看完能少走些弯路。
2. 版本选型分析：为什么偏偏是 1.1.1m
2.1 版本背景与安全考量
OpenSSL 的版本演进非常讲究，1.1.1 系列目前已经处于长期支持（LTS）状态，官方在 2021 年之后进入了安全维护期，只修安全问题、不增加新功能。1.1.1m 这个子版本，是在 1.1.1l 之后推出的一个修复版本，重点是解决了 CVE-2021-4160 等若干问题，包括关于BN_mod_sqrt、PEM 解析等模块的潜在缺陷。对于生产环境来说，安全修复的价值是实打实的，因为证书解析和加密运算是所有 HTTPS 流量都绕不开的环节。
选择 1.1.1m 而不是更早的 1.1.1k、1.1.1l，或者更新的 3.x 系列，核心原因在于“稳定优先”。当时 3.0 版本刚发布不久，API 变动较大，不少老项目用的还是 OpenSSL 1.1.1 的接口。如果贸然升级到 3.x，编译 PHP 扩展时可能出现OPENSSL_sk_num之类函数找不到的问题，反而增加工作量。所以 1.1.1m 正好卡在功能稳定和漏洞修复之间的平衡点上。
2.2 tar.gz 源码包与包管理器安装的差异
这里多说一句关于“下载安装方式”的选型。在 Linux 上安装软件，通常有两种选择：用 yum/apt 装编译好的二进制包，或者下载 *.tar.gz 源码包自己编译。对于 OpenSSL 这种深度依赖系统底层库的组件，yum 仓库里的版本往往偏旧，而且某些系统还会对软件包做定制化修改，路径也可能被改得和官方默认结构不一致。源码编译则可以精确控制安装路径、编译参数、启用的加密算法，甚至能编出静态库供其他项目链入。
不过源码方式也有代价：你需要提前准备好 gcc、make、perl 等工具链，并且要处理好“旧版本残留”与“新版本共存”的问题。这个共存问题在热词里也出现了——perl is needed by openssl，就是典型的 RPM 包安装时遇到的依赖报错。我建议你结合自身场景决定：如果只是为了临时给某个项目提供新版 OpenSSL，源码编译并指定--prefix安装到独立目录，是最安全的方案；如果是为了系统全局升级，那就要做好准备处理各类服务对 libssl.so 的依赖。
3. 环境准备与依赖检查：先把坑排掉一半
3.1 必备编译工具链确认
在真正执行./config之前，先把编译环境确认好。OpenSSL 1.1.1m 的编译需要 gcc、make、perl，以及 Linux 内核头文件。在 CentOS 7.6 等老系统上，我通常按下面的顺序检查工具：
gcc --version make --version perl --version如果 perl 没有安装，直接安装即可。这里有个容易忽视的细节：有些精简版系统里，perl命令存在，但缺少Pod::Usage、ExtUtils::Embed等模块，编译时会卡住。好在 OpenSSL 官方对 perl 模块的依赖不大，通常系统自带的 perl 版本就能满足，但如果编译中途报错提到关键字Failed和perl，先检查是不是 perl 版本太老或者环境变量PERL5LIB被污染了。
3.2 处理旧版本 OpenSSL 的共存策略
很多教程会直接让你下载源码到/usr/local/src后执行./config --prefix=/usr/local/openssl，然后 make install。但这条路径会引出一个大问题：系统的/usr/lib64里还躺着旧版 libssl.so，你新装的/usr/local/openssl/lib里的库文件不会自动成为默认链接目标。如果直接把新的库覆盖到系统目录，又可能把 yum 依赖的旧库搞崩，导致curl、wget甚至yum都无法正常工作。
所以我的建议非常简单：如果你对系统全局升级没有绝对把握，不要直接覆盖系统库，而是把新版 OpenSSL 安装到独立前缀目录，例如：
./config --prefix=/usr/local/openssl-1.1.1m这样/usr/local/openssl-1.1.1m/bin/openssl就是独立的可执行文件，/usr/local/openssl-1.1.1m/lib是独立的库目录。需要某个应用链入新版库时，通过LD_LIBRARY_PATH或者编译时的-I、-L参数指定即可。如果你确实需要全局升级，那务必做好备份，并且先验证新版库能不能被系统里最核心的服务正常加载，确认无误后再替换/usr/bin/openssl等关键文件。
3.3 下载源码包：官网与国内镜像
openssl-1.1.1m.tar.gz 这个文件的获取渠道，常见的有两个：OpenSSL 官网的源码下载目录（https://www.openssl.org/source/），以及国内的一些镜像站。官网文件是权威的，但如果你所在的服务器网络访问海外站点不稳定，下载速度可能很感人，这时候国内镜像就很有价值了。我常用的方式是先下载到本地再校验 sha256 摘要，确保源码包没有被篡改。
打开官网或者镜像站后，在 source 目录下找到 openssl-1.1.1m.tar.gz 这个文件，下载下来。之后在服务器上解压：
tar -zxvf openssl-1.1.1m.tar.gz cd openssl-1.1.1m解压之后，目录里有Configure、config、Makefile.org等关键文件，还有个INSTALL.md，建议先扫一眼，里面记录了官方推荐的编译步骤和参数说明。源码包本身的完整性检查可以在官网的sha256sum文件里核对，这一小步很多新手会跳过，但我还是建议保留——毕竟 OpenSSL 是基础设施，一旦源码被植入后门，影响范围是灾难性的。
4. 编译安装全流程：从 config 到 make install
4.1 config 参数的选择逻辑
OpenSSL 的config脚本在 1.1.1 系列里已经比较智能了，它会自动探测当前系统的处理器类型、操作系统版本和编译器特性。但有些参数必须根据你的实际需求指定。我用过的组合比较多，这里给出两个典型场景：
场景一：独立安装，不干扰系统默认版本。
./config --prefix=/usr/local/openssl-1.1.1m --openssldir=/usr/local/openssl-1.1.1m/ssl shared zlib--prefix：指定安装根目录，后续所有文件都会放在这个目录下。--openssldir：指定 openssl 配置文件（openssl.cnf）、证书目录等文件的存放位置。shared：生成动态库 libssl.so 和 libcrypto.so，这是绝大多数应用链入所必需的，不要省略。zlib：启用压缩支持，用于 TLS 记录压缩，如果你的系统没有安装 zlib-devel，这个参数会导致编译失败，可去掉。
场景二：尽量兼容系统默认路径（适合想要全局替换的场景，但不推荐新手直接试）。
./config --prefix=/usr --openssldir=/etc/pki/tls shared zlib这种方案会将库文件装到/usr/lib或/usr/lib64下，直接覆盖系统自带的 OpenSSL 库。风险非常大，因为很多系统工具（比如 yum、curl、openssl command）已经链接了旧版 soname，新版库的 soname 是libssl.so.1.1而旧版可能是libssl.so.10，一旦替换，这些工具会直接报错找不到库文件。所以如果你只是学习或测试，优先使用独立安装路径。
4.2 make 与 make install 的常见问题
配置完成后，执行：
make -j4 make install-j4表示并行编译，利用多核 CPU 加速。不过要注意，如果在 4 核以上的机器上并行编译，偶尔会出现make: *** [apps/openssl] Error 1这类随机报错，多半是因为内存不足或并发竞争导致。遇到这种情况，先执行make clean，再改用make -j1单线程编译，通常就能顺利通过。
make install执行完之后，检查/usr/local/openssl-1.1.1m/bin/openssl是否存在，同时查看一下库文件是否生成：
ls -l /usr/local/openssl-1.1.1m/lib/libssl.so* ls -l /usr/local/openssl-1.1.1m/lib/libcrypto.so*如果这两个动态库存在，说明核心安装已经成功。接下来就是配置动态链接器，让系统能找到新版库。这一步特别关键，很多人在安装后运行openssl version发现版本没变，就是因为路径配置没做。
4.3 动态库链接配置与版本验证
为了让/usr/local/openssl-1.1.1m/lib目录下的库文件能被系统找到，需要编辑/etc/ld.so.conf.d/下的一个新建配置文件。我通常创建/etc/ld.so.conf.d/openssl-1.1.1m.conf，内容就一行：
/usr/local/openssl-1.1.1m/lib然后执行：
ldconfig执行ldconfig -p可以看到新的 libssl.so.1.1 是否已经被系统缓存。接着验证 openssl 命令：
/usr/local/openssl-1.1.1m/bin/openssl version如果输出OpenSSL 1.1.1m 14 Dec 2021之类的内容，说明编译安装成功了。但这里一定要意识到：系统的/usr/bin/openssl还是旧版本，你刚安装的新版本是独立的。想让全局默认 openssl 命令指向新版，可以把新版本放在 PATH 的前面，或者直接替换/usr/bin/openssl。我个人的经验是，除非明确知道自己在做什么，否则不要动/usr/bin/openssl的软链接，因为 yum 等工具在安装 RPM 包时会对 openssl 有依赖检查，你把软链接指到自定义路径，可能导致 RPM 校验失败。
如果想确认应用能否加载新版库，可以用ldd命令：
ldd /usr/local/openssl-1.1.1m/bin/openssl输出里会显示libssl.so.1.1 => /usr/local/openssl-1.1.1m/lib/libssl.so.1.1，这就说明库链接正确。
5. 典型报错场景与排查实录
5.1 perl is needed by openssl 报错分析
热词里出现的perl is needed by openssl这条报错，是我在 CentOS 7.6 上通过 rpm 方式安装 openssl 时经常遇到的。这个报错来自 RPM 依赖检查，意思是当前系统缺少 perl 依赖包。虽然源码编译不需要 rpm，但如果你尝试用rpm -ivh openssl-...rpm安装官方二进制包，就会触发这个检查。解决办法很简单：先安装 perl 再装 openssl rpm，或者用rpm -Uvh --nodeps强制安装（但我不建议，容易引发其他问题）。
如果是源码编译却遇到类似“perl not found”或“perl module not found”，需要确认正确定位 perl 解释器路径，以及在编译时设置PERL5LIB环境变量。通常情况下：
yum install -y perl perl-devel就能解决 90% 的 perl 相关问题。对于源码编译，./config脚本本身是用 perl 写的，如果 perl 缺失，第一步就直接报错退出。
5.2 openssl error:0a000126:unexpected eof while reading
这是另一个热词里出现的报错。error:0a000126:ssl routines::unexpected eof while reading通常出现在使用新版 OpenSSL 作为客户端连接服务器时，服务器端异常关闭了 TLS 连接。这个报错在升级 OpenSSL 后尤其常见，因为新版对 TLS 协议的处理更加严格，服务器如果发送了不完整的 TLS 握手响应，旧版可能忽略，新版直接报错。
排查这类问题的思路是这样的：
- 先用
openssl s_client -connect 目标域名:端口命令手动测试，观察握手过程中在哪一步断开。 - 用
-tls1_2、-tls1_3分别指定协议版本，判断是不是协议版本不匹配。 - 查看服务器端是否要求特定证书或客户端证书，若要求但未提供，也可能触发 EOF 报错。
如果你是在 PHP 的 curl 扩展里遇到这个报错，可以在代码里临时设置CURLOPT_SSLVERSION指定 TLS 版本，或者检查服务器端的 SSL 配置是否支持你使用的协议。这类问题的根源大多数不在本地 OpenSSL，而在于目标服务器的 TLS 栈配置有缺陷。
5.3 configure 时版本探测不匹配：100020bf
热词里还有个checking openssl header version... 100020bf (openssl 1.0.2k 26 jan 2017)，这个出现在很多需要链接 OpenSSL 的第三方软件编译过程中，比如 Nginx、PHP 扩展等。它的意思是，编译工具在检查 OpenSSL 头文件版本时，发现头文件是 1.0.2k，而你希望链接到新安装的 1.1.1m。出现这个问题的根本原因，是编译器的头文件搜索路径还指向了旧版 OpenSSL 的 include 目录，而不是你新装的/usr/local/openssl-1.1.1m/include。
解决办法是在编译第三方软件时，显式指定：
./configure --with-openssl=/usr/local/openssl-1.1.1m以 PHP 为例，重新编译 PHP 时：
./configure --with-openssl=/usr/local/openssl-1.1.1m ...同时还需要保证 PEAR 的 openssl 扩展路径正确。如果你用的是 CMake 项目，可能需要设置OPENSSL_ROOT_DIR和OPENSSL_INCLUDE_DIR指向新路径。这个问题的核心只有一个：编译链接时的搜索路径必须指向新安装的位置，否则系统自动找到的还是旧版本头文件，版本探测自然就停留在 1.0.2k。
5.4 conda 环境中的 tar.gz 与 OpenSSL 版本冲突
热词里提到了conda 环境tar.gz创建环境，这个场景我也遇到过。conda 在创建新环境时，会下载安装一套自己的 OpenSSL 动态库，这套库通常位于 conda 环境的lib目录下。如果你在 conda 环境里需要某个包编译链接系统级 OpenSSL，可能会出现版本冲突，比如 conda 环境里的库版本过低，而你的源码包需要 1.1.1+。
我的建议是：在 conda 环境里，尽量优先使用conda install openssl来更新环境内的 OpenSSL 版本，而不是强行把环境外的 openssl-1.1.1m.tar.gz 编出来的库塞进 conda 环境。因为 conda 环境内部的动态链接路径是硬编码在RPATH里的，外部手动装库很容易破坏环境一致性。如果确实需要外部源码包，可以通过设置CONDA_PREFIX和LD_LIBRARY_PATH绕行，但排查复杂度会明显上升，不建议在没把握的情况下这样做。
5.5 常见问题速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
perl is needed by openssl | RPM 安装时缺少 perl 依赖 | 安装 perl 和 perl-devel，或改用源码编译 |
error:0a000126:unexpected eof while reading | 服务器端 TLS 栈异常关闭连接 | 用 s_client 测试，调整 TLS 版本或检查服务器配置 |
checking openssl header version... 100020bf | 编译器头文件路径指向旧版本 | 显式指定--with-openssl=/usr/local/openssl-1.1.1m |
make: *** [apps/openssl] Error 1 | 并行编译资源竞争 | make clean后改为make -j1 |
openssl: error while loading shared libraries: libssl.so.1.1 | 动态库路径未配置 | 在 ld.so.conf.d 下添加路径并执行ldconfig |
| conda 环境中 OpenSSL 版本无法识别 | conda 环境内部库与系统库冲突 | 优先使用conda install openssl更新内部库 |
6. 升级后的影响范围与兼容性验证
6.1 对 Nginx、PHP、Python 等应用的潜在影响
当你把 openssl-1.1.1m 装入系统并开始被其他应用链接，影响面会迅速扩大。Nginx 在编译时如果指定了--with-http_ssl_module和--with-openssl=/usr/local/openssl-1.1.1m，那么它会在编译阶段把 OpenSSL 的静态库直接编入 Nginx 二进制文件，运行时不再依赖系统版本，这是最稳妥的方式。PHP 则不同，它的 OpenSSL 支持是通过扩展方式动态调用的，编译时指定--with-openssl后，动态链接到 libssl.so.1.1，所以如果你替换了系统库，PHP 加载的库版本也会跟着变。
Python 更特殊：有的场景下，Python 的ssl模块在编译时静态链接了特定版本的 OpenSSL，你升级系统 OpenSSL 并不会改变 Python 已经编译好的模块。但很多需要编译 C 扩展的 Python 包（比如 cryptography）会在安装时检测系统 OpenSSL 版本，如果低于要求，会尝试从源码编译绑定自己需要的版本，这时候你系统里的新 OpenSSL 反而可能干扰它的编译。
我的验证经验是：Nginx 改完重新make后，用ldd $(which nginx)查看库依赖，如果是静态编译，输出里不会出现 libssl.so；如果是动态链接，必须确认指向的是新库。PHP 则用php -i | grep 'OpenSSL'查看 SSL Version 字段。对于 Python，可以在虚拟环境里执行：
import ssl print(ssl.OPENSSL_VERSION)如果显示的还是旧版本，说明 Python 内部绑定的是编译时加载的库，不必过度担心。
6.2 soname 变更与系统服务的兼容性陷阱
OpenSSL 1.1.1 系列的 soname 是libssl.so.1.1和libcrypto.so.1.1，而 CentOS 7 系统自带的 OpenSSL 1.0.2 系列的 soname 是libssl.so.10和libcrypto.so.10。这两个系列可以共存而不冲突，因为动态链接器根据 soname 区分版本。这也是我前面建议你不要直接覆盖系统库的底层原因——即使覆盖了，旧版 soname 依然存在的符号不会消失，但新版和旧版如果混装在同一目录，可能出现符号解析错乱。
实际升级中，我遇到过curl命令突然报symbol SSL_library_init, version OPENSSL_1.0.0 not defined in file libssl.so.1.1这类问题，原因就是/usr/lib64下的 libssl.so 被替换，但 curl 还要求旧版符号。所以再次强调：保留系统旧库，安装新版库到独立目录，通过LD_LIBRARY_PATH或编译路径按需引用，是风险最小的方案。
7. 关于 openssl-1.1.1m 安装的最后几点经验
从我历次折腾 OpenSSL 源码包的经验来看，openssl-1.1.1m.tar.gz 这个版本适合作为生产环境的长期稳定版来使用，尤其当你的业务没有升级到 OpenSSL 3.x 的需求时，1.1.1m 在安全性和稳定性之间提供了相当优秀的平衡。
有几个小技巧，我建议你额外记住：
- 编译时尽量指定
-fPIC。OpenSSL 默认生成的库可能不含 PIC 标志，但如果你想后续把它链入其他 C 程序或 Python 扩展，必须启用 PIC。可以配置为./config -fPIC ...。 - 始终保留旧版 openssl 命令的备份。即使你决定用新版替换全局路径，也先执行
cp /usr/bin/openssl /usr/bin/openssl.bak，应对突发问题可以快速回滚。 - 如果你是给内网多台服务器统一部署，可以将编译好的
/usr/local/openssl-1.1.1m目录用 tar 打包分发到其他同架构机器上，再统一配置 ld.so.conf，能节省大量编译时间。 - 检查安全更新。OpenSSL 1.1.1 系列虽然 LTS，但后续也发布了 1.1.1n、1.1.1o 等更多维护版本，如果你的安全合规要求高，建议留意官网更新公告，在条件允许时升级到最新维护版。
我最后一次在生产环境启用 1.1.1m 是在一台承载内部支付回调服务的 CentOS 7.6 机器上，当时 PHP 7.4 的 openssl 扩展需要 1.1.1+ 才能支持 TLS 1.3，但我又不想影响系统其他组件。我用独立前缀编译安装后，只修改了 PHP 的编译参数并重启了 PHP-FPM，Nginx 和 yum 完全没动，运行了几个月都稳稳当当。这就是我反复强调“独立安装路径”这个习惯的根本原因——在基础设施型组件的升级上，少动系统公共区域，往往就是最大的稳定保障。
本文还有配套的精品资源，点击获取
