简介OpenSSL 1.0.2u 源代码包面向需要深入理解 SSL/TLS 协议实现、在自己的应用程序中集成加密能力或在生产环境维护 OpenSSL 服务的开发人员、系统管理员与安全测试人员。1.0.2u 属于 1.0.2 长期维护分支的后续更新版本集中修复了早期版本中公布的多个安全漏洞并针对稳定性与兼容性做了优化适合仍在使用该 LTS 分支的存量系统进行升级、离线部署或安全审计。压缩包大小 5.11MB以 tar.gz 格式打包解压后可得到完整的 OpenSSL 1.0.2u 源码树其中包括 configure 配置脚本、Makefile 构建文件、AES/RSA/DSA 等对称与非对称算法实现以及用于生成密钥、创建证书请求、签名证书的命令行工具源码便于用户根据自身平台定制编译。目前已有 411 人学习浏览。对希望从源码层面理解密码学应用、分析 HTTPS 通信过程或自行构建加密方案的技术人员来说这份源码是一个扎实的起点通过阅读与实验可以清晰掌握 OpenSSL 的目录组织、核心 API 调用方式、证书管理流程和 PKCS#7/PKCS#12 等标准并能够将其灵活运用于 Web 服务、邮件服务、FTP 等常见安全通信场景。1. 为什么 2025 年还有人折腾 openssl-1.0.2u 这个十年前的 tar 包1.1 你手里拿着的是哪个“古董”openssl-1.0.2u.tar 这个文件名老运维一看就知道这是 OpenSSL 1.0.2 系列最后一个正式版本 u 的源码包。1.0.2 系列早在 2019 年 12 月 31 日就全面停止维护了1.0.2u 也是这一系列里最后放出来的一个版本修掉了一批公开漏洞之后就彻底宣告 EOL。拿现在的时间点来算这确实是个不折不扣的“古董”。但古董不意味着没人用。我前两年接手过一个金融行业的遗留交易网关系统还是 CentOS 7 的底子核心服务依赖的某个加密模块只跟 OpenSSL 1.0.2 系做过完整兼容测试升级到 1.1.1 之后握手机制、会话恢复行为全变样一压测就断连。后来流程审批了快三个月结论还是“保持 1.0.2u不做大版本迁移”。这种情况在银行、医疗、制造这些强合规、重稳定性的行业里非常普遍。1.2 手动编译安装而不是 yum install既然老版本有需求为什么不能用yum install openssl或apt install openssl直接装原因有两层。第一层操作系统的软件源里早就把 1.0.2 系列清掉了。CentOS 7 默认源最高只有 1.0.2k但中间一堆安全更新的补丁是红帽自己 backport 进去的你装到的版本虽然显示 1.0.2k实际安全能力可能接近 1.0.2t。可惜官方源把旧版本下线后这种“半官方补丁版”也没法通过常规方式拿到了。第二层不少项目的依赖库比如旧版 PostgreSQL 的某些扩展、老版 Nginx 的 SSL 模块、自研的硬件加密中间件是按特定 OpenSSL 小版本的头文件和库路径编译的。直接换掉系统级 OpenSSL 会引发连锁反应最稳妥的做法就是把 openssl-1.0.2u 编译到一个独立目录里按需加载。所以你会看到很多团队的服务器上同时存在/usr/bin/openssl系统自带新版和/opt/openssl-1.0.2u/bin/openssl手工编译的老版本二者并行不悖。2. 解压之前下载源头、校验和与 tar 包内部结构2.1 从哪里拿 tar 包才靠谱下载 OpenSSL 源码最权威的渠道就是 openssl.org 官网的 source 目录GitHub 上也有官方镜像仓库但发布版的 tar 包签名和校验文件只在官网放。需要说明的是国内访问官网有时候慢得让人抓狂很多人转到各种镜像站下载这就有个隐患——镜像站可能同步不及时也可能被中间人篡改。所以我下载回来第一件事从来不是解压而是先校验。OpenSSL 官方对 1.0.2u 发布的校验文件是openssl-1.0.2u.tar.gz.sha256里面记录了这个 tar 包的标准 SHA256 值openssl-1.0.2u.tar.gz: 57982e0e547a09d0804b79a8afb40b1f8e6e4100a4fe6e1a0f2f5e7503d957f5实际数值以你下载到的官方 sha256 文件为准这里不建议凭记忆背 hash而是应该手动跑一遍比对流程# 下载 openssl-1.0.2u.tar.gz 和它的校验文件到同一目录 curl -O https://www.openssl.org/source/openssl-1.0.2u.tar.gz curl -O https://www.openssl.org/source/openssl-1.0.2u.tar.gz.sha256 # 校验输出必须看到 OK sha256sum -c openssl-1.0.2u.tar.gz.sha256提示如果你所在的网络环境访问不了官网用镜像源下载后一定要找两个独立来源比对 hash。我曾经遇到过一次第三方镜像解压出来的源码编译报错最后定位到是某个头文件被替换过虽然当时没发现恶意代码但这种事只要碰上一次就足够长记性。2.2 tar 包里到底有什么拿到包之后先别急着tar -zxvf我用tar -tzf先瞄一眼里面的顶层目录结构确认包没损坏也能初步判断是不是官方打包格式tar -tzf openssl-1.0.2u.tar.gz | head -20官方源码包解开后顶层目录叫openssl-1.0.2u里面核心内容分这么几块crypto/AES、RSA、SHA、DES 等底层密码算法实现是整个项目的基础编译产物是libcrypto.a和libcrypto.sossl/TLS/DTLS 协议栈实现编译产物是libssl.a和libssl.soapps/openssl 命行工具的源码包括openssl s_client、openssl x509、openssl verify这些常用子命令include/头文件目录第三方程序要链接这个版本的 OpenSSL编译时缺不了它Configure、config、Makefile.org构建脚本和配置模板要注意 1.0.2 时代的源码结构和 1.1.1、3.x 差别很大。3.x 引入了 provider 机制、fips 模块目录结构更清晰1.0.2 很多逻辑直接堆在ssl/下面读代码的时候体验确实差一些。不过在行为特征上1.0.2 也有它的特点默认 TLS 版本是 TLSv1.2不带 TLSv1.3默认密码套件顺序偏向 ECDHE-RSA-AES128-GCM-SHA256 这类组合。如果你要在生产环境保持旧协议行为反而得靠这些老特性。3. 从 openssl-1.0.2u.tar 到可用的 openssl编译安装全流程3.1 依赖准备gcc、make、Perl 一个都不能少编译 OpenSSL 不是解压完直接 make 就能跑对系统工具链有硬性要求。1.0.2u 的构建流程依赖三个基础组件gcc或其他 C 编译器版本建议 4.8 及以上太老的编译器会出现语法不兼容的问题make用于解析 Makefile 执行编译PerlConfigure 脚本是 Perl 写的没有 Perl 整个构建流程直接卡死在第一步在 CentOS 7 上可以用 yum 一次性装齐Debian/Ubuntu 用 apt 对应装# CentOS 7 / RHEL 7 yum install -y gcc make perl # Debian 9/10、Ubuntu 16.04/18.04 这类老系统 apt-get install -y gcc make perl另外建议装一个wget或curl方便拉取源码包。如果你是在内网离线环境操作可以提前把工具链的 rpm/deb 包准备好否则后面编译报错会非常折磨人。3.2 Configure 参数怎么填才不坑1.0.2u 的配置入口有两个脚本config和Configure。config是个包装脚本会自动探测当前系统类型再转发给Configure专业用户更常直接调Configure并手工指定目标平台和参数。我实际生产环境中用的配置命令是这样./Configure linux-x86_64 \ --prefix/opt/openssl-1.0.2u \ --openssldir/opt/openssl-1.0.2u/ssl \ shared \ zlib-dynamic \ enable-ec_nistp_64_gcc_128 \ enable-tls1_2拆开解释几个重点项linux-x86_64目标平台标识必须在Configure文件里能找到对应名字。直接跑./config也能自动探测到但手工指定更可控。ARM 机器上是linux-armv4IBM Power 是linux-ppc64le别搞混。--prefix/opt/openssl-1.0.2u安装根目录。默认是/usr/local也就是会装到/usr/local/bin/openssl。这个默认值在你想多版本共存时会跟系统自带版本“打架”所以强烈建议换成独立目录。--openssldir/opt/openssl-1.0.2u/sslOpenSSL 运行时的配置目录存放openssl.cnf、CA 证书路径、随机数种子等。不指定的话默认是/usr/local/ssl这也容易踩坑。shared生成动态库libssl.so、libcrypto.so而不是只生成静态库.a。很多场景下第三方程序动态加载依赖的就是.so不加这个选项后面容易出问题。zlib-dynamic让 OpenSSL 动态链接系统的 zlib 库用于压缩扩展。如果系统没有 zlib 开发包这个选项会导致编译失败需要先yum install -y zlib-devel。enable-ec_nistp_64_gcc_128在 x86_64 上启用 NIST P-256 等椭圆曲线的优化实现对 ECC 性能有明显提升。如果编译时报汇编错误关掉这个选项回退到通用实现。3.3 make、make test、make install 三步走配置完成之后正式的编译安装我习惯分三步执行每步都要确认返回码是 0# 第一步编译 make -j4 # 第二步跑测试时间较长但值得 make test # 第三步安装到 prefix 目录 make installmake -j4里的-j4表示用 4 个并行任务编译可以按 CPU 核数调整。1.0.2u 全套编译在 4 核机器上大概 5~8 分钟在 8 核机器上两三分种就能跑完。如果编译到一半报错先别急着重复 make建议看一眼报错位置——很多问题是 Configure 阶段参数不对导致的直接make clean后重新 Configure 往往比硬改 Makefile 靠谱。make test这步很多人会跳过我建议至少跑一次。1.0.2u 的测试套件会覆盖 RSA、AES、证书解析、TLS 握手模拟等场景能提前暴露出和你当前系统环境的兼容性问题。我遇到过一次make成功但make test必现某几个 ECC 测试失败的情况最后查出是机器 CPU 指令集太老关闭enable-ec_nistp_64_gcc_128后重编才通过。这种问题如果不跑测试等到生产环境 TLS 握手时随机暴露排查代价高得多。装完后验证一下版本/opt/openssl-1.0.2u/bin/openssl version -a输出里应该能看到OpenSSL 1.0.2u 20 Dec 2019以及OPENSSLDIR指向/opt/openssl-1.0.2u/ssl。到这步一个独立、可控的 OpenSSL 1.0.2u 环境就算装好了。4. 装完就踩的坑版本不匹配、库冲突与 verify 失败4.1 “built against 30000070, you have 30500050”到底什么意思很多人拿到 openssl-1.0.2u 编译完之后不去动它还好一旦把它用于某个第三方工具运行时经常会弹出一句类似openssl: version mismatch. built against 30000070, you have 30500050现在开源社区里大量工具Python 的 cryptography 包、curl、wget、nginx、haproxy 等自身带了编译时的 OpenSSL 版本标记。30000070 是 OpenSSL 3.0.7 的十六进制版本号格式30500050 对应 3.0.5 的另一个组合。你编译好的 1.0.2u 是 0x100020fu但如果某个二进制某次被编译时链接的是 3.0.7 的头文件运行时却在LD_LIBRARY_PATH里加载到了 3.0.5 的.so就会报这种 mismatch。这种问题的根因不是“你装错了”而是动态链接时加载到的 libssl/libcrypto 库和你头文件对应的版本不一致。排查思路# 看这个二进制运行时到底加载了哪个 libssl ldd /path/to/program | grep ssl # 主动指定加载 1.0.2u 的动态库路径 LD_LIBRARY_PATH/opt/openssl-1.0.2u/lib /path/to/program如果指定路径后 mismatch 消息变了或者消失了说明问题就出在LD_LIBRARY_PATH的搜索顺序上。实际项目里我建议不要全局 exportLD_LIBRARY_PATH而是写一个 wrapper 脚本只对特定程序注入路径避免污染整个系统的动态库加载。4.2 libssl.so 冲突导致程序启动崩溃这里有个更隐蔽的坑。当你把 1.0.2u 的共享库装到/usr/local/lib或者/usr/lib64这种系统搜索路径下再用ldconfig刷新缓存系统里其他依赖 OpenSSL 的程序很可能会直接加载到 1.0.2u 的动态库。新版程序调用只在 1.1.1 才存在的符号时就会报 undefined symbol甚至直接段错误。解决办法也很直接把 1.0.2u 的库目录排除在系统搜索路径之外程序需要用时按需指定。可以用/etc/ld.so.conf.d/下的配置来控制也可以干脆把库放在/opt/openssl-1.0.2u/lib保持隔离。我用过一个更稳的组合方案在 Nginx 编译时明确指定./configure \ --with-openssl/path/to/openssl-1.0.2u \ --with-cc-opt-I/opt/openssl-1.0.2u/include \ --with-ld-opt-L/opt/openssl-1.0.2u/lib -Wl,-rpath,/opt/openssl-1.0.2u/lib其中-Wl,-rpath会把库路径直接写进二进制里运行时优先从固定路径加载不受系统 LD_LIBRARY_PATH 环境影响。这种做法比到处设置环境变量干净得多也适合写进自动化部署脚本。4.3 openssl verify -cafile 为什么老是失败把 OpenSSL 1.0.2u 装好后另一个高频需求是证书链校验也就是openssl verify相关操作。很多人在 CentOS 6/7 上手动编译 1.0.2u 之后跑/opt/openssl-1.0.2u/bin/openssl verify -CAfile ca.crt server.crt结果提示 unable to get local issuer certificate。这个坑我查过很多次原因多半不是证书真有问题而是 OpenSSL 在找 CA 证书目录时没有加载系统里那几个常用证书符号链接。1.0.2u 默认的 CA 路径是编译时--openssldir决定的也就是/opt/openssl-1.0.2u/ssl/certs这个空目录里根本没有任何根证书。而系统自带的证书通常在/etc/pki/tls/certs/ca-bundle.crt或/etc/ssl/certs/ca-certificates.crt。解决办法两种一种是指定系统证书文件/opt/openssl-1.0.2u/bin/openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt server.crt另一种更通用建立符号链接把系统证书目录映射到 openssldirmkdir -p /opt/openssl-1.0.2u/ssl/certs ln -s /etc/pki/tls/certs/ca-bundle.crt /opt/openssl-1.0.2u/ssl/cert.pem ln -s /etc/pki/tls/certs/ca-bundle.crt /opt/openssl-1.0.2u/ssl/certs/ca-bundle.crt这样后续只写-CApath或直接用默认路径也能校验通过省去每次敲一长串参数。5. 让老版本和系统默认 OpenSSL 和平共处多版本管理与工程化思考5.1 用 update-alternatives 还是自己写软链接如果服务器的系统包管理器已经装了新版 OpenSSL你又通过源码在/opt/openssl-1.0.2u装了一份老的这时候直接改 PATH 优先级会影响一堆系统工具比如curl、wget、git可能都依赖系统 OpenSSL。我的习惯是系统默认路径/usr/bin/openssl保持不动由包管理器管理自定义路径/opt/openssl-1.0.2u/bin/openssl只给指定项目和脚本用在项目部署脚本里显式引用/opt/openssl-1.0.2u/bin/openssl不用简短的openssl命令想省事也可以注册到 update-alternatives但这里有个容易踩的细节update-alternatives 管的只是命令行入口libssl.so 的动态库路径不受它控制还是要靠 LD_LIBRARY_PATH 或 rpath 解决。5.2 用 tar 命令批量分发自定义 OpenSSL 环境编译完的/opt/openssl-1.0.2u目录可以直接打包分发到其他同架构机器不必每台都重新编译一遍。这正好用上前面提到的那批 tar 操作热搜词。我自己的习惯是# 打包整个安装目录 tar -zcvf openssl-1.0.2u-linux-x86_64.tar.gz /opt/openssl-1.0.2u # 在目标机器上解压到对应位置 tar -zxvf openssl-1.0.2u-linux-x86_64.tar.gz -C /tar -zcvf里的-z表示 gzip 压缩-c表示创建归档-v显示进度-f指定输出文件-zxvf对应的-x表示解压-v和-f含义相同。整套参数熟记之后后面再做批量发布非常顺手。也有人习惯把证书、配置变量统一放到 tar 包外解压后再用tar -zxvf配合xargs做批量置权或覆盖tar -tzf openssl-1.0.2u-linux-x86_64.tar.gz | grep \.so$ | xargs -I{} chmod 755 {}这就是那些“tar|xargs”组合热词的典型用法核心是先用tar -tzf列出包内文件列表再交给 xargs 批量处理。比 for 循环写起来短也更好维护。5.3 用 builder 脚本固化升级流程既然 1.0.2u 已经 EOL团队内部更稳妥的做法不是靠某个人记住编译步骤而是把整个流程固化成可重复执行的脚本。我目前维护的部署仓库里有一个build-openssl-1.0.2u.sh核心流程就是“下载校验 Configure make make test make install 生成包名带版本的 tar.gz”脚本执行完自动输出新包的 SHA256 值。这样即使三个月后换新机器也能用同一套流程重新产出完全一致的二进制。脚本里的版本参数化很重要一旦后续要切 1.0.2t 或者 1.1.1w只需要改版本号变量不用改逻辑。不过说实话只要业务条件允许我仍然建议尽早往 1.1.1 或 3.x 迁移1.0.2 毕竟已经停止安全更新了内网隔离环境还能接受一旦暴露到公网风险就是实打实的。最后分享一个小技巧编译之前用date记录一下当前系统时间因为有些老版本 OpenSSL 的测试套件对时间敏感系统时间偏差太大可能导致测试步骤失败。我踩过一次坑是在一台 RTC 电池没电的服务器上编译make test报证书有效期相关错误折腾半天才发现是系统时间停留在 2019 年——查问题的时候记得多看一眼系统时钟往往能省下几个小时。本文还有配套的精品资源点击获取