简介：OpenSSL 1.1.1离线安装包专为无法直接联网的内网服务器或开发环境准备，省去从源码编译时反复拉取依赖的麻烦，解决离线部署TLS/SSL基础组件难的问题。压缩包内为完整OpenSSL 1.1.1源码树，解压后可使用./config --prefix=... --openssldir=...自由指定安装与SSL配置目录，配合make与make install即可完成部署，整个过程不依赖外部网络。包体共2000个文件，大小11.37MB，其中C源文件944个、头文件269个、Perl脚本175个、Pod文档463个，另含configure脚本、Android构建说明及各类测试数据，结构清晰，便于按需裁剪或交叉编译。目前已有942人学习下载，适合内网环境搭建HTTPS/TLS基础组件，也可作为阅读OpenSSL源码、理解加密库架构的参考素材。 搞离线部署的人，尤其是经常跟内网服务器、工控机、国产化环境打交道的兄弟，大概率都在某个周五下午遇到这种场景：应用文档里白纸黑字写着“基于 OpenSSL 1.1.1 编译”，可服务器上默认带的是 1.1.1 的某个小版本，或者干脆是 3.x，一跑起来各种 ABI 不兼容、证书加载失败。这种时候，手上有一个靠谱的 openssl 1.1.1 离线安装包，比什么都有用。这篇文章不扯大道理，直接讲清楚离线包怎么弄、怎么装、装完怎么不把系统搞坏。
滑动得更具体点：适用于三种人。第一种是内网部署工程师，服务器不通外网，只能提前把包装好带进去；第二种是开发环境需要固定 OpenSSL 版本、不能随便升级系统的；第三种就是运维排查“openssl version mismatch”“证书验证失败”这类问题，需要快速在本地起一个干净的 OpenSSL 1.1.1 环境。你会发现，离线安装包的核心不只是“能装上”，而是“装完能用、不冲突、可复现”。
1. 为什么锁定 OpenSSL 1.1.1：版本兼容不是小事
1.1 应用生态的“版本锁”
OpenSSL 1.1.1 是 2018 年发布的 LTS 版本，官方支持到 2023 年 9 月结束，但大量存量项目依然跑在它上面。举个常见例子：某国产数据库的客户端、某个银行证书控件、某个老版本 Nginx 模块，编译时就是对着 1.1.1 的头文件生成的，换到 OpenSSL 3.x 之后，很多 API 被标记为 deprecated，底层 EVP 结构也变了，直接链接轻则告警，重则段错误。
这就像你家门锁是 A 型锁芯，厂家只生产 A 型钥匙；如果你强行换个 B 型锁芯，原来的钥匙就全废了。所以不是 OpenSSL 新版不好，而是业务链路里的其他组件还没跟上，锁死 1.1.1 反而是最省事的选择。
1.2 离线部署的两个核心诉求
离线安装包和在线 apt/yum 安装完全是两种逻辑。在线安装时，包管理器会自动处理依赖关系；离线安装时，最常见的失败原因不是 OpenSSL 本身，而是依赖缺失：缺 Perl、缺 make、缺编译器、缺 zlib 开发库。第一个诉求是“自包含”，最好一个包带齐所有东西，到目标机器上解压即用；第二个诉求是“不污染系统”，尤其不能直接覆盖/usr/bin/openssl和/usr/lib/x86_64-linux-gnu/libssl.so，否则系统包管理器可能直接罢工。
所以这篇文章里的安装方案，统一走“独立目录、独立 PATH、独立动态库”的路子。OpenSSL 装在/opt/openssl-1.1.1或自己指定的目录，跟系统自带版本共存，互不干扰。
2. 离线安装包从哪里来：三个可靠来源
2.1 源码编译：最通用，也最可控
源码编译是离线安装的“万金油”，因为只需要一份 OpenSSL 源码包，以及目标机器上有编译工具链。OpenSSL 官方发布页面提供.tar.gz源码包，文件名类似openssl-1.1.1w.tar.gz。在能联网的机器上下载好，传到内网，然后解压编译。
很多人担心内网机器没有 gcc。这个确实存在，解决方案有两个：一是提前把 gcc、make、perl 的离线安装包准备好，用 rpm/deb 包方式装好；二是如果目标机器实在没有编译器，就选择下面第二种预编译包方案。
2.2 Windows 预编译包：省心但要认准来源
Windows 环境没有系统级 OpenSSL，绝大多数应用工具都自带或依赖预编译版本。常见来源是 SlproWeb 提供的 Win64/Win32 OpenSSL 安装包，以及个别云厂商、软件仓库提供的二进制包。版本格式一般叫 “Win64 OpenSSL v1.1.1w Light”，Light 版只保留核心命令行工具和动态库，Full 版还会带上开发头文件、静态库、文档等。
离线环境下，我通常选择 Light 版即可，除非目标机器上还要编译依赖 OpenSSL 的 C/C++ 程序。需要留意的是，下载时注意校验 SHA256 哈希，防止包被篡改或下载不完整。
2.3 从已有环境“借”一套可用的 OpenSSL
第三种方法比较取巧：找一台已经装好 OpenSSL 1.1.1 的机器，把整个安装目录打包带走。比如/usr/local/openssl-1.1.1或/opt/openssl111，直接tar czf openssl111.tar.gz /usr/local/openssl-1.1.1然后传到目标机器解压。但前提是目标机器 CPU 架构、操作系统发行版尽量一致，至少 glibc 版本不能差太多，否则动态库可能加载不了。
我自己的习惯是：能源码编译就源码编译，这样最干净；预编译包主要用于 Windows 和没有编译器的嵌入式环境；目录拷贝只作为“应急方案”，不推荐作为长期维护手段。
| 来源方式 | 适用平台 | 优点 | 缺点 |
|---|---|---|---|
| 源码编译 | Linux/Unix/macOS | 可控性最强，路径版本完全自主 | 依赖编译工具链，耗时长 |
| 预编译二进制 | Windows 为主 | 免编译，装上即用 | 发行方五花八门，容易下到不完整包 |
| 复用已有目录 | 同构 Linux 环境 | 最快，几分钟搞定 | 受 glibc/CPU 架构限制，易出现兼容性问题 |
3. 实操：Linux 下离线编译安装 OpenSSL 1.1.1
3.1 编译前的依赖确认
有人一上来就./config && make -j8，结果报错Can't locate IPC/Cmd.pm或者POD2MAN not found，一脸懵。这是缺 Perl 模块。OpenSSL 的构建系统借助 Perl 生成部分文件，老系统尤其容易缺。
建议编译前执行一轮确认：
perl -v make -v gcc -v ld -v如果输出都正常，再检查 zlib 开发库是否存在：
ls /usr/include/zlib.h pkg-config --exists zlib缺什么就补什么。离线环境补依赖是另一个话题，但原则一样：提前下载对应发行版的 rpm/deb 包，用rpm -ivh或dpkg -i安装，注意依赖顺序，缺一个就再补一个。实在补不齐 zlib，也可以编译 OpenSSL 时不启用 zlib 压缩，后面会讲到。
3.2 编译参数的选择逻辑
解压源码后进入目录，我的常用配置命令是这样的：
./config --prefix=/opt/openssl-1.1.1 --openssldir=/opt/openssl-1.1.1/ssl shared zlib make -j$(nproc) make install这里每个参数都有讲究。--prefix指定安装根目录，所有二进制、库文件、头文件都会装到这个目录下，不会污染/usr；--openssldir指定 OpenSSL 运行时配置和证书目录，独立设置便于后续管理；shared表示生成动态库.so，很多应用启动时需要加载libssl.so；zlib启用压缩支持，部分协议如 TLS 压缩和 CMS 会用到。
如果你目标环境里没有 zlib 开发库，就把zlib从参数里去掉，直接：
./config --prefix=/opt/openssl-1.1.1 --openssldir=/opt/openssl-1.1.1/ssl shared no-zlib功能上影响不大，绝大多数场景用不到压缩。
3.3 安装后的动态库路径配置
OpenSSL 装好之后，直接用openssl version大概率还是显示系统老版本，因为/usr/bin/openssl在 PATH 里的优先级比/opt/openssl-1.1.1/bin高。解决办法有两种。第一种是临时生效，适合自己测试：
export PATH=/opt/openssl-1.1.1/bin:$PATH export LD_LIBRARY_PATH=/opt/openssl-1.1.1/lib:$LD_LIBRARY_PATH第二种是长期生效，适合服务器正式使用。在/etc/ld.so.conf.d/下新建一个openssl111.conf，写入：
/opt/openssl-1.1.1/lib然后执行ldconfig刷新。这样其他程序运行时也能找到 1.1.1 的动态库。
注意：
make install在 Linux 下默认不会运行ldconfig，如果你不手动配置动态库路径，就算安装成功了，运行时也可能报error while loading shared libraries: libssl.so.1.1: cannot open shared object file。
3.4 验证是否真正生效
安装完别急着走，做三件事确认环境正常：
/opt/openssl-1.1.1/bin/openssl version /opt/openssl-1.1.1/bin/openssl version -a ldd /opt/openssl-1.1.1/bin/openssl第一条看版本，第二条看编译配置和OPENSSLDIR路径，第三条检查动态库是否指向/opt/openssl-1.1.1/lib。如果ldd显示libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1，说明它加载了系统的库，可能是动态库路径配置没生效；正常应该显示指向/opt/openssl-1.1.1/lib。
4. 实操：Windows 下离线部署 OpenSSL 1.1.1
4.1 Light 版还是 Full 版
Windows 下我默认选 Light 版安装包。Light 版麻雀虽小五脏俱全，包含openssl.exe、libssl-1_1-x64.dll、libcrypto-1_1-x64.dll以及基础配置文件。它不带开发头文件和静态库，恰好适合大多数只调用命令行工具或动态库的场景。
如果你需要在 Windows 上编译 C/C++ 程序，比如用 Visual Studio 构建一个依赖 OpenSSL 的项目，那就要装 Full 版，里面带了 include 目录、.lib导入库和示例，省去自己折腾头文件的麻烦。
4.2 安装与免安装两种方式
预编译包一般有 exe 安装向导，双击下一步就行。问题在于离线环境下，安装程序可能要求先装 Visual C++ Redistributable，否则 DLL 加载失败。所以安装之前最好确认目标机器已有 VC++ 运行库。
不想污染系统的话，也可以用 7-Zip 把安装包解压出来，里面的bin目录就是完整可用的。把bin目录加入系统 PATH，或者直接在命令行里切到该目录运行：
openssl version如果提示缺少 DLL，把bin目录里的libssl-1_1-x64.dll和libcrypto-1_1-x64.dll跟 exe 放同一目录，或者注册到系统 PATH 中，问题即可解决。
4.3 自己编译 Windows 版 OpenSSL 的思路
如果官方预编译包不满足需求，自己编译也不难，但准备工作繁琐。需要安装 Strawberry Perl、NASM 和 Visual Studio 的 C++ 工具链。在“x64 Native Tools Command Prompt”中执行：
perl Configure VC-WIN64A --prefix=C:\OpenSSL111 nmake nmake install这个过程比较慢，大概 10-20 分钟。离线环境下，Perl 和 NASM 得提前找好离线安装包，所以除非必须自定义配置，否则还是优先用现成二进制，省时省力。
5. 版本冲突与证书校验问题排查实录
5.1 version mismatch 是怎么产生的
热搜词里有个典型的报错：
openssl version mismatch. built against 30000070, you have 30500050这个数字是 OpenSSL 内部版本号编码。30000070表示 OpenSSL 3.0.7，30500050表示 OpenSSL 3.0.5？不，稍微懂行的朋友会看出十六进制编码。实际上这行报错来自某个程序编译时用了一个版本的头文件，运行时却链接了另一个版本的库文件，头文件和动态库不一致。
最常见的场景是：你用apt install libssl-dev装了一套 3.0.7 的头文件，又在/usr/local编译安装了 3.0.5 的库，编译程序时指定了/usr/local/include，链接时却让ld找到了/usr/lib下 3.0.7 的库。解决思路只有一个：把 include 路径和库路径指向同一个 OpenSSL 安装目录。
我自己的处理步骤是这样的：
- 确认报错程序是哪个：
ldd /path/to/program | grep ssl。 - 查看实际加载的库路径和版本。
- 重新编译，显式指定 CFLAGS 和 LDFLAGS：
./configure --with-openssl=/opt/openssl-1.1.1 export CFLAGS="-I/opt/openssl-1.1.1/include" export LDFLAGS="-L/opt/openssl-1.1.1/lib -Wl,-rpath,/opt/openssl-1.1.1/lib"-Wl,-rpath很重要，它把库搜索路径直接写进可执行文件，避免程序运行时找错库。
5.2 避免污染系统 OpenSSL 的方法
我见过不少同事图省事，直接：
./config --prefix=/usr shared make && make install结果/usr/bin/openssl版本变了，但系统证书路径、Apache、Nginx、Python 的 ssl 模块全跟着出问题，最后只能重装系统或者费半天劲恢复。
正确的做法永远是不覆盖系统自带 OpenSSL。系统自带的 openssl 归包管理器管，你自用的放独立目录。用的时候通过 PATH 和环境变量指定优先使用自用版本，或者直接使用绝对路径调用：
/opt/openssl-1.1.1/bin/openssl s_client -connect example.com:443如果想长期让某个服务用 1.1.1，就给服务配置编译参数或服务配置文件，而不是动全局环境。
5.3 openssl verify -CAfile 的正确打开方式
热词里有“openssl verify -cafile”，其实很容易踩坑。openssl verify 用于校验证书链，正确参数是-CAfile，CA 是大写。常见用法：
openssl verify -CAfile rootCA.crt server.crt如果根证书、中间证书、站点证书都在同一个文件里，也可以直接：
openssl verify -CAfile chain.crt server.crt报错unable to get local issuer certificate，说明-CAfile指定的文件里没有签发者证书，需要把中间 CA 或根 CA 补进去。如果验证本地服务，还可以配合-verify_hostname：
openssl verify -CAfile ca.crt -verify_hostname www.example.com server.crt这个参数会额外校验证书里的域名是否匹配，适合测试证书有没有签发错域名。
提示：
openssl s_client -CAfile用来测试 TLS 握手时的证书链，比如检查某个 HTTPS 站点返回的证书是否完整。很多人把verify和s_client的参数搞混，前者只管本地验证，后者是真实发起 TLS 连接。
6. 常见问题速查与一点实操心得
| 现象 | 原因 | 处理方式 |
|---|---|---|
openssl version显示旧版本 | PATH 顺序不对，系统 bin 优先级更高 | 调整 PATH 或用绝对路径调用 |
error while loading shared libraries: libssl.so.1.1 | 动态库路径未配置 | 写/etc/ld.so.conf.d/openssl111.conf+ldconfig，或设置LD_LIBRARY_PATH |
version mismatch | 头文件和库文件版本不一致 | 统一 CFLAGS/LDFLAGS 指向同一安装目录，必要时加-Wl,-rpath |
make时报POD2MAN相关错误 | 系统 Perl 模块不完整 | 安装 perl、pod2man，或检查 Perl 版本 |
openssl verify报unable to get local issuer certificate | CA 文件里缺少签发证书 | 将根 CA 和中间 CA 合并到-CAfile指定的文件中 |
| Windows 下双击 openssl.exe 闪退 | 缺少 VC++ 运行库 | 安装对应版本的 Visual C++ Redistributable |
最后分享一点个人习惯。我在做离线环境时，会把 OpenSSL 源码包、编译产物、依赖包统一放在一个/opt/software/openssl-1.1.1目录下，目录名里带上完整版本号和编译日期，比如openssl-1.1.1w-20241012。这样后续排查问题时，一眼就能知道这套环境是什么时间、哪个版本、怎么生成的，省去很多“这是我什么时候装的”的追忆成本。
还有个小技巧：离线环境里如果担心以后还要装别的依赖 OpenSSL 的软件，可以在编译 OpenSSL 时顺便生成静态库，也就是去掉shared参数改为no-shared，虽然文件体积更大，但后续编译其他软件时可以直接静态链接，运行时完全不依赖系统里有没有 libssl.so。两者权衡，按需选择。我自己通常两种都会编译一份，动态库用于日常命令，静态库用于交付给第三方做二次开发。这种方式虽然笨，但在真实项目里帮我校验过不少坑。
本文还有配套的精品资源，点击获取
