尧图网站建设 
简介面向Windows 64位平台C/C开发者的OpenSSL静态库集成包专门解决在Windows下难以获得预编译OpenSSL库、手动编译又需配置Perl与nasm工具链的痛点。压缩包共83个文件、约31.6MB以75个.h头文件和2个.lib静态库为主体头文件与库文件对应完整可直接在Visual Studio等IDE中配置引用另有3个exe安装/工具程序、1个cpp示例源码以及cnf配置、gz源码包等配套文件方便按需查看或二次编译。附带的ActivePerl和nasm安装包与openssl-1.0.2m源码包一同构成完整的编译环境若想自行定制编译参数或升级版本也不必再去逐一下载依赖。win64下的demo示例演示了静态库的链接与基本调用方式适合初学者理解初始化、加密/解密等核心流程也适合项目集成时快速对照参考。目前已有1215人学习下载是Windows下做安全通信、数字证书或加密算法开发时的实用工具包。 这段时间在 Windows 64 位环境下把 OpenSSL 完整编译了一遍顺手整理出了静态库、安装包和可直接打开的 demo 示例。如果你之前自己尝试过在 Windows 上编译 OpenSSL应该明白这条链路有多折腾——工具链、依赖、汇编器、命令行环境任何一环没对齐都可能卡住半天。所以我这次把编译产物和示例源码一起打包目的就是让你拿到手之后直接能#include、直接能链接、直接能跑。这篇内容不仅是给一个下载地址我会把编译思路、目录结构、工程配置和踩过的坑全部写清楚。适合这几类人要在 Windows 下做 C/C 开发、需要集成 RSA/AES/SHA 等算法、不想花一个下午去折腾编译环境的同学以及正在被各种链接错误折磨的同行。1. 为什么要把 OpenSSL 编译成静态库一次部署就少一堆破事1.1 动态库与静态库的现实取舍OpenSSL 官方在 Windows 下默认构建方式其实是动态库也就是会生成libcrypto-3-x64.dll、libssl-3-x64.dll这类文件。动态库的好处是多个程序可以共享同一份文件升级时只需要替换 DLL 就行。但在实际项目里动态库带来的问题往往比好处更明显目标机器上缺 DLL、DLL 路径配置不对、不同程序依赖不同版本的 OpenSSL 导致互相覆盖甚至杀毒软件把某些 DLL 当风险文件处理。我在内部工具项目里被这种问题坑过不止一次最后干脆全改静态链接。静态库的做法是把 OpenSSL 的代码直接编进你的 exe发布时只要带一个可执行文件就够了。对工具类程序、内部服务、需要拷到各种环境跑的小程序来说这几乎是最省心的方案。代价是 exe 体积会变大、编译时间会变长但相比部署时遇到的各种玄学问题这点代价很值得。1.2 静态库真正要留意的三个前提静态库不是简单地编译出来就行你在使用之前要确认三件事架构一致x64 的静态库只能给 x64 程序用。你拿 Win32 工程去链接 x64 的 lib链接器会直接报LNK1112: module machine type x64 conflicts with target machine type x86。运行库一致OpenSSL 在 MSVC 下默认按/MD编译如果你的工程强制使用/MT链接时会报LNK2038 mismatch detected for RuntimeLibrary。这个后面专门讲。系统依赖OpenSSL 在 Windows 上依赖ws2_32、crypt32这几个系统库链接静态库时需要手动补上否则会出现LNK2019 无法解析的外部符号。这三个问题我在下面的 demo 工程里都会处理你也可以直接照抄配置。2. 编译前最容易翻车的环境准备Perl、NASM 和开发者命令行2.1 别让 perl is needed by openssl 拦住你打开 OpenSSL 源码目录执行Configure脚本时如果报perl is needed by openssl是因为 OpenSSL 的构建系统从 configure 到生成 Makefile 全是用 Perl 脚本写的Windows 不自带 Perl需要自己装。我推荐用 Strawberry Perl安装的时候注意勾选Add Perl to PATH否则后面执行perl -v依然找不到命令。装完之后在命令行里验证一下perl -v能正常打印版本信息就说明 Perl 环境没问题了。2.2 NASM 没进 PATHconfigure 照样陪你玩到最后NASM 是 OpenSSL 编译汇编优化代码用的。如果你的目标是性能最大化的正式环境别跳过这一步。不装 NASM 也能 configure 成功但你最终编译出来的库没有汇编优化RSA 这类计算密集型操作性能会明显差一截。最容易踩的坑是NASM 装了但没把安装目录加进 PATHconfigure 执行时找不到。更诡异的是OpenSSL 在 configure 阶段有时候不会立刻报错而是等到 nmake 编译中途才告诉你找不到nasm这时候再回头折腾环境变量就非常浪费时间。建议在 configure 之前先确认where nasm有路径输出再继续。2.3 务必用 x64 Native Tools 命令行而不是普通 CMD很多人习惯性地打开普通 CMD然后执行nmake结果报nmake 不是内部或外部命令。这是因为 nmake 和 cl 编译器的环境变量需要在专门的环境里加载。正确做法是在开始菜单里找到 Visual Studio 安装目录下的x64 Native Tools Command Prompt for VS 2022版本号随你的 VS 版本变化右键以管理员身份运行。在这个命令行里where cl和where nmake都能找到对应路径。3. configure 与 nmake 全流程一条命令的每一个参数都是有讲究的3.1 下载哪个版本源码如果是从零开始我建议新项目直接用 OpenSSL 3.x 系列比如 3.3.x。如果是要兼容老项目、或者原来代码里用了不少 1.1.1 的旧 API那 1.1.1w 是最后一个 1.1.1 版本很多老工程到现在还在用。两种版本我都编译了一份目录结构保持一致所以你根据自己的项目情况选即可。3.2 configure 参数详解以 OpenSSL 3.x 为例完整配置命令如下perl Configure VC-WIN64A no-shared --prefixC:\OpenSSL --openssldirC:\OpenSSL\ssl逐项解释一下VC-WIN64A指定使用 MSVC 编译器、目标架构是 64 位。在 Windows 上编译 OpenSSL 不能随便写linux-x86_64那种平台参数必须用这套专门的命名。no-shared告诉构建系统只生成静态库不生成 DLL。这是整个配置命令里最关键的一个参数。--prefix安装路径。编译完成后头文件、库文件和配置文件都会按标准结构输出到这个目录下。--openssldirOpenSSL 运行时的配置目录主要放openssl.cnf。如果你的机器上 NASM 没有配置好、只是想快速先编译通一个版本做验证可以临时加上no-asmperl Configure VC-WIN64A no-shared no-asm --prefixC:\OpenSSL --openssldirC:\OpenSSL\ssl注意no-asm会关闭汇编优化正式发布时要记得去掉。3.3 编译、自检与安装配置完成之后依次执行nmake这一步会把 libcrypto 和 libssl 编译出来。整个过程根据机器性能大约需要 5 到 15 分钟中间如果弹出nmake fatal error优先检查是不是 NASM 路径问题或者换用no-asm重新 configure。然后执行自检nmake test自检会跑相当长一段时间主要是验证算法实现的正确性。如果你只是内部使用、不想等可以跳过去但我还是建议跑一遍OpenSSL 的测试套件覆盖面很广能筛出不少环境相关问题。最后安装到指定目录nmake install安装完成后检查一下C:\OpenSSL目录正常情况下会有include、lib、bin、ssl这几个子目录。4. 发布包里到底有什么静态库文件、命令行工具和 demo 工程4.1 目录结构说明我打包好的完整目录结构如下openssl-win64/ ├─ bin/ │ ├─ openssl.exe # 命令行工具 │ └─ openssl.cfg # 默认配置文件 ├─ include/ │ └─ openssl/ # 全部头文件 ├─ lib/ │ ├─ libcrypto.lib # 静态库文件 │ └─ libssl.lib # 静态库文件 ├─ demo/ │ ├─ sha256_demo/ # VS 可直接打开的示例工程 │ │ ├─ sha256_demo.cpp │ │ └─ sha256_demo.vcxproj │ ├─ aes_demo/ │ └─ README.md ├─ INSTALL.txt # 环境配置说明 └─ LICENSES/libcrypto.lib是核心加密库包含 AES、RSA、SHA、MD5 等算法实现。libssl.lib是 TLS/SSL 协议层如果你只是用对称加密、哈希、签名这些能力链接 libcrypto 就够了如果要写 HTTPS 客户端那还需要 libssl。4.2 直接用 openssl.exe 做快速验证安装包里的openssl.exe是官方构建的命令行工具日常用来生成密钥、查看证书、计算哈希非常方便。我打包时已经把bin目录和配置文件一起放好了在命令行里切到该目录直接执行openssl version能正常输出版本信息说明工具和配置都没问题。平时想快速验证一个文件的 SHA256openssl dgst -sha256 yourfile.bin生成自签名证书这类操作也可以用它完成openssl.cfg配置好之后基本不太会报错。5. demo 工程实战从 include 到链接到完整可运行5.1 VS 工程配置头文件、库目录和附加依赖项如果你用 Visual Studio 创建自己的工程配置方法如下C/C - 常规 - 附加包含目录添加C:\OpenSSL\include链接器 - 常规 - 附加库目录添加C:\OpenSSL\lib链接器 - 输入 - 附加依赖项添加libcrypto.lib、libssl.lib、ws2_32.lib、crypt32.lib、user32.lib、advapi32.lib最后那四个系统库很多人会漏掉。ws2_32提供 socket 相关接口crypt32提供 Windows 证书库操作支持user32和advapi32是 OpenSSL 在 Windows 平台上一些辅助功能依赖的库。漏掉任何一个链接阶段都会报一堆LNK2019。5.2 一个零依赖的 SHA256 示例demo 工程里包含了一个最简的 SHA256 示例核心代码如下#include openssl/evp.h #include cstdio #include cstring #include string static std::string bytes_to_hex(const unsigned char* data, unsigned int len) { static const char* hex 0123456789abcdef; std::string out; for (unsigned int i 0; i len; i) { out.push_back(hex[data[i] 4]); out.push_back(hex[data[i] 0x0F]); } return out; } int main() { const char* msg hello openssl static lib; unsigned char digest[EVP_MAX_MD_SIZE]; unsigned int digest_len 0; EVP_MD_CTX* ctx EVP_MD_CTX_new(); EVP_DigestInit_ex(ctx, EVP_sha256(), nullptr); EVP_DigestUpdate(ctx, msg, strlen(msg)); EVP_DigestFinal_ex(ctx, digest, digest_len); EVP_MD_CTX_free(ctx); printf(sha256(%s) %s\n, msg, bytes_to_hex(digest, digest_len).c_str()); return 0; }这段代码使用了 OpenSSL 的 EVP 接口是官方推荐的高级 API比直接调用底层的SHA256_*函数兼容性更好。如果你用命令行方式编译可以这样验证cl /EHsc /I C:\OpenSSL\include sha256_demo.cpp /link C:\OpenSSL\lib\libcrypto.lib ws2_32.lib crypt32.lib /out:sha256_demo.exe注意这里的/I和/link参数顺序很关键头文件路径要在编译阶段指定库路径要在链接阶段指定写反了会提示找不到文件。5.3 链接不上的常见报错与排查思路我整理了几条最常见的链接报错以及对应的处理方案你可以直接对照排查报错信息原因处理方式LNK2019 unresolved external symbol __imp_CertOpenStore缺少 crypt32 依赖附加依赖项中加入crypt32.libLNK2019 unresolved external symbol WSAStartup缺少 ws2_32 依赖附加依赖项中加入ws2_32.libLNK1104 cannot open file libcrypto.lib库路径不对或架构不匹配检查附加库目录确认是 x64 库LNK2038 mismatch detected for RuntimeLibrary运行库/MT与/MD不一致统一工程的运行库设置处理这类问题的通用思路是先看缺少的符号属于哪一类接口再判断是哪个库提供的。网络相关就找ws2_32证书相关就找crypt32别一言不合就去重编 OpenSSL。6. 把静态库接进现有工程时你需要绕开的坑6.1 运行库 /MT 与 /MD 不一致默认情况下MSVC 编译 OpenSSL 时使用的运行库是/MD也就是动态运行时。如果你的工程配置是/MT静态运行时链接静态库时会直接报LNK2038。解决思路有两种。第一种把工程改成/MD这是最省事的方案但可能会导致可执行文件体积变大且需要目标机器有对应版本的 VC 运行库。第二种重新编译一份/MT版本的 OpenSSL 静态库configure 完成后在生成的 Makefile 里全局搜索/MD并替换成/MT然后重新 nmake。两种方式我都实测过第二种更一劳永逸适合对运行时依赖要求苛刻的项目。另外要提醒一点OpenSSL 官方一般只发布 Release 版本库。如果你在 Debug 配置的工程里链接 Release 库虽然一般能编译通过但调试时可能看不到内部符号建议开发时也用 Release 配置。6.2 系统依赖库ws2_32、crypt32 等缺一不可这个问题我在 5.1 里列过一次表格这里再强调一下为何它们“缺一不可”。OpenSSL 在 Windows 上实现 TLS 连接最底层必须调用操作系统的 socket 接口这部分由ws2_32.lib提供访问 Windows 系统证书存储区、校验系统根证书时需要crypt32.lib提供相关 API。很多静态库的使用者习惯只加一个libcrypto.lib结果链接时报出一堆莫名其妙的符号错误。建议在工程里固定维护一个公共配置项把以下这个列表写死libcrypto.lib libssl.lib ws2_32.lib crypt32.lib user32.lib advapi32.lib项目里所有依赖 OpenSSL 的子模块都复用这一份配置能省掉不少来回排查的时间。6.3 Qt 的 pro 文件怎么指定静态库如果你的项目用的是 Qt在.pro文件里这样配置INCLUDEPATH C:/OpenSSL/include LIBS -LC:/OpenSSL/lib -llibcrypto -llibssl LIBS -lws2_32 -lcrypt32 -luser32 -ladvapi32注意 Qt 的LIBS里路径分隔符建议用正斜杠否则某些构建环境会解析出错。如果链接时提示找不到-llibcrypto也可以改成直接写文件路径的方式LIBS C:/OpenSSL/lib/libcrypto.lib C:/OpenSSL/lib/libssl.lib6.4 发布静态库给同事时的交接清单自己在本地编译好只是第一步如果还要把这套库交给团队其他成员建议至少交付这几样东西include目录头文件必须完整。lib目录下的静态库文件。一份简单的 README写清楚架构、编译参数、运行库类型、需要额外链接的系统库。一个能编译通过的 demo 工程作为“最小验证用例”。我打包的发布里把这四样都放全了团队里新同事拿到手之后最快五分钟就能跑通第一个基于 OpenSSL 的程序。当初我自己折腾这堆东西花了整整一个下午现在把这些坑都填好后面的人就不用再重复踩一遍了。本文还有配套的精品资源点击获取 Windows下OpenSSL静态库编译与集成：从源码到链接配置全指南
简介面向Windows 64位平台C/C开发者的OpenSSL静态库集成包专门解决在Windows下难以获得预编译OpenSSL库、手动编译又需配置Perl与nasm工具链的痛点。压缩包共83个文件、约31.6MB以75个.h头文件和2个.lib静态库为主体头文件与库文件对应完整可直接在Visual Studio等IDE中配置引用另有3个exe安装/工具程序、1个cpp示例源码以及cnf配置、gz源码包等配套文件方便按需查看或二次编译。附带的ActivePerl和nasm安装包与openssl-1.0.2m源码包一同构成完整的编译环境若想自行定制编译参数或升级版本也不必再去逐一下载依赖。win64下的demo示例演示了静态库的链接与基本调用方式适合初学者理解初始化、加密/解密等核心流程也适合项目集成时快速对照参考。目前已有1215人学习下载是Windows下做安全通信、数字证书或加密算法开发时的实用工具包。 这段时间在 Windows 64 位环境下把 OpenSSL 完整编译了一遍顺手整理出了静态库、安装包和可直接打开的 demo 示例。如果你之前自己尝试过在 Windows 上编译 OpenSSL应该明白这条链路有多折腾——工具链、依赖、汇编器、命令行环境任何一环没对齐都可能卡住半天。所以我这次把编译产物和示例源码一起打包目的就是让你拿到手之后直接能#include、直接能链接、直接能跑。这篇内容不仅是给一个下载地址我会把编译思路、目录结构、工程配置和踩过的坑全部写清楚。适合这几类人要在 Windows 下做 C/C 开发、需要集成 RSA/AES/SHA 等算法、不想花一个下午去折腾编译环境的同学以及正在被各种链接错误折磨的同行。1. 为什么要把 OpenSSL 编译成静态库一次部署就少一堆破事1.1 动态库与静态库的现实取舍OpenSSL 官方在 Windows 下默认构建方式其实是动态库也就是会生成libcrypto-3-x64.dll、libssl-3-x64.dll这类文件。动态库的好处是多个程序可以共享同一份文件升级时只需要替换 DLL 就行。但在实际项目里动态库带来的问题往往比好处更明显目标机器上缺 DLL、DLL 路径配置不对、不同程序依赖不同版本的 OpenSSL 导致互相覆盖甚至杀毒软件把某些 DLL 当风险文件处理。我在内部工具项目里被这种问题坑过不止一次最后干脆全改静态链接。静态库的做法是把 OpenSSL 的代码直接编进你的 exe发布时只要带一个可执行文件就够了。对工具类程序、内部服务、需要拷到各种环境跑的小程序来说这几乎是最省心的方案。代价是 exe 体积会变大、编译时间会变长但相比部署时遇到的各种玄学问题这点代价很值得。1.2 静态库真正要留意的三个前提静态库不是简单地编译出来就行你在使用之前要确认三件事架构一致x64 的静态库只能给 x64 程序用。你拿 Win32 工程去链接 x64 的 lib链接器会直接报LNK1112: module machine type x64 conflicts with target machine type x86。运行库一致OpenSSL 在 MSVC 下默认按/MD编译如果你的工程强制使用/MT链接时会报LNK2038 mismatch detected for RuntimeLibrary。这个后面专门讲。系统依赖OpenSSL 在 Windows 上依赖ws2_32、crypt32这几个系统库链接静态库时需要手动补上否则会出现LNK2019 无法解析的外部符号。这三个问题我在下面的 demo 工程里都会处理你也可以直接照抄配置。2. 编译前最容易翻车的环境准备Perl、NASM 和开发者命令行2.1 别让 perl is needed by openssl 拦住你打开 OpenSSL 源码目录执行Configure脚本时如果报perl is needed by openssl是因为 OpenSSL 的构建系统从 configure 到生成 Makefile 全是用 Perl 脚本写的Windows 不自带 Perl需要自己装。我推荐用 Strawberry Perl安装的时候注意勾选Add Perl to PATH否则后面执行perl -v依然找不到命令。装完之后在命令行里验证一下perl -v能正常打印版本信息就说明 Perl 环境没问题了。2.2 NASM 没进 PATHconfigure 照样陪你玩到最后NASM 是 OpenSSL 编译汇编优化代码用的。如果你的目标是性能最大化的正式环境别跳过这一步。不装 NASM 也能 configure 成功但你最终编译出来的库没有汇编优化RSA 这类计算密集型操作性能会明显差一截。最容易踩的坑是NASM 装了但没把安装目录加进 PATHconfigure 执行时找不到。更诡异的是OpenSSL 在 configure 阶段有时候不会立刻报错而是等到 nmake 编译中途才告诉你找不到nasm这时候再回头折腾环境变量就非常浪费时间。建议在 configure 之前先确认where nasm有路径输出再继续。2.3 务必用 x64 Native Tools 命令行而不是普通 CMD很多人习惯性地打开普通 CMD然后执行nmake结果报nmake 不是内部或外部命令。这是因为 nmake 和 cl 编译器的环境变量需要在专门的环境里加载。正确做法是在开始菜单里找到 Visual Studio 安装目录下的x64 Native Tools Command Prompt for VS 2022版本号随你的 VS 版本变化右键以管理员身份运行。在这个命令行里where cl和where nmake都能找到对应路径。3. configure 与 nmake 全流程一条命令的每一个参数都是有讲究的3.1 下载哪个版本源码如果是从零开始我建议新项目直接用 OpenSSL 3.x 系列比如 3.3.x。如果是要兼容老项目、或者原来代码里用了不少 1.1.1 的旧 API那 1.1.1w 是最后一个 1.1.1 版本很多老工程到现在还在用。两种版本我都编译了一份目录结构保持一致所以你根据自己的项目情况选即可。3.2 configure 参数详解以 OpenSSL 3.x 为例完整配置命令如下perl Configure VC-WIN64A no-shared --prefixC:\OpenSSL --openssldirC:\OpenSSL\ssl逐项解释一下VC-WIN64A指定使用 MSVC 编译器、目标架构是 64 位。在 Windows 上编译 OpenSSL 不能随便写linux-x86_64那种平台参数必须用这套专门的命名。no-shared告诉构建系统只生成静态库不生成 DLL。这是整个配置命令里最关键的一个参数。--prefix安装路径。编译完成后头文件、库文件和配置文件都会按标准结构输出到这个目录下。--openssldirOpenSSL 运行时的配置目录主要放openssl.cnf。如果你的机器上 NASM 没有配置好、只是想快速先编译通一个版本做验证可以临时加上no-asmperl Configure VC-WIN64A no-shared no-asm --prefixC:\OpenSSL --openssldirC:\OpenSSL\ssl注意no-asm会关闭汇编优化正式发布时要记得去掉。3.3 编译、自检与安装配置完成之后依次执行nmake这一步会把 libcrypto 和 libssl 编译出来。整个过程根据机器性能大约需要 5 到 15 分钟中间如果弹出nmake fatal error优先检查是不是 NASM 路径问题或者换用no-asm重新 configure。然后执行自检nmake test自检会跑相当长一段时间主要是验证算法实现的正确性。如果你只是内部使用、不想等可以跳过去但我还是建议跑一遍OpenSSL 的测试套件覆盖面很广能筛出不少环境相关问题。最后安装到指定目录nmake install安装完成后检查一下C:\OpenSSL目录正常情况下会有include、lib、bin、ssl这几个子目录。4. 发布包里到底有什么静态库文件、命令行工具和 demo 工程4.1 目录结构说明我打包好的完整目录结构如下openssl-win64/ ├─ bin/ │ ├─ openssl.exe # 命令行工具 │ └─ openssl.cfg # 默认配置文件 ├─ include/ │ └─ openssl/ # 全部头文件 ├─ lib/ │ ├─ libcrypto.lib # 静态库文件 │ └─ libssl.lib # 静态库文件 ├─ demo/ │ ├─ sha256_demo/ # VS 可直接打开的示例工程 │ │ ├─ sha256_demo.cpp │ │ └─ sha256_demo.vcxproj │ ├─ aes_demo/ │ └─ README.md ├─ INSTALL.txt # 环境配置说明 └─ LICENSES/libcrypto.lib是核心加密库包含 AES、RSA、SHA、MD5 等算法实现。libssl.lib是 TLS/SSL 协议层如果你只是用对称加密、哈希、签名这些能力链接 libcrypto 就够了如果要写 HTTPS 客户端那还需要 libssl。4.2 直接用 openssl.exe 做快速验证安装包里的openssl.exe是官方构建的命令行工具日常用来生成密钥、查看证书、计算哈希非常方便。我打包时已经把bin目录和配置文件一起放好了在命令行里切到该目录直接执行openssl version能正常输出版本信息说明工具和配置都没问题。平时想快速验证一个文件的 SHA256openssl dgst -sha256 yourfile.bin生成自签名证书这类操作也可以用它完成openssl.cfg配置好之后基本不太会报错。5. demo 工程实战从 include 到链接到完整可运行5.1 VS 工程配置头文件、库目录和附加依赖项如果你用 Visual Studio 创建自己的工程配置方法如下C/C - 常规 - 附加包含目录添加C:\OpenSSL\include链接器 - 常规 - 附加库目录添加C:\OpenSSL\lib链接器 - 输入 - 附加依赖项添加libcrypto.lib、libssl.lib、ws2_32.lib、crypt32.lib、user32.lib、advapi32.lib最后那四个系统库很多人会漏掉。ws2_32提供 socket 相关接口crypt32提供 Windows 证书库操作支持user32和advapi32是 OpenSSL 在 Windows 平台上一些辅助功能依赖的库。漏掉任何一个链接阶段都会报一堆LNK2019。5.2 一个零依赖的 SHA256 示例demo 工程里包含了一个最简的 SHA256 示例核心代码如下#include openssl/evp.h #include cstdio #include cstring #include string static std::string bytes_to_hex(const unsigned char* data, unsigned int len) { static const char* hex 0123456789abcdef; std::string out; for (unsigned int i 0; i len; i) { out.push_back(hex[data[i] 4]); out.push_back(hex[data[i] 0x0F]); } return out; } int main() { const char* msg hello openssl static lib; unsigned char digest[EVP_MAX_MD_SIZE]; unsigned int digest_len 0; EVP_MD_CTX* ctx EVP_MD_CTX_new(); EVP_DigestInit_ex(ctx, EVP_sha256(), nullptr); EVP_DigestUpdate(ctx, msg, strlen(msg)); EVP_DigestFinal_ex(ctx, digest, digest_len); EVP_MD_CTX_free(ctx); printf(sha256(%s) %s\n, msg, bytes_to_hex(digest, digest_len).c_str()); return 0; }这段代码使用了 OpenSSL 的 EVP 接口是官方推荐的高级 API比直接调用底层的SHA256_*函数兼容性更好。如果你用命令行方式编译可以这样验证cl /EHsc /I C:\OpenSSL\include sha256_demo.cpp /link C:\OpenSSL\lib\libcrypto.lib ws2_32.lib crypt32.lib /out:sha256_demo.exe注意这里的/I和/link参数顺序很关键头文件路径要在编译阶段指定库路径要在链接阶段指定写反了会提示找不到文件。5.3 链接不上的常见报错与排查思路我整理了几条最常见的链接报错以及对应的处理方案你可以直接对照排查报错信息原因处理方式LNK2019 unresolved external symbol __imp_CertOpenStore缺少 crypt32 依赖附加依赖项中加入crypt32.libLNK2019 unresolved external symbol WSAStartup缺少 ws2_32 依赖附加依赖项中加入ws2_32.libLNK1104 cannot open file libcrypto.lib库路径不对或架构不匹配检查附加库目录确认是 x64 库LNK2038 mismatch detected for RuntimeLibrary运行库/MT与/MD不一致统一工程的运行库设置处理这类问题的通用思路是先看缺少的符号属于哪一类接口再判断是哪个库提供的。网络相关就找ws2_32证书相关就找crypt32别一言不合就去重编 OpenSSL。6. 把静态库接进现有工程时你需要绕开的坑6.1 运行库 /MT 与 /MD 不一致默认情况下MSVC 编译 OpenSSL 时使用的运行库是/MD也就是动态运行时。如果你的工程配置是/MT静态运行时链接静态库时会直接报LNK2038。解决思路有两种。第一种把工程改成/MD这是最省事的方案但可能会导致可执行文件体积变大且需要目标机器有对应版本的 VC 运行库。第二种重新编译一份/MT版本的 OpenSSL 静态库configure 完成后在生成的 Makefile 里全局搜索/MD并替换成/MT然后重新 nmake。两种方式我都实测过第二种更一劳永逸适合对运行时依赖要求苛刻的项目。另外要提醒一点OpenSSL 官方一般只发布 Release 版本库。如果你在 Debug 配置的工程里链接 Release 库虽然一般能编译通过但调试时可能看不到内部符号建议开发时也用 Release 配置。6.2 系统依赖库ws2_32、crypt32 等缺一不可这个问题我在 5.1 里列过一次表格这里再强调一下为何它们“缺一不可”。OpenSSL 在 Windows 上实现 TLS 连接最底层必须调用操作系统的 socket 接口这部分由ws2_32.lib提供访问 Windows 系统证书存储区、校验系统根证书时需要crypt32.lib提供相关 API。很多静态库的使用者习惯只加一个libcrypto.lib结果链接时报出一堆莫名其妙的符号错误。建议在工程里固定维护一个公共配置项把以下这个列表写死libcrypto.lib libssl.lib ws2_32.lib crypt32.lib user32.lib advapi32.lib项目里所有依赖 OpenSSL 的子模块都复用这一份配置能省掉不少来回排查的时间。6.3 Qt 的 pro 文件怎么指定静态库如果你的项目用的是 Qt在.pro文件里这样配置INCLUDEPATH C:/OpenSSL/include LIBS -LC:/OpenSSL/lib -llibcrypto -llibssl LIBS -lws2_32 -lcrypt32 -luser32 -ladvapi32注意 Qt 的LIBS里路径分隔符建议用正斜杠否则某些构建环境会解析出错。如果链接时提示找不到-llibcrypto也可以改成直接写文件路径的方式LIBS C:/OpenSSL/lib/libcrypto.lib C:/OpenSSL/lib/libssl.lib6.4 发布静态库给同事时的交接清单自己在本地编译好只是第一步如果还要把这套库交给团队其他成员建议至少交付这几样东西include目录头文件必须完整。lib目录下的静态库文件。一份简单的 README写清楚架构、编译参数、运行库类型、需要额外链接的系统库。一个能编译通过的 demo 工程作为“最小验证用例”。我打包的发布里把这四样都放全了团队里新同事拿到手之后最快五分钟就能跑通第一个基于 OpenSSL 的程序。当初我自己折腾这堆东西花了整整一个下午现在把这些坑都填好后面的人就不用再重复踩一遍了。本文还有配套的精品资源点击获取