企业官网建设流程全解析

简介：OpenSSL 1.1.1k 源码包面向需要集成或运维 SSL/TLS 加密能力的开发者、系统管理员与安全学习者，提供稳定分支的密码库及配套命令行工具，可用于安全连接调试、证书密钥管理和加密功能开发。资源以 gz 压缩包分发，大小约 9.37MB，文件清单与类型明细暂未提供，解压后可依据标准流程配置、编译与安装。目前已有 413 人学习，适合作为理解 OpenSSL 版本特性与搭建实验环境的参考。内容围绕 TLS 1.0 至 1.3 协议支持、AES/RSA/ECC/哈希等算法、X.509 证书与私钥公钥管理展开，并包含 s_client、s_server、genpkey、req、x509 等常用工具的使用场景；同时涉及 C 语言 API 集成、AES-NI 等性能优化、多平台适配和安全更新思路，便于读者在开发调试与运维排错中建立较完整的知识框架。

1. 把openssl-1.1.1k.tar.gz丢进构建机：三步走完才是麻烦的开始

把openssl-1.1.1k.tar.gz解压，./config && make && make install走完，终端回显版本号1.1.1k，很多人到这里就收工了。实际动手时，真正的麻烦从这一刻才开始：系统里原有的libssl.so.1.1仍然存在，curl、ssh和你的业务进程运行时加载的，很可能还是旧的那一份；编译期链接的路径和运行期加载的路径，不一定指向同一个文件。这个源码包本身并不复杂，复杂的是让它在该出现的地方出现、在不该出现的地方不出现。1.1.1k 这一版包含两个已经公开的修复（重协商过程中的空指针问题、严格校验模式下的 CA 证书绕过问题），所以不少老系统会挑这个字母版本做一次定点升级。下文按实际部署顺序拆开讲，适合需要给存量服务补齐 TLS 1.3 能力、又不想动发行版自带库的运维和 C/C++ 开发者。

2. 动手前先看清包结构：三个目录和三样依赖

拿到一个源码包，我不会立刻敲./config。先花两分钟确认三件事：压缩包内的目录层级长什么样、哪些文件才是真正的构建入口、这台机器上最少需要存在哪些工具。这三件事确认完，后面九成的“配了但没生效”都能提前避开。

2.1 解压只是个体力活，关键是认清入口文件

OpenSSL 的源码包解开后只有一个顶层目录openssl-1.1.1k/，里面没有常见的configure.ac和Makefile.in那套 Autotools 结构，取而代之的是Configure（Perl 脚本，真正的构建系统）和config（Shell 包装脚本，负责猜测平台并调用Configure）。绝大多数人用的是./config，因为它省事；但在 CI 里我倾向于直接调./Configure并显式给目标名，这样换构建机时结果才一致。

先做完整性校验，再只看结构不解压，最后落到独立的构建目录里：

# 校验来源完整性：摘要值要和下载页给出的值逐位比对，不要跳过 sha256sum openssl-1.1.1k.tar.gz # 只看顶层结构，确认压缩包里没有多余的嵌套层级 tar -tzf openssl-1.1.1k.tar.gz | head -n 20 # 解压到独立构建目录，避免和别的版本的材料混在一起 mkdir -p /opt/build && tar -xzf openssl-1.1.1k.tar.gz -C /opt/build cd /opt/build/openssl-1.1.1k && ls

tar -tzf那一步的意义在于确认压缩包内部的路径前缀。如果前缀不是openssl-1.1.1k/而是多套了一层，-C解压后你cd的路径就是错的，后面的./config会报“找不到脚本”，这属于最没必要的翻车。-C /opt/build则是把构建材料和/usr/src这类公共目录隔开，构建目录我会当成一次性耗材，装完就把中间产物清掉。

顶层目录里值得关注的只有几个：Configure和config是构建入口，Configurations/10-main.conf里放着所有目标平台的定义（编译选项、目标文件名、默认 libdir 都在里面），INSTALL是官方给的参数说明，crypto/、ssl/、apps/分别对应算法库、协议实现和命令行工具，test/是后面make test要跑的用例。想快速弄清某个编译开关到底做了什么，去看Configurations/10-main.conf比翻文档快。

2.2 最小依赖集：编译器、make、Perl，别的一样都不需要

1.1.1 系列的构建依赖非常干净：一个 C 编译器、GNU make、Perl 5。zlib 是可选的，只有你显式加了zlib开关才会引入。听起来简单，但在精简容器镜像里翻车的概率相当高——很多-slim基础镜像为了压体积把 Perl 裁掉了，./config一跑就报perl: command not found或者./config: not found，看着像脚本损坏，其实是解释器缺失。

开跑之前把这四条命令走一遍，比出事之后再回来查要省时间：

gcc --version | head -n 1 # 编译器版本，太老的 gcc 不支持某些优化开关 make --version | head -n 1 # 需要 GNU make，BSD make 会在这里出问题 perl -v | sed -n '2p' # 5.x 即可，1.1.1 只用到 Perl 核心模块 ldd --version | head -n 1 # 后面排查动态库路径要用它

参数说明上，gcc --version | head -n 1取第一行是够的，你只需要知道大版本；make --version里如果出现BSD make字样就要换gmake，否则./config生成的 Makefile 语法它认不全。Perl 那行用sed -n '2p'是为了跳过版权信息直接看版本号。ldd看起来和构建无关，但后面验证“程序到底加载了哪一份libssl”全靠它，提前确认机器上有这个命令。

还有个隐蔽的坑：某些发行版把perl拆成了perl-base和perl-modules两个包，perl -v正常但pod2man缺失，构建过程会在生成文档那一步挂掉。这不是致命错误，处理方式放在第 5 章。

2.3 用./Configure LIST确认目标名，而不是靠猜

./config会自动探测平台，它的探测逻辑就是跑一遍uname -m加一些启发式判断。桌面环境上没问题，但在容器、交叉编译环境、以及一些uname被改动过的环境里，探测结果可能落到一个通用的linux-x86_64上，也可能直接告诉你“target not supported”。

显式看一遍可选目标，是成本最低的保险：

# 列出所有内置目标，只筛出常见的 Linux 平台 ./Configure LIST | grep -E 'linux-(x86_64|aarch64|armv4|ppc64le)'

输出里linux-x86_64、linux-aarch64这类是通用目标；带-ilp32、-64、clang后缀的是变体（对应 ABI 或编译器差异）。选哪个的判断依据不是机器新旧，而是你要交付的二进制跑在什么环境上：目标机器是 x86_64 通用发行版，就用linux-x86_64；用 clang 并且希望享受 clang 的告警策略，就选带clang的变体。

提示：Configure LIST只能看名字，看不到具体编译选项。如果你不确定某个目标加了哪些-march，直接grep一下Configurations/10-main.conf里对应的段落，比在生产机上试错便宜得多。

3. 参数组合怎么定：--prefix、shared与no-*开关的取舍

参数这一块是最容易照抄出问题的地方。网上流传的命令行经常把--prefix=/usr/local/ssl、no-shared、zlib甚至enable-fips一锅端地写在一起，但你并不知道写它的人面对的是什么部署形态。下面这套组合是我在“不动系统库、并行安装一份、给指定程序用”这个场景下的默认值，逐项解释为什么。

3.1 四个必设参数，以及它们各自影响的文件

先给命令，再拆解：

./config \ --prefix=/opt/openssl-1.1.1k \ --openssldir=/opt/openssl-1.1.1k/ssl \ --libdir=lib \ shared zlib \ no-ssl3 no-comp no-weak-ssl-ciphers \ -fPIC

--prefix决定安装根目录，也就是bin/openssl落在哪。这里刻意用带版本号的路径/opt/openssl-1.1.1k，原因很直接：将来装 1.1.1 后续字母版本或者换到 3.x 主线时，两套可以直接共存，回滚只需要改一个软链或者改一次LD_LIBRARY_PATH，不用重装系统库。代价是每次升级都要改环境变量，这点后面会讲怎么用 rpath 一次性解决。

--openssldir决定 OpenSSL 去哪找配置文件和证书，它和--prefix是两个独立的东西，这是新手最常混淆的一点。默认值在 1.1.1 里是/usr/local/ssl，如果不显式指定，安装完会看到openssl version -d指向一个你没打算用的目录，然后s_client校验证书时告诉你找不到本地签发者。这里把它放在前缀下面，保持整套东西自包含。

--libdir=lib是显式指定库目录名。64 位平台上，某些发行版打过补丁的配置会把库放到lib64，而pkg-config的.pc文件里写的路径又和实际不一致，两头对不上就会出现“明明装了却链接不到”。显式写lib，让.pc文件、-L路径、运行时路径三处统一。

shared和zlib放在同一行，前者要求生成动态库（libssl.so.1.1、libcrypto.so.1.1），后者打开 zlib 相关的代码路径。这里提醒一句：zlib和no-comp不要同时写在一行命令里，前者打开压缩相关能力，后者把它关掉，同时写上只会让后面看命令的人困惑，而你排查依赖时会怀疑是不是自己漏了什么。

no-ssl3、no-comp、no-weak-ssl-ciphers这三个是减法开关。no-ssl3去掉已经废弃的 SSLv3 支持，no-comp去掉 TLS 层压缩（这个能力在有名的 CRIME 攻击之后就不该默认开着），no-weak-ssl-ciphers直接把出口级和低强度的密码套件从编译产物里剔除。减法开关的价值不只是安全，还有排查成本：你的服务如果某天被扫出支持 3DES，用这组参数编出来的库根本不会给它这个机会。

-fPIC是给 C 编译器的标志，位置在参数列表最后，Configure会把它原样传给编译器。

3.2 静态还是动态：由部署形态决定，不是性能问题

shared和no-shared的选择经常被包装成性能话题，实际上下沉到部署层面看，它就是一个“你愿不愿意管运行时路径”的问题。

选shared（动态库）意味着：openssl可执行文件很小，libcrypto.so.1.1在多个进程间共享，升级库文件不需要重新编译调用方（前提是 ABI 兼容）。代价是运行时必须有办法找到这个.so，要么设LD_LIBRARY_PATH，要么给可执行文件写 rpath，要么改/etc/ld.so.conf.d。三种方式的影响范围依次放大，风险也依次放大，第 4 章会详细讲。

选no-shared（静态库）意味着：交付物是一个自包含的可执行文件，扔到目标机上就能跑，不用管库路径。代价是体积，以及当你有多份静态链接的程序跑在同一台机器上时，libcrypto的代码段会在内存里存在多份。对内网小工具、单文件分发的场景，静态是省事的选择；对需要被第三方程序动态加载（比如某个语言运行时按 soname 去dlopen）的场景，必须是shared。

我一般的判断标准是：这份库如果只服务于我自己写的程序，静态；如果要被系统上别的软件、或者被 Python/Node 这类运行时按libssl.so.1.1这个名字去找，动态。选错了的典型症状是——程序跑起来报libssl.so.1.1: cannot open shared object file，或者反过来，你明明编了静态版，某个依赖却还是加载了系统里那份旧的。

3.3 交叉编译与-fPIC：两个最容易撞墙的开关

交叉编译时，./config的自动探测基本必然失败（它探的是构建机），所以必须用./Configure显式给目标名，再配--cross-compile-prefix：

# 以 x86_64 主机上编 aarch64 目标为例 ./Configure linux-aarch64 \ --cross-compile-prefix=aarch64-linux-gnu- \ --prefix=/opt/openssl-1.1.1k-aarch64 \ --openssldir=/opt/openssl-1.1.1k-aarch64/ssl \ --libdir=lib \ shared no-async \ -fPIC

linux-aarch64是目标名，决定Configurations/10-main.conf里取哪一段编译选项；--cross-compile-prefix是给所有工具名加的前缀，gcc会变成aarch64-linux-gnu-gcc，ar、ranlib同理。no-async在这类场景里经常是必需的——async支持依赖ucontext相关接口，某些精简的交叉工具链里没有，不关掉就会在链接阶段报一堆未定义符号。

-fPIC单独拎出来说，是因为它引发的是全篇最有代表性的一条报错：

relocation R_X86_64_PC32 against symbol `...' can not be used when making a shared object; recompile with -fPIC

现象是从静态库往共享库链接时炸掉。原因是参与链接的目标文件里混进了非 PIC 编译的.o（常见于你手动把某个第三方.a塞进来，或者目标平台的默认配置没带-fPIC）。解决方式就是让所有参与共享库链接的目标都带位置无关代码，构建 OpenSSL 时显式加-fPIC，自己写的模块也一样。这条经验适用于任何“静态库链接进.so”的场景，不止 OpenSSL。

配置完就可以开编了：

# 并行编译，核数按机器来，别在内存小的机器上开满 make -j"$(nproc)" # 跑一遍测试套件，交叉编译时跑不了，跳过即可 make test # 只装软件本体，不装文档（原因见第 5 章） make install_sw

make -j的核数不要迷信nproc，8G 内存以下的容器开满核编译crypto/目录容易触发 OOM killer，表现为make没有报错但进程被 kill、退出码 137。稳妥一点用-j4，或者-j$(( $(nproc) / 2 ))。make test在原生编译时值得跑，它会覆盖大量密码学算法的一致性测试，跑完再装能省掉后面“某个算法结果不对”的排查。make install_sw和make install的区别是前者跳过文档安装，这个差异在 5.3 节会解释为什么重要。

4. 让新库真正被调用：pkg-config、运行时路径与证书目录

装完不等于用上，这是整个流程里落差最大的一段。安装目录里躺着正确的文件，程序却加载了系统的旧库，或者链接时找到了头文件、运行时找不到.so，这些问题的根源都在“路径”上。这一段讲的就是把三条路径对齐：编译期的头文件路径、链接期的库路径、运行期的加载路径，再加上一个容易被彻底忽略的证书目录。

4.1 并行安装之后，先看清装出来的目录结构

安装完成后花一分钟ls一遍，心里有数，比出事之后再find强：

tree -L 2 /opt/openssl-1.1.1k 2>/dev/null || find /opt/openssl-1.1.1k -maxdepth 2 -type d

正常会看到四块：bin/openssl（命令行工具）、lib/（libssl.so.1.1、libcrypto.so.1.1、静态库，以及pkgconfig/*.pc）、include/openssl/（头文件）、ssl/（openssl.cnf、certs/、private/、misc/）。这四个目录分别对应四个不同阶段的路径配置，少对齐一个就会出问题：

表里最容易漏的是第四行。前三行对齐了，程序能编能跑，但一旦涉及证书校验，就会在“证书链不完整”这个报错上耗掉半天。

4.2 编译期与运行期必须指向同一个目录

pkg-config这一层是把编译和链接参数统一的省事做法。make install_sw会在lib/pkgconfig/下生成openssl.pc、libssl.pc、libcrypto.pc三个文件，把PKG_CONFIG_PATH指过去就能直接用：

export PKG_CONFIG_PATH=/opt/openssl-1.1.1k/lib/pkgconfig # 先确认 pkg-config 认到的是新装这一份，而不是系统 /usr/lib 下的 pkg-config --modversion openssl pkg-config --cflags --libs openssl

--modversion输出应当是1.1.1k。如果输出的是系统里别的版本，说明PKG_CONFIG_PATH被/usr/lib/pkgconfig抢了优先级——pkg-config是按路径顺序找的，把新的路径放在最前面即可。这一步没确认就去编程序，后面所有排查都是在错误的地基上做。

编译时把运行期路径一并写进去，比依赖环境变量可靠得多：

gcc app.c -o app $(pkg-config --cflags --libs openssl) \ -Wl,-rpath,/opt/openssl-1.1.1k/lib

-Wl,-rpath,<dir>是把目录写进 ELF 的DT_RUNPATH，程序启动时动态加载器会去这个目录找.so。它比LD_LIBRARY_PATH好在两点：不依赖启动环境（systemd 服务、cron 任务、被别的进程exec时都不会丢），并且只影响这一个可执行文件，不会误伤系统上其它程序。

LD_LIBRARY_PATH当然也能用，适合临时调试：

LD_LIBRARY_PATH=/opt/openssl-1.1.1k/lib ldd ./app | grep -E 'libssl|libcrypto'

那一行的输出是判断“到底加载了哪一份”的唯一可靠依据，不要用openssl version代替——它只告诉你bin/openssl自己用的是什么，不代表你的业务进程也是。

至于/etc/ld.so.conf.d/openssl-1.1.1k.conf这种全局做法，我一般不推荐在跑着其它服务的机器上用。原因是系统自带的curl、ssh、包管理器等程序都依赖libssl.so.1.1这个 soname，你把搜索路径改到自己的目录，它们会静默地加载你编的这一份。同 soname 的不同构建在绝大多数情况下能混用，但一旦你构建时加了no-weak-ssl-ciphers这类减法开关，某个老程序依赖的弱套件突然消失了，症状是“某个 HTTPS 站点连不上了”，而报错信息完全不会指向库替换。真要全局生效，优先考虑在软件包层面替换，而不是改搜索路径。

4.3--openssldir指向的目录，决定证书校验成不成立

新装的ssl/目录里，certs/是空的。系统的信任根在/etc/ssl/certs（或发行版对应的位置），两者互不相通。于是出现一个很典型的现象：系统curl访问某个站点正常，换成/opt/openssl-1.1.1k/bin/openssl s_client就报unable to get local issuer certificate。不是网络问题，也不是服务端问题，纯粹是新装的这套没拿到信任根。

三种处理方式，按侵入性从小到大：

# 方式一：临时指定信任文件，不改任何配置，适合一次性排查 /opt/openssl-1.1.1k/bin/openssl s_client -connect 目标域名:443 \ -servername 目标域名 \ -CAfile /etc/ssl/certs/ca-certificates.crt </dev/null # 方式二：用环境变量，OpenSSL 1.1.x 会读取 SSL_CERT_FILE export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt export SSL_CERT_DIR=/etc/ssl/certs # 方式三：把信任根固化到 openssldir 里，一劳永逸 cp /etc/ssl/certs/ca-certificates.crt /opt/openssl-1.1.1k/ssl/cert.pem

方式一里的-servername是 SNI，不带的话对多域名共用一个 IP 的站点会拿到默认证书，校验照样失败，但报错信息会误导你以为证书链有问题。</dev/null是为了让命令读完就退出，否则s_client会挂在交互模式等输入。

方式三适用于“这台机器上所有用到这套 OpenSSL 的程序都该信任系统根证书”的场景。如果你的程序有自己的证书链需求（比如内网私有 CA），更合适的做法是在openssl.cnf里配CAfile和CApath，然后通过OPENSSL_CONF环境变量按进程指定，而不是改全局的那份配置文件。

CApath那个目录还有个附加要求：文件名必须是证书主题的哈希值，光把.pem拷进去不管用。用openssl rehash生成哈希链接（旧版本里这个命令叫c_rehash）：

cp /path/to/internal-ca.crt /opt/openssl-1.1.1k/ssl/certs/ /opt/openssl-1.1.1k/bin/openssl rehash /opt/openssl-1.1.1k/ssl/certs/

4.4 三条验证命令，确认用的确实是这一份

装完之后我会固定跑这三条，缺一条都不算验证完成：

# 一、看这套 OpenSSL 自己的版本、构建参数、OPENSSLDIR 指向 /opt/openssl-1.1.1k/bin/openssl version -a # 二、看它依赖的动态库解析到哪个路径 ldd /opt/openssl-1.1.1k/bin/openssl | grep -E 'libssl|libcrypto' # 三、发起一次真实握手，确认协议版本和证书链 /opt/openssl-1.1.1k/bin/openssl s_client \ -connect 目标域名:443 -servername 目标域名 -brief </dev/null

第一条输出的信息量很大：built on是构建时间（用来区分你手上这份是不是刚编的），compiler那行能看到你传的-fPIC之类标志有没有生效，OPENSSLDIR和ENGINESDIR则是运行时路径的直接证据。这三个字段任何一个不对，都说明参数没传对或者装到了别处。

第二条是防止“看版本对、实际用旧库”的唯一手段。ldd输出里如果出现/usr/lib/x86_64-linux-gnu/libssl.so.1.1，说明 rpath 没生效，程序加载的是系统那份。

第三条里的-brief会输出一行紧凑的握手摘要，包含协议版本、密码套件、证书校验结果。想单独验证 TLS 1.3 是否可用，加-tls1_3；想验证某个套件在不在，用openssl ciphers -v 'ECDHE+AESGCM'看列表，比反复试握手快。

5. 避坑与排查：五个翻车现场的现象、原因与处理

下面这五条都是我在不同机器上真实撞过的，按“现象 → 原因 → 解决”写，症状描述尽量保留原始报错的关键词，方便你直接拿去搜。

5.1openssl version是新版本，业务程序却还在用旧库

现象：/opt/openssl-1.1.1k/bin/openssl version输出1.1.1k，但自己编的程序里OpenSSL_version(OPENSSL_VERSION)返回的是系统旧版本号；用ldd ./app一看，libssl.so.1.1指向/usr/lib/...。

原因：编译期和运行期分离。pkg-config --libs只影响-L和-l，决定链接时找哪个.so；运行时加载器按RPATH→LD_LIBRARY_PATH→ld.so.cache→ 默认路径的顺序找。你只改了前者，后者仍然命中系统目录。更隐蔽的一种情况是编译了静态库但没加-static，链接器优先选.so。

解决：给可执行文件写 rpath（-Wl,-rpath,/opt/openssl-1.1.1k/lib），已上线的程序用patchelf --set-rpath补；确实要走环境变量的话，注意LD_LIBRARY_PATH对 setuid 程序无效，systemd 服务要用Environment=显式传。最后一定用ldd复核，别用版本号字符串自证。

5.2make在链接阶段报R_X86_64_PC32 ... recompile with -fPIC

现象：编译过程一路正常，到最后生成libssl.so时报一堆 relocation 错误，提示重新用-fPIC编译。

原因：共享库的代码要在运行时被映射到任意地址，所有引用必须用位置无关的方式表达。构建时如果有目标文件没带-fPIC（自己加的第三方.a、或者目标平台配置里漏了），链接器就会拒绝把它并进.so。

解决：给./Configure显式加-fPIC，并检查是否把外部静态库塞进了链接列表——外部.a必须本身是 PIC 编译的，重新编一份比想办法绕过便宜。改完参数记得先make distclean，残留的.o不会因为你改了参数就自动重编。

5.3make install卡在POD document had syntax errors

现象：编译和测试都过了，make install在装文档阶段报POD document had syntax errors at /usr/bin/pod2man，退出码非零，前面装好的东西看起来也“不太对”。

原因：1.1.1 系列的 POD 文档写法与较新版本 Perl 自带的pod2man严格模式不兼容，这是构建文档时的工具链差异，和库本身的代码质量无关。

解决：直接改用make install_sw，跳过文档安装。绝大多数部署场景不需要本地 man page，库、头文件、openssl可执行文件都装好了。已经装了一半的，make install_sw重跑一次即可，它是幂等的。别去改pod2man的行为，那会影响机器上其它项目。

5.4 期待 FIPS 能力，装完发现没有

现象：按某些资料加了enable-fips之类的参数，Configure报未知选项或者干脆忽略，装完也找不到 FIPS 模块。

原因：1.1.1 主线不提供 FIPS 认证模块，那是另一个分支才有的东西。把“1.1.1k 修了两个安全漏洞”和“FIPS 合规”混为一谈，是选型阶段就埋下的误判。

解决：合规需求要在选型阶段确认清楚，不要等到装完再补。真有 FIPS 要求，需要走对应的分支或由合规方案提供方给出，而不是给 1.1.1k 加个开关。这条没有技术捷径，只有需求澄清。

5.5 换了 OpenSSL，Python 和其它语言运行时没跟着换

现象：C 程序已经用上新库了，但 Python 里ssl.OPENSSL_VERSION还是旧字符串；重新pip install cryptography也报错或者装出老版本。

原因：Python 的_ssl模块是编译期绑定到具体 OpenSSL 的，运行时改环境变量不生效——它不会在启动时按 soname 重新找库。cryptography这类包在构建时会去找头文件和库，找错地方就会失败或降级。

解决：Python 侧要换 OpenSSL，只能重编解释器（--with-openssl=/opt/openssl-1.1.1k）。如果只是想给某个 Rust 或 C 扩展指定库位置，构建时用OPENSSL_DIR=/opt/openssl-1.1.1k，很多绑定库认这个变量。别指望一个环境变量摆平所有语言运行时，那是两套机制。

6. 把它固化成一段脚本：参数、校验和回滚位置一次定死

手工敲命令的后果是，半年后你要在另一台机器上重现同样的构建，只能靠翻命令行历史，而历史里往往缺了那次“临时加上的”参数。我的习惯是把整个流程写成脚本，参数集中放在开头，输出目录带版本号，构建完立刻做一次自检并把结果落盘。

#!/usr/bin/env bash set -euo pipefail # 任何一步失败立刻停，不留半成品 VER=1.1.1k PREFIX=/opt/openssl-${VER} BUILD=/opt/build TARBALL=${BUILD}/openssl-${VER}.tar.gz # 1) 来源校验：摘要不匹配直接退出，不进入编译 expected="<下载页给出的 sha256 值>" actual=$(sha256sum "${TARBALL}" | awk '{print $1}') [ "${actual}" = "${expected}" ] || { echo "checksum mismatch"; exit 1; } # 2) 干净的解压目录，避免上一次的中间产物污染这次构建 rm -rf "${BUILD}/openssl-${VER}" tar -xzf "${TARBALL}" -C "${BUILD}" cd "${BUILD}/openssl-${VER}" # 3) 参数集中在这里，改配置只改这一段 ./config \ --prefix="${PREFIX}" \ --openssldir="${PREFIX}/ssl" \ --libdir=lib \ shared zlib \ no-ssl3 no-comp no-weak-ssl-ciphers \ -fPIC # 4) 并行度手工控制，内存小的机器上别开满 make -j4 make test make install_sw # 5) 自检结果落盘，作为这次构建的凭证 { "${PREFIX}/bin/openssl" version -a ldd "${PREFIX}/bin/openssl" | grep -E 'libssl|libcrypto' } > "${PREFIX}/build-manifest.txt" 2>&1

这段脚本里有几个刻意的选择。set -euo pipefail比set -e更严格，管道里任何一环失败都会中断，避免make挂在后台、脚本却继续往下跑。摘要校验放在解压之前，是因为解压一个损坏的包会得到一堆看起来正常的文件，排查成本远高于直接拒绝。rm -rf那一行看起来粗暴，但源码构建的最大时间黑洞就是“上一次改过参数、这次没重编”导致的玄学问题，用一个干净的目录换确定性，很值。

参数段集中在中间，是为了将来改版本时只动两处：VER和环境变量。升级到 1.1.1 系列后续字母版本时，改完VER后重跑一遍，新版本会装到/opt/openssl-1.1.1x，旧目录原封不动——回滚就是把软链指回去，或者改一下rpath，不用重新编译业务代码。

自检结果写进build-manifest.txt这一步，是踩过坑之后养成的习惯。version -a里的编译标志能证明这次构建用的确实是你以为的那组参数，ldd的输出能证明它链接的是自己的库而不是系统的。这两段信息在事后排查“为什么这台机器行为和那台不一样”的时候价值极高，因为两台机器的源码包可能一样、参数可能一样，但环境变量不一样。

还有一条边界要说清楚：1.1.1 系列已经不再接收常规维护，1.1.1k 更不是这条线的终点。它的价值在于给存量系统做一次定点修复和过渡，而不是新项目的起点。新项目直接上 3.x 主线，那边的 API 和构建体系都有变化，别把这份笔记里的命令直接套过去。

从那以后我每次做这类源码库的替换，都会在脚本最后强制跑一遍ldd加真实握手这两步，不管多急。因为所有“版本号对了”的自证都可以骗人，只有加载路径和握手结果不会。希望帮到你。

本文还有配套的精品资源，点击获取