简介这是一份面向Windows 32位系统的OpenSSL 1.1.1完整开发与运行资源包适合需要在C/C项目中集成SSL/TLS加密功能的开发者或需要配置安全网络通信的运维人员。压缩包共2000个文件约16.22MB主要包含bin目录下的openssl.exe命令行工具与动态链接库、include目录中的API头文件、lib目录下的静态库与导入库以及html目录中的完整API参考文档。其中HTML文档提供了详尽的使用教程与函数说明头文件覆盖SSL、加密、证书等核心模块可支撑从证书生成到数据加密的各类场景。该版本修复了此前多项安全漏洞并支持AES-GCM、CHACHA20/POLY1305等现代密码算法内存管理与多线程性能亦有优化。已有1042人学习下载对正在Windows环境下构建安全通信应用的开发者具有直接参考价值。1. OpenSSL 1.1.1一个已经 EOL 却还在承担生产业务的老版本为什么还要认真对待它OpenSSL 1.1.1 是很矛盾的存在官方早已停止支持但大量服务器、嵌入式设备、存量代码还在跑它。不是不想升级而是 TLS 1.3 的支持、与旧密码套件的兼容、以及一堆私有扩展没有做完让很多团队只能守着这个版本继续维护。这篇笔记解决四件事怎么把 1.1.1 编译干净、怎么用它做证书和 TLS 配置、最常见的坑在哪、以及部署后如何快速验证它是不是真的健康。适合被旧环境绑住又必须补安全能力的开发者和运维。2. 编译部署 OpenSSL 1.1.1configure、make、install 的前后边界2.1 configure 参数别乱加prefix 和 shared 是第一步我拿到 1.1.1 的源码包第一件事不是执行./config而是确认系统里有 Perl 5.10 以上并且make、gcc都在。1.1.1 的构建脚本是 Perl 写的环境不对会在 configure 阶段直接报Cant locate Config.pm这类错误。如果你在容器里先装好 build-essential 和 perl 模块再往下走。我一般用最小化参数开始避免一开始就引入一堆不熟悉的开关./config \ --prefix/opt/openssl-1.1.1 \ --openssldir/opt/openssl-1.1.1/ssl \ shared \ no-async逻辑说明--prefix决定安装根目录--openssldir决定私钥、证书、openssl.cnf 等配置文件的默认位置。shared要求生成动态库libssl.so.1.1和libcrypto.so.1.1如果不加默认都是静态库后续其他程序链接时非常痛苦。no-async是我当时为了绕开某些容器环境的 io_setup 限制加的但后来发现它才是导致s_client崩溃的元凶具体在避坑章节讲。所以如果你不确定系统有没有 async 问题不要加no-async。configure 完成后我会检查 configdata.pm 里实际生效的路径因为命令行写了--prefix但 libdir 可能会默认落到lib而不是lib64grep -E ^(prefix|openssldir|libdir) configdata.pm这个命令输出三个关键目录。如果libdir是lib而你的系统是 64 位且希望库在lib64可以在 configure 时加--libdirlib64。不过多数 Linux 发行版都能正确识别只是在部分交叉编译环境里会失手。2.2 make -j 与 install 后如何让全系统识别编译这一步我会先跑单核再跑并行。很多人直接make -j$(nproc)结果在头文件生成阶段遇到竞争报错信息非常玄学openssl/ssl.h: No such file or directory其实 make 依赖顺序乱了。1.1.1 的 Makefile 在并行处理上不算完美所以我的习惯是make -j1 make -j$(nproc)第一遍单核确保所有生成步骤按顺序完成第二遍并行加速。如果第一次单核都失败问题多半是缺少依赖库或编译器版本太老而不是 make 本身。安装到独立 prefix 后make install不会覆盖系统原有 OpenSSL但动态库路径不会自动进入系统缓存。需要手动写 ld 配置make install echo /opt/openssl-1.1.1/lib /etc/ld.so.conf.d/openssl-111.conf ldconfig逻辑说明ldconfig只扫描ld.so.conf里登记的目录如果不写文件动态链接器就找不到新的libssl.so.1.1。写好后可以用ldconfig -p | grep ssl验证。注意如果你为了临时调用新库而用LD_LIBRARY_PATH/opt/openssl-1.1.1/lib那这个变量会全局接管可能导致系统里其他依赖旧版本的程序出问题。我建议优先用 ld.conf 文件而不是到处 export。2.3 与系统自带 1.0.2 或 3.x 共存PATH 和依赖的优先级生产环境里最怕的是把不同版本的libssl.so搞混。OpenSSL 的 soname 是跟着大版本走的1.0.2 是libssl.so.1.0.01.1.1 是libssl.so.1.13.x 是libssl.so.3。理论上只要不强制做软链覆盖这几个版本可以和平共存。但我见过某开发者为了满足一个老应用的编译需求把/opt/openssl-1.1.1/lib/libssl.so.1.1手动软链到/usr/lib/libssl.so结果依赖旧版本的程序全部报undefined symbol。所以共存的第一原则是不要把新版本库强制覆盖到系统的默认 soname 上。我一般通过编译参数控制程序链接到哪个版本gcc -o myapp myapp.c \ -I/opt/openssl-1.1.1/include \ -L/opt/openssl-1.1.1/lib \ -Wl,-rpath,/opt/openssl-1.1.1/lib \ -lssl -lcrypto逻辑说明-Wl,-rpath把库路径写进程序的动态链接器搜索路径这样运行时即使LD_LIBRARY_PATH变了也不会误链其他版本的 SSL 库。如果你用 CMake可以设CMAKE_PREFIX_PATH但最终要确认myapp的DT_RPATH或DT_RUNPATH指向了 1.1.1 的目录。需要临时使用 1.1.1 的命令行时我再写一个环境脚本export PATH/opt/openssl-1.1.1/bin:$PATH export LD_LIBRARY_PATH/opt/openssl-1.1.1/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH/opt/openssl-1.1.1/lib/pkgconfig:$PKG_CONFIG_PATH注意这个脚本只用于当前 shell。如果你同时维护多个版本最好在每个服务启动脚本里单独指定而不是全局 source。3. 用 OpenSSL 1.1.1 生成私钥、CSR 和自签证书从零到可用的命令链3.1 生成 RSA/ECC 私钥与 CSRgenpkey 和 req 的参数权衡1.1.1 里genrsa还能用但官方已经推荐genpkey。区别在于genpkey通过-pkeyopt统一指定算法参数更灵活。生产环境我一般用 3072 位 RSA 或 P-256 椭圆曲线。原因很简单2048 位在 1.1.1 的安全级别设置里处于临界如果以后 security level 上调到 22048 还能用但证书链里的根若小于 2048 就会有问题。3072 位性能损耗不大兼容性也好。openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:3072 \ -aes-256-cbc \ -pass pass:YourPassphrase \ -out server.key逻辑说明-aes-256-cbc对私钥做对称加密-pass指定加密口令。如果你不希望口令出现在 shell 历史里可以把pass:YourPassphrase换成file:keypass.txt。私钥文件权限建议chmod 600 server.key。ECC 私钥则指定曲线openssl genpkey -algorithm EC \ -pkeyopt ec_paramgen_curve:prime256v1 \ -out eckey.pem逻辑说明prime256v1是 NIST P-256绝大多数协议栈都支持。不要为了追求安全性盲目上secp384r1有些老客户端和硬件设备不支持这条曲线。生成后可以用openssl pkey -in eckey.pem -text -noout查看曲线名称。生成 CSR 时1.1.1 的新增参数-addext很好用可以直接把 SAN 加进去避免再写 extfileopenssl req -new \ -key server.key \ -out server.csr \ -subj /CCN/STBeijing/LBeijing/OExample Corp/CNexample.com \ -addext subjectAltNameDNS:example.com,DNS:www.example.com注意-addext在 1.0.2 里不存在如果你的自动化脚本还要兼容老版本就不要用这个参数。另外CN现在只是“常用名”没有浏览器会因为它而信任你必须依赖 SAN。3.2 自签证书与扩展属性x509 命令的 v3 指定自签证书有两种方式一条命令从 CSR 直接签或者用 extfile 控制扩展。我用后者更可控。先写一个 extfilecat ext.cnf EOF basicConstraintscritical,CA:true keyUsagecritical,digitalSignature,keyEncipherment subjectAltNameDNS:example.com EOF openssl x509 -req \ -in server.csr \ -signkey server.key \ -days 825 \ -extfile ext.cnf \ -out server.crt逻辑说明-days 825是比 365 更适合内部证书的时长因为很多客户端检查证书有效期超过 825 天会拒绝。basicConstraintscritical,CA:true表示这个证书也充当 CA如果只是服务器证书应该设CA:false否则证书被拿去签发其他证书就危险了。keyUsage需要和握手场景匹配加了keyEncipherment才能做 RSA 密钥交换。如果你只是想快速测试也可以直接从 CSR 拷贝扩展openssl x509 -req -in server.csr -signkey server.key -days 825 -copy_extensions copy -out server.crt注意-copy_extensions copy在 1.1.1 里是测试特性如果 CSR 里的扩展内容不正确也会原样带进去所以正式用途还是用 extfile 显式声明。生成后一定要检查openssl x509 -in server.crt -noout -text | grep -A2 Subject Alternative Name如果输出是DNS:example.com就是对的。这里最容易踩坑的是忘记把www.example.com也加进 SAN结果用户访问带 www 的域名时报证书不匹配。3.3 用 s_server 和 s_client 验证证书链和握手证书生成后我会立刻在本机起一个临时服务验证openssl s_server -accept 4433 \ -cert server.crt \ -key server.key \ -www \ -tls1_3逻辑说明-www让服务把连接信息输出到浏览器方便快速查看。-tls1_3强制只使用 TLS 1.3如果证书或客户端不支持会立刻暴露。如果你要测试双向认证再加-Verify 1 -CAfile ca.crt。然后另开终端openssl s_client -connect 127.0.0.1:4433 \ -servername example.com \ -CAfile server.crt \ -brief逻辑说明-servername触发 SNI-CAfile把自签证书当作根证书来验证。-brief是 1.1.1 较新的选项只打印协议版本、加密套件和证书是否验证通过。握手成功会看到Verification: OK如果证书有问题会报Certificate chain的错误。这里常见的翻车是证书文件本身包含中间证书需要用-showcerts查看完整链。4. 1.1.1 下的 cipher suite、security level 和 TLS 1.3 配置4.1 查看和选择密码套件别把 ssl_cipher 和 tls13_cipher 混在一起OpenSSL 1.1.1 同时支持 TLS 1.2 和 1.3但两者的密码套件命名空间完全不同。TLS 1.3 只有五个官方套件名字形如TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256等。控制 TLS 1.2 的ssl_ciphers指令管不到 1.3。在最常见的 nginx 配置里1.1.1 对应的写法是# 控制 TLS 1.2 及以下 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; # 控制 TLS 1.3 ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;我用命令行查看某个套件是否可用openssl ciphers -v ECDHE-RSA-AES128-GCM-SHA256:!aNULL | head -10逻辑说明-v列出套件名称、协议版本、签名算法和密钥交换类型。!aNULL排除匿名式套件防止中间人伪装。如果你手写应用代码需要调用SSL_CTX_set_ciphersuites()设置 1.3 套件调用SSL_CTX_set_cipher_list()设置 1.2 及以下套件。忘记后者是很多开发者在 1.1.1 上升级时的通病。4.2 security level 对不同密钥长度的影响Security Level 是 1.1.1 继承自 1.1.0 的安全分级范围 0 到 5。默认是 level 1允许 1024 位 RSA 证书和 SHA1 签名但不允许 512 位 DH 参数。level 2 要求所有证书密钥 2048 位SHA1 签名会被拒。level 3 要求 3072 位。这个阈值直接决定你对接的老设备能不能握手。判断当前版本默认安全级别openssl version -a | grep SECLEVEL如果看到输出SECLEVEL1说明默认比较宽松。如果你在服务端代码里调高了级别比如SSL_CTX_set_security_level(ctx, 2)那么一台只持有 1024 位 RSA 证书的旧客户端就会握手失败服务端日志通常只显示handshake failure不会告诉你级别问题。排查时可以用 s_client 指定同一级别openssl s_client -connect 10.0.0.5:443 -security_level 1 -brief如果这样能连上而默认级别连不上基本可以断定是 security level 造成的。我碰到过某设备商的网关只支持 1024 位证书为了兼容它我给那个监听端口单独设了一个 contextsecurity level 设为 1其余端口保持 level 2。不要全局降级。4.3 DH 参数与会话复用性能和安全之间的小控制TLS 1.3 握手使用 ECDHE不再需要传统的静态 DH 参数。但 TLS 1.2 及以下仍可能用到 DHE 套件此时服务端需要dhparam。如果你没有显式提供OpenSSL 1.1.1 会用内置的 2048 位参数字但有些老客户端只认特定长度的参数。生成 2048 位 DH 参数openssl dhparam -out dhparam.pem 2048逻辑说明2048 位足够4096 位会让握手变慢且某些旧设备不接受。生成后在 nginx 里加ssl_dhparam /opt/openssl-1.1.1/ssl/dhparam.pem;。会话复用方面1.1.1 同时支持 session cache 和 session ticket。排查性能问题时我会在 s_server 上关闭 ticket逼着客户端走 cacheopenssl s_server -accept 4433 -cert server.crt -key server.key -no_ticket -www然后客户端连接两次观察Reused, TLSv1.3这类输出。如果显示New说明 cache 没有命中。原因可能是 cache 配置太小或者客户端每次都发新的 SNI。这里我踩过的坑是在负载均衡后面多个后端节点各自维护 session cache导致客户端每次落到不同节点就新建会话。解决办法是配置共享 cache或者干脆用 ticket 并统一 ticket key。1.1.1 里生成统一的 key 调用openssl rand 48但这属于更复杂的部署先知道方向即可。5. OpenSSL 1.1.1 避坑部署半年遇到的 5 个具体问题5.1 编译时加上 no-asyncs_client 启动即崩溃现象编译时用了no-async安装后openssl version正常但执行openssl s_client -connect example.com:443会直接段错误。原因OpenSSL 1.1.1 的 EVP 接口在某些算法实现里会通过 async 模块管理硬件异步等待。如果编译时禁用了 async部分接口返回的句柄是空的导致后续调用崩溃。这个问题只在 Linux AIO 受限的容器里容易出现我一开始以为 no-async 能规避 io_setup 限制结果反而破坏了运行时逻辑。解决去掉no-async重新编译。如果容器环境真的不允许 IO 系统调用可以在运行时用OPENSSL_ia32cap调整指令集或者给容器的 seccomp 配置放行io_setup和io_submit。我后来验证过绝大多数普通 Linux 机器不需要 no-async加它纯属给自己找麻烦。5.2 生成的证书没有 SANChrome 直接不认现象用 1.1.1 生成自签证书后浏览器访问 HTTPS 报NET::ERR_CERT_COMMON_NAME_INVALID但openssl verify显示证书有效。原因1.1.1 时代的主流浏览器已经完全忽略 CN 字段只认 subjectAltNameSAN。我的 CSR 里只写了-subj /CNexample.com没有 SAN所以证书里没有可用的域名标识。解决重新生成 CSR并加上-addext subjectAltNameDNS:example.com。如果证书已签发只能重签。我把 SAN 写进配置模板每次openssl req都从模板里读取避免人工输入遗漏。命令如下cat csr.cnf EOF [ req ] distinguished_name req_dn req_extensions v3_req [ req_dn ] CN example.com [ v3_req ] subjectAltName DNS:example.com, DNS:www.example.com EOF openssl req -new -key server.key -out server.csr -config csr.cnf注意req_extensions必须指定为v3_req否则扩展不会写入 CSR。5.3 Security Level 2 拒绝 1024 位证书老设备握手失败现象某设备商的客户端证书是 1024 位 RSA握手时服务端不断报alert handshake failure抓包显示客户端发送证书后服务端直接返回 alert。原因服务端通过SSL_CTX_set_security_level(ctx, 2)把级别提高后证书公钥长度低于 2048 位握手过程中对端证书校验失败但日志不会明确提示“too weak key”非常隐蔽。解决先用openssl s_client -security_level 1测试如果能连上说明是级别问题。然后给老设备单独建一个 context 或监听端口把 security level 保持在 1。不要全局降级否则新接入的 3072 位环境会担心整体安全水位下降。更好的方案是推动设备方把证书换成 2048 位但有些离线设备没得选只能兼容。5.4 TLS 1.3 的密码套件配置了等于没配置现象在 nginx 里用ssl_ciphers TLS_AES_128_GCM_SHA256;后客户端握手结果仍然是TLS_AES_256_GCM_SHA384。原因nginx 的ssl_ciphers指令只作用于 OpenSSL 的 cipher list而 TLS 1.3 的 ciphersuites 是另一个 APISSL_CTX_set_ciphersuites控制的。在 OpenSSL 1.1.1 里两者分得很清楚nginx 在 1.1.1 环境下需要借助ssl_conf_command才能配置 1.3 套件。解决在 nginx 配置中ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;如果你自己写 C/C 服务用SSL_CTX_set_ciphersuites()函数。验证方式openssl s_client -connect 127.0.0.1:443 -brief 21 | grep Cipher is如果输出不是你配置的套件检查服务端进程是否真的加载了 1.1.1 的动态库而不是系统旧版本。5.5 libssl.so.1.1 被软链覆盖后系统里一半服务启动失败现象某服务器升级后sshd、curl、postfix 等大量程序报undefined symbol: SSL_CTX_set_options有些直接无法启动。原因某部署脚本为了“统一版本”把/opt/openssl-1.1.1/lib/libssl.so.1.1软链到/usr/lib/libssl.so覆盖了原本链接到libssl.so.1.0.0的符号表入口。虽然文件名不同但很多老程序编译时依赖的是libssl.so这个无版本号的软链覆盖后它们找到了库但找不到旧符号。解决用patchelf或ldd查看具体依赖把错误的软链删掉恢复原有 soname 秩序。我写了一个快速扫描脚本find / -name libssl.so* -o -name libcrypto.so* 2/dev/null | xargs ls -l看到多个版本共存时注意不要让无版本号的libssl.so指向任何具体版本除非你真的知道自己在做什么。正确做法是在应用编译时通过 rpath 指定版本而不是动系统软链。6. 部署后我用 speed 和 c_rehash 做健康检查一个十分钟的验证习惯每次部署完 OpenSSL 1.1.1我不会立刻跑业务而是先执行两条命令。第一条是性能冒烟测试/opt/openssl-1.1.1/bin/openssl speed -evp aes-256-gcm -seconds 2-seconds 2把测试时间压短避免在服务器上跑太久。正常机器 AES-256-GCM 每秒算几 GB 到几十 GB 都有关键是结果不会报not available。如果它告诉你EVP routines:错误说明新构建的库没有正确编译 AES-NI 支持或者编译器把指令集关掉了。这条命令也顺便验证了命令行版本和动态库版本属于同一个安装目录。第二条是证书哈希目录检查。很多服务端程序和客户端库在加载 CA 证书时需要证书的哈希文件名。用c_rehash可以在 1.1.1 的 ssl 目录下生成这些哈希软链/opt/openssl-1.1.1/bin/c_rehash /opt/openssl-1.1.1/ssl/certs执行后再列出目录ls -l /opt/openssl-1.1.1/ssl/certs/ | head如果看到类似12345678.0 - ca.crt的软链说明 CA 目录可用。这个步骤很多人忽略直到程序报unable to get local issuer certificate才想起来。我有个习惯凡是用到SSL_CTX_load_verify_locations()的项目我都让客户端指向这个已 rehash 的目录而不是单个 CA 文件。最后我会用一小段脚本验证整体版本和库路径/opt/openssl-1.1.1/bin/openssl version -a | grep -E OPENSSLDIR|OPENSSL_CONF|Engine|SECLEVEL这能看到配置目录、默认配置文件和安全级别。如果OPENSSLDIR不是你自己指定的路径后续生成证书时可能写到错误的位置。我在这上面吃过一次亏装到/opt但 openssldir 忘了设结果openssl req默认去读/usr/local/ssl/openssl.cnf配置文件全乱。从那以后我每次装完必查这几个字段再跑一次speed和c_rehash前后十分钟能省下后面几天的排障时间。希望这些习惯对你也有帮助。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 17:54:26 · 阅读 1.2k OpenSSL 1.1.1编译部署与TLS配置避坑指南
简介这是一份面向Windows 32位系统的OpenSSL 1.1.1完整开发与运行资源包适合需要在C/C项目中集成SSL/TLS加密功能的开发者或需要配置安全网络通信的运维人员。压缩包共2000个文件约16.22MB主要包含bin目录下的openssl.exe命令行工具与动态链接库、include目录中的API头文件、lib目录下的静态库与导入库以及html目录中的完整API参考文档。其中HTML文档提供了详尽的使用教程与函数说明头文件覆盖SSL、加密、证书等核心模块可支撑从证书生成到数据加密的各类场景。该版本修复了此前多项安全漏洞并支持AES-GCM、CHACHA20/POLY1305等现代密码算法内存管理与多线程性能亦有优化。已有1042人学习下载对正在Windows环境下构建安全通信应用的开发者具有直接参考价值。1. OpenSSL 1.1.1一个已经 EOL 却还在承担生产业务的老版本为什么还要认真对待它OpenSSL 1.1.1 是很矛盾的存在官方早已停止支持但大量服务器、嵌入式设备、存量代码还在跑它。不是不想升级而是 TLS 1.3 的支持、与旧密码套件的兼容、以及一堆私有扩展没有做完让很多团队只能守着这个版本继续维护。这篇笔记解决四件事怎么把 1.1.1 编译干净、怎么用它做证书和 TLS 配置、最常见的坑在哪、以及部署后如何快速验证它是不是真的健康。适合被旧环境绑住又必须补安全能力的开发者和运维。2. 编译部署 OpenSSL 1.1.1configure、make、install 的前后边界2.1 configure 参数别乱加prefix 和 shared 是第一步我拿到 1.1.1 的源码包第一件事不是执行./config而是确认系统里有 Perl 5.10 以上并且make、gcc都在。1.1.1 的构建脚本是 Perl 写的环境不对会在 configure 阶段直接报Cant locate Config.pm这类错误。如果你在容器里先装好 build-essential 和 perl 模块再往下走。我一般用最小化参数开始避免一开始就引入一堆不熟悉的开关./config \ --prefix/opt/openssl-1.1.1 \ --openssldir/opt/openssl-1.1.1/ssl \ shared \ no-async逻辑说明--prefix决定安装根目录--openssldir决定私钥、证书、openssl.cnf 等配置文件的默认位置。shared要求生成动态库libssl.so.1.1和libcrypto.so.1.1如果不加默认都是静态库后续其他程序链接时非常痛苦。no-async是我当时为了绕开某些容器环境的 io_setup 限制加的但后来发现它才是导致s_client崩溃的元凶具体在避坑章节讲。所以如果你不确定系统有没有 async 问题不要加no-async。configure 完成后我会检查 configdata.pm 里实际生效的路径因为命令行写了--prefix但 libdir 可能会默认落到lib而不是lib64grep -E ^(prefix|openssldir|libdir) configdata.pm这个命令输出三个关键目录。如果libdir是lib而你的系统是 64 位且希望库在lib64可以在 configure 时加--libdirlib64。不过多数 Linux 发行版都能正确识别只是在部分交叉编译环境里会失手。2.2 make -j 与 install 后如何让全系统识别编译这一步我会先跑单核再跑并行。很多人直接make -j$(nproc)结果在头文件生成阶段遇到竞争报错信息非常玄学openssl/ssl.h: No such file or directory其实 make 依赖顺序乱了。1.1.1 的 Makefile 在并行处理上不算完美所以我的习惯是make -j1 make -j$(nproc)第一遍单核确保所有生成步骤按顺序完成第二遍并行加速。如果第一次单核都失败问题多半是缺少依赖库或编译器版本太老而不是 make 本身。安装到独立 prefix 后make install不会覆盖系统原有 OpenSSL但动态库路径不会自动进入系统缓存。需要手动写 ld 配置make install echo /opt/openssl-1.1.1/lib /etc/ld.so.conf.d/openssl-111.conf ldconfig逻辑说明ldconfig只扫描ld.so.conf里登记的目录如果不写文件动态链接器就找不到新的libssl.so.1.1。写好后可以用ldconfig -p | grep ssl验证。注意如果你为了临时调用新库而用LD_LIBRARY_PATH/opt/openssl-1.1.1/lib那这个变量会全局接管可能导致系统里其他依赖旧版本的程序出问题。我建议优先用 ld.conf 文件而不是到处 export。2.3 与系统自带 1.0.2 或 3.x 共存PATH 和依赖的优先级生产环境里最怕的是把不同版本的libssl.so搞混。OpenSSL 的 soname 是跟着大版本走的1.0.2 是libssl.so.1.0.01.1.1 是libssl.so.1.13.x 是libssl.so.3。理论上只要不强制做软链覆盖这几个版本可以和平共存。但我见过某开发者为了满足一个老应用的编译需求把/opt/openssl-1.1.1/lib/libssl.so.1.1手动软链到/usr/lib/libssl.so结果依赖旧版本的程序全部报undefined symbol。所以共存的第一原则是不要把新版本库强制覆盖到系统的默认 soname 上。我一般通过编译参数控制程序链接到哪个版本gcc -o myapp myapp.c \ -I/opt/openssl-1.1.1/include \ -L/opt/openssl-1.1.1/lib \ -Wl,-rpath,/opt/openssl-1.1.1/lib \ -lssl -lcrypto逻辑说明-Wl,-rpath把库路径写进程序的动态链接器搜索路径这样运行时即使LD_LIBRARY_PATH变了也不会误链其他版本的 SSL 库。如果你用 CMake可以设CMAKE_PREFIX_PATH但最终要确认myapp的DT_RPATH或DT_RUNPATH指向了 1.1.1 的目录。需要临时使用 1.1.1 的命令行时我再写一个环境脚本export PATH/opt/openssl-1.1.1/bin:$PATH export LD_LIBRARY_PATH/opt/openssl-1.1.1/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH/opt/openssl-1.1.1/lib/pkgconfig:$PKG_CONFIG_PATH注意这个脚本只用于当前 shell。如果你同时维护多个版本最好在每个服务启动脚本里单独指定而不是全局 source。3. 用 OpenSSL 1.1.1 生成私钥、CSR 和自签证书从零到可用的命令链3.1 生成 RSA/ECC 私钥与 CSRgenpkey 和 req 的参数权衡1.1.1 里genrsa还能用但官方已经推荐genpkey。区别在于genpkey通过-pkeyopt统一指定算法参数更灵活。生产环境我一般用 3072 位 RSA 或 P-256 椭圆曲线。原因很简单2048 位在 1.1.1 的安全级别设置里处于临界如果以后 security level 上调到 22048 还能用但证书链里的根若小于 2048 就会有问题。3072 位性能损耗不大兼容性也好。openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:3072 \ -aes-256-cbc \ -pass pass:YourPassphrase \ -out server.key逻辑说明-aes-256-cbc对私钥做对称加密-pass指定加密口令。如果你不希望口令出现在 shell 历史里可以把pass:YourPassphrase换成file:keypass.txt。私钥文件权限建议chmod 600 server.key。ECC 私钥则指定曲线openssl genpkey -algorithm EC \ -pkeyopt ec_paramgen_curve:prime256v1 \ -out eckey.pem逻辑说明prime256v1是 NIST P-256绝大多数协议栈都支持。不要为了追求安全性盲目上secp384r1有些老客户端和硬件设备不支持这条曲线。生成后可以用openssl pkey -in eckey.pem -text -noout查看曲线名称。生成 CSR 时1.1.1 的新增参数-addext很好用可以直接把 SAN 加进去避免再写 extfileopenssl req -new \ -key server.key \ -out server.csr \ -subj /CCN/STBeijing/LBeijing/OExample Corp/CNexample.com \ -addext subjectAltNameDNS:example.com,DNS:www.example.com注意-addext在 1.0.2 里不存在如果你的自动化脚本还要兼容老版本就不要用这个参数。另外CN现在只是“常用名”没有浏览器会因为它而信任你必须依赖 SAN。3.2 自签证书与扩展属性x509 命令的 v3 指定自签证书有两种方式一条命令从 CSR 直接签或者用 extfile 控制扩展。我用后者更可控。先写一个 extfilecat ext.cnf EOF basicConstraintscritical,CA:true keyUsagecritical,digitalSignature,keyEncipherment subjectAltNameDNS:example.com EOF openssl x509 -req \ -in server.csr \ -signkey server.key \ -days 825 \ -extfile ext.cnf \ -out server.crt逻辑说明-days 825是比 365 更适合内部证书的时长因为很多客户端检查证书有效期超过 825 天会拒绝。basicConstraintscritical,CA:true表示这个证书也充当 CA如果只是服务器证书应该设CA:false否则证书被拿去签发其他证书就危险了。keyUsage需要和握手场景匹配加了keyEncipherment才能做 RSA 密钥交换。如果你只是想快速测试也可以直接从 CSR 拷贝扩展openssl x509 -req -in server.csr -signkey server.key -days 825 -copy_extensions copy -out server.crt注意-copy_extensions copy在 1.1.1 里是测试特性如果 CSR 里的扩展内容不正确也会原样带进去所以正式用途还是用 extfile 显式声明。生成后一定要检查openssl x509 -in server.crt -noout -text | grep -A2 Subject Alternative Name如果输出是DNS:example.com就是对的。这里最容易踩坑的是忘记把www.example.com也加进 SAN结果用户访问带 www 的域名时报证书不匹配。3.3 用 s_server 和 s_client 验证证书链和握手证书生成后我会立刻在本机起一个临时服务验证openssl s_server -accept 4433 \ -cert server.crt \ -key server.key \ -www \ -tls1_3逻辑说明-www让服务把连接信息输出到浏览器方便快速查看。-tls1_3强制只使用 TLS 1.3如果证书或客户端不支持会立刻暴露。如果你要测试双向认证再加-Verify 1 -CAfile ca.crt。然后另开终端openssl s_client -connect 127.0.0.1:4433 \ -servername example.com \ -CAfile server.crt \ -brief逻辑说明-servername触发 SNI-CAfile把自签证书当作根证书来验证。-brief是 1.1.1 较新的选项只打印协议版本、加密套件和证书是否验证通过。握手成功会看到Verification: OK如果证书有问题会报Certificate chain的错误。这里常见的翻车是证书文件本身包含中间证书需要用-showcerts查看完整链。4. 1.1.1 下的 cipher suite、security level 和 TLS 1.3 配置4.1 查看和选择密码套件别把 ssl_cipher 和 tls13_cipher 混在一起OpenSSL 1.1.1 同时支持 TLS 1.2 和 1.3但两者的密码套件命名空间完全不同。TLS 1.3 只有五个官方套件名字形如TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256等。控制 TLS 1.2 的ssl_ciphers指令管不到 1.3。在最常见的 nginx 配置里1.1.1 对应的写法是# 控制 TLS 1.2 及以下 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; # 控制 TLS 1.3 ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;我用命令行查看某个套件是否可用openssl ciphers -v ECDHE-RSA-AES128-GCM-SHA256:!aNULL | head -10逻辑说明-v列出套件名称、协议版本、签名算法和密钥交换类型。!aNULL排除匿名式套件防止中间人伪装。如果你手写应用代码需要调用SSL_CTX_set_ciphersuites()设置 1.3 套件调用SSL_CTX_set_cipher_list()设置 1.2 及以下套件。忘记后者是很多开发者在 1.1.1 上升级时的通病。4.2 security level 对不同密钥长度的影响Security Level 是 1.1.1 继承自 1.1.0 的安全分级范围 0 到 5。默认是 level 1允许 1024 位 RSA 证书和 SHA1 签名但不允许 512 位 DH 参数。level 2 要求所有证书密钥 2048 位SHA1 签名会被拒。level 3 要求 3072 位。这个阈值直接决定你对接的老设备能不能握手。判断当前版本默认安全级别openssl version -a | grep SECLEVEL如果看到输出SECLEVEL1说明默认比较宽松。如果你在服务端代码里调高了级别比如SSL_CTX_set_security_level(ctx, 2)那么一台只持有 1024 位 RSA 证书的旧客户端就会握手失败服务端日志通常只显示handshake failure不会告诉你级别问题。排查时可以用 s_client 指定同一级别openssl s_client -connect 10.0.0.5:443 -security_level 1 -brief如果这样能连上而默认级别连不上基本可以断定是 security level 造成的。我碰到过某设备商的网关只支持 1024 位证书为了兼容它我给那个监听端口单独设了一个 contextsecurity level 设为 1其余端口保持 level 2。不要全局降级。4.3 DH 参数与会话复用性能和安全之间的小控制TLS 1.3 握手使用 ECDHE不再需要传统的静态 DH 参数。但 TLS 1.2 及以下仍可能用到 DHE 套件此时服务端需要dhparam。如果你没有显式提供OpenSSL 1.1.1 会用内置的 2048 位参数字但有些老客户端只认特定长度的参数。生成 2048 位 DH 参数openssl dhparam -out dhparam.pem 2048逻辑说明2048 位足够4096 位会让握手变慢且某些旧设备不接受。生成后在 nginx 里加ssl_dhparam /opt/openssl-1.1.1/ssl/dhparam.pem;。会话复用方面1.1.1 同时支持 session cache 和 session ticket。排查性能问题时我会在 s_server 上关闭 ticket逼着客户端走 cacheopenssl s_server -accept 4433 -cert server.crt -key server.key -no_ticket -www然后客户端连接两次观察Reused, TLSv1.3这类输出。如果显示New说明 cache 没有命中。原因可能是 cache 配置太小或者客户端每次都发新的 SNI。这里我踩过的坑是在负载均衡后面多个后端节点各自维护 session cache导致客户端每次落到不同节点就新建会话。解决办法是配置共享 cache或者干脆用 ticket 并统一 ticket key。1.1.1 里生成统一的 key 调用openssl rand 48但这属于更复杂的部署先知道方向即可。5. OpenSSL 1.1.1 避坑部署半年遇到的 5 个具体问题5.1 编译时加上 no-asyncs_client 启动即崩溃现象编译时用了no-async安装后openssl version正常但执行openssl s_client -connect example.com:443会直接段错误。原因OpenSSL 1.1.1 的 EVP 接口在某些算法实现里会通过 async 模块管理硬件异步等待。如果编译时禁用了 async部分接口返回的句柄是空的导致后续调用崩溃。这个问题只在 Linux AIO 受限的容器里容易出现我一开始以为 no-async 能规避 io_setup 限制结果反而破坏了运行时逻辑。解决去掉no-async重新编译。如果容器环境真的不允许 IO 系统调用可以在运行时用OPENSSL_ia32cap调整指令集或者给容器的 seccomp 配置放行io_setup和io_submit。我后来验证过绝大多数普通 Linux 机器不需要 no-async加它纯属给自己找麻烦。5.2 生成的证书没有 SANChrome 直接不认现象用 1.1.1 生成自签证书后浏览器访问 HTTPS 报NET::ERR_CERT_COMMON_NAME_INVALID但openssl verify显示证书有效。原因1.1.1 时代的主流浏览器已经完全忽略 CN 字段只认 subjectAltNameSAN。我的 CSR 里只写了-subj /CNexample.com没有 SAN所以证书里没有可用的域名标识。解决重新生成 CSR并加上-addext subjectAltNameDNS:example.com。如果证书已签发只能重签。我把 SAN 写进配置模板每次openssl req都从模板里读取避免人工输入遗漏。命令如下cat csr.cnf EOF [ req ] distinguished_name req_dn req_extensions v3_req [ req_dn ] CN example.com [ v3_req ] subjectAltName DNS:example.com, DNS:www.example.com EOF openssl req -new -key server.key -out server.csr -config csr.cnf注意req_extensions必须指定为v3_req否则扩展不会写入 CSR。5.3 Security Level 2 拒绝 1024 位证书老设备握手失败现象某设备商的客户端证书是 1024 位 RSA握手时服务端不断报alert handshake failure抓包显示客户端发送证书后服务端直接返回 alert。原因服务端通过SSL_CTX_set_security_level(ctx, 2)把级别提高后证书公钥长度低于 2048 位握手过程中对端证书校验失败但日志不会明确提示“too weak key”非常隐蔽。解决先用openssl s_client -security_level 1测试如果能连上说明是级别问题。然后给老设备单独建一个 context 或监听端口把 security level 保持在 1。不要全局降级否则新接入的 3072 位环境会担心整体安全水位下降。更好的方案是推动设备方把证书换成 2048 位但有些离线设备没得选只能兼容。5.4 TLS 1.3 的密码套件配置了等于没配置现象在 nginx 里用ssl_ciphers TLS_AES_128_GCM_SHA256;后客户端握手结果仍然是TLS_AES_256_GCM_SHA384。原因nginx 的ssl_ciphers指令只作用于 OpenSSL 的 cipher list而 TLS 1.3 的 ciphersuites 是另一个 APISSL_CTX_set_ciphersuites控制的。在 OpenSSL 1.1.1 里两者分得很清楚nginx 在 1.1.1 环境下需要借助ssl_conf_command才能配置 1.3 套件。解决在 nginx 配置中ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;如果你自己写 C/C 服务用SSL_CTX_set_ciphersuites()函数。验证方式openssl s_client -connect 127.0.0.1:443 -brief 21 | grep Cipher is如果输出不是你配置的套件检查服务端进程是否真的加载了 1.1.1 的动态库而不是系统旧版本。5.5 libssl.so.1.1 被软链覆盖后系统里一半服务启动失败现象某服务器升级后sshd、curl、postfix 等大量程序报undefined symbol: SSL_CTX_set_options有些直接无法启动。原因某部署脚本为了“统一版本”把/opt/openssl-1.1.1/lib/libssl.so.1.1软链到/usr/lib/libssl.so覆盖了原本链接到libssl.so.1.0.0的符号表入口。虽然文件名不同但很多老程序编译时依赖的是libssl.so这个无版本号的软链覆盖后它们找到了库但找不到旧符号。解决用patchelf或ldd查看具体依赖把错误的软链删掉恢复原有 soname 秩序。我写了一个快速扫描脚本find / -name libssl.so* -o -name libcrypto.so* 2/dev/null | xargs ls -l看到多个版本共存时注意不要让无版本号的libssl.so指向任何具体版本除非你真的知道自己在做什么。正确做法是在应用编译时通过 rpath 指定版本而不是动系统软链。6. 部署后我用 speed 和 c_rehash 做健康检查一个十分钟的验证习惯每次部署完 OpenSSL 1.1.1我不会立刻跑业务而是先执行两条命令。第一条是性能冒烟测试/opt/openssl-1.1.1/bin/openssl speed -evp aes-256-gcm -seconds 2-seconds 2把测试时间压短避免在服务器上跑太久。正常机器 AES-256-GCM 每秒算几 GB 到几十 GB 都有关键是结果不会报not available。如果它告诉你EVP routines:错误说明新构建的库没有正确编译 AES-NI 支持或者编译器把指令集关掉了。这条命令也顺便验证了命令行版本和动态库版本属于同一个安装目录。第二条是证书哈希目录检查。很多服务端程序和客户端库在加载 CA 证书时需要证书的哈希文件名。用c_rehash可以在 1.1.1 的 ssl 目录下生成这些哈希软链/opt/openssl-1.1.1/bin/c_rehash /opt/openssl-1.1.1/ssl/certs执行后再列出目录ls -l /opt/openssl-1.1.1/ssl/certs/ | head如果看到类似12345678.0 - ca.crt的软链说明 CA 目录可用。这个步骤很多人忽略直到程序报unable to get local issuer certificate才想起来。我有个习惯凡是用到SSL_CTX_load_verify_locations()的项目我都让客户端指向这个已 rehash 的目录而不是单个 CA 文件。最后我会用一小段脚本验证整体版本和库路径/opt/openssl-1.1.1/bin/openssl version -a | grep -E OPENSSLDIR|OPENSSL_CONF|Engine|SECLEVEL这能看到配置目录、默认配置文件和安全级别。如果OPENSSLDIR不是你自己指定的路径后续生成证书时可能写到错误的位置。我在这上面吃过一次亏装到/opt但 openssldir 忘了设结果openssl req默认去读/usr/local/ssl/openssl.cnf配置文件全乱。从那以后我每次装完必查这几个字段再跑一次speed和c_rehash前后十分钟能省下后面几天的排障时间。希望这些习惯对你也有帮助。本文还有配套的精品资源点击获取