2.2.12 在Windows下编译OpenSSL 1.0.2m_WindowsC/C++加密解密实战-QQ阅读男生都市网

上QQ阅读APP看书，第一时间看更新

2.2.12　在Windows下编译OpenSSL 1.0.2m

这个1.0.2版本属于当前主流使用的版本，无论是维护老项目，还是开发新项目，这个版本都用得比较多，因为其成熟、稳定。尤其对于信息安全相关的项目，建议大家不要直接使用很新的算法库，因为可能有潜在的Bug没有被发现。该版本下载地址：https://www.openssl.org/source/old/。

这里我们下载openssl-1.0.2m.tar.gz，把它复制到C:（也可以是其他目录），然后按照下面的步骤开始编译和安装。这里我们编译32位的Debug版本的动态库。

（1）安装ActivePerl。这个软件我们前面已经介绍过了，这里不再赘述。

（2）安装NASM。可以到https://www.nasm.us/下载新版安装包，这里下载的是nasm-2.14-installer-x64.exe，下载下来后直接双击安装。安装完毕后，要在系统变量Path中配置NASM程序所在路径，这里采用默认安装路径，所以NASM的路径是：C:\Program Files\NASM，把它添加到Path系统变量中，如图2-22所示。

图2-22

单击“确定”按钮。然后打开一个命令行窗口，输入命令nasm，此时界面显示如图2-23所示。

图2-23

这说明NASM安装并配置成功了。好了，准备工作完成，可以正式开始编译OpenSSL了。为了让大家知道不指定目录OpenSSL会把生成的文件放在哪里，我们先在不指定路径的情况下进行编译。

1．不指定生成目录的32位Release版本动态库的编译

（1）解压OpenSSL源码目录。把openssl-1.0.2m.tar.gz复制到某个目录下，比如C:，然后解压缩，解压后的目录为C:\openssl-1.0.2m，进入C:\openssl-1.0.2m，就可以看到各个子文件夹了。

（2）配置OpenSSL。打开VC 2017的“VS 2017的开发人员命令提示符”提示窗口，单击“开始”→“所有程序”→“Visual Studio 2017”→“Visual Studio Tools”→“VS 2017的开发人员命令提示符”，输入命令如下：

cd C:\openssl-1.0.2m
perl Configure VC-WIN32
ms\do_nasm
nmake -f ms\ntdll.mak

VC-WIN32表示生成Release版本的32位的库，如果需要Debug版本，就使用debug-VC-WIN32。ntdll.mak表示即将生成动态链接库。执行完毕后，我们可以在C:\openssl-1.0.2m\out32dll\下看到生成的动态链接库，比如libeay32.dll，如图2-24所示。

图2-24

该文件夹除了包括动态库外，相关的导入库文件（比如libeay32.lib和ssleay32.lib）和一些可执行的工具（.exe）程序也在该目录下。导入库文件在开发中需要引用，所以我们需要知道它的路径。

头文件文件夹所在的路径是C:\openssl-1.0.2m\inc32\，开发的时候我们可以把inc32下的OpenSSL文件夹复制到工程目录，再在VC工程设置中添加引用，就可以使用头文件了。当然，不复制到工程目录也可以，只要在VC中引用到这里的路径即可。稍后我们会通过实例来演示如何使用这里编译出来的动态库。如果大家觉得在OpenSSL目录下去找这个子目录很麻烦，也可以执行安装命令：nmake -f ms\ntdll.mak install，执行该命令后，将会把include文件夹、lib文件夹、和bin文件夹复制到在C:\usr\local\ssl下，有兴趣的读者可以试试。

重要提示：如果编译过程中出错，建议把C:\openssl-1.0.2m这个文件夹删除，然后重新解压，再按上面的步骤执行。

好了，下面我们进行指定生成目录下的编译。一般这种方式用得多，这样可以和OpenSSL源码目录分离开来。

2．指定生成目录的32位Release版本动态库的编译

（1）如果C盘已经有openssl-1.0.2m文件夹，就解压OpenSSL源码目录。把openssl-1.0.2m.tar.gz复制到C:，然后解压缩，解压后的目录为C:\openssl-1.0.2m，进入C:\openssl-1.0.2m，就可以看到各个子文件夹了。如果C盘已经有openssl-1.0.2m文件夹，可以不用再解压。

cd C:\openssl-1.0.2m
perl Configure VC-WIN32 --prefix=c:/myOpensllout
ms\do_nasm
nmake -f ms\ntdll.mak

--prefix用于指定安装目录，就是生成的文件存放的目录；VC-WIN32表示生成Release版本的32位的库，如果需要Debug版本，就使用debug-VC-WIN32。稍等片刻，编译完成，如图2-25所示。

图2-25

此时可以看到C盘下并没有myOpensslout，因为我们还没有执行安装命令，但可以在C:\openssl-1.0.2m\out32dll\下看到生成的动态链接库，比如libeay32.dll。头文件文件夹OpenSSL所在的路径为C:\openssl-1.0.2m\inc32\。下面执行安装命令：

nmake -f ms\ntdll.mak install

执行完毕后，我们看到C盘下有myOpensslout了，如图2-26所示。

图2-26

如果喜欢干净，可以用nmake -f ms\ntdll.mak clean命令清理一下。

至此，32位动态库编译安装完成。下面进入验证环节。

【例2.9】验证32位动态库

（1）新建一个控制面板工程test。

（2）打开test.cpp，输入代码如下：

（3）打开工程属性对话框，然后添加头文件包含路径：C:\myopensslout\include，以及导入库路径：C:\myopensslout\lib。如果此时运行程序，系统干净的朋友是无法运行的，会提示缺少动态库，如图2-27所示。

图2-27

但有些朋友发现可以直接运行，难道上面生成的lib文件是静态库，而不是导入库。其实是导入库，我们可以验证一下。打开VC 2017的“VS 2017的开发人员命令提示符”提示窗口，即单击“开始”→“所有程序”→“Visual Studio 2017”→“Visual Studio Tools”→“VS 2017的开发人员命令提示符”，输入命令如下：

lib /list C:\myopensslout\lib\libeay32.lib

如果输出的是LIBEAY32.dll，就说明libeay32.lib是一个导入库，如果输出的是.obj，就说明是静态库。既然不是静态库，为何能运行起来呢？说明系统路径肯定存在libeay32.dll。大家可以去C:\Windows\SysWOW64或C:\Windows\System32等常见系统路径下搜索，如果删掉或重命名后还能运行test.exe，就说明安装了某些软件导致test.exe依然能找到libeay32.dll，比如安装了ice3.7.2这个通信库。或许有朋友到这里有点怀疑test.exe是否真的依赖libeay32.dll，大家可以验证一下，如果有Dependency Walker工具就查看一下依赖项，如图2-28所示。

图2-28

如果没有Dependency Walker工具，也可以使用VC 2017的dumpbin程序，把test.exe复制到C盘下，然后VC 2017的“VS 2017的开发人员命令提示符”提示窗口，然后输入命令dumpbin /dependents c:\test.exe，如图2-29所示。

图2-29

可以看到的确依赖libeay32.dll。另外，可以发现把test.exe放到一个干净的操作系统上，就运行不起来了。如果一定要知道libeay32.dll在哪里，也不是没有可能。大招就是使用Dependency Walker，这个依赖项查看工具自VC 6开始就自带了，后来高版本的VC虽然不带它了，但可以从官网（www.dependencywalker.com）上下载。这里还是使用VC 6自带的1.0版。我们把test.exe拖进Dependency walker工具，然后单击工具栏上的c:\按钮，它用于显示全路径，如图2-30所示。

图2-30

可以看到，test.exe依赖的libeay32.dll位于system32下，终于找到元凶了，把它删除再运行test.exe会发现无法运行。

绕了一大圈，让系统干净的朋友久等了，继续把C:\myopensslout\bin下的libeay32.dll复制到解决方案路径下的Debug子目录下，即和test.exe同一文件夹下。

（4）保存工程并运行，运行结果如图2-31所示。

图2-31

这里测试工程test用了Debug模式，而库libeay32.dll是Release版本的，这是没问题的。

3．编译64位Release版本的动态库

首先把C盘下的openssl-1.0.2m文件夹删除（如果有的话），然后按照下面的步骤进行：

（2）配置OpenSSL。单击“开始”→“Visual Studio 2017”→“Visual Studio Tools”→“VS 2017的开发人员命令提示符”，打开VC 2017的“VS 2017的开发人员命令提示符”窗口，输入命令如下：

cd C:\openssl-1.0.2m
perl Configure VC-WIN64A no-asm --prefix=c:/myopensslstout64
ms\do_win64A
nmake -f ms\ntdll.mak

--prefix用于指定安装目录，就是生成的文件存放的目录。VC-WIN64A表示生成Release版本的64位的库，如果需要Debug版本，就使用debug-VC-WIN64A。稍等片刻，编译完成，如图2-32所示。

图2-32

此时我们看到C盘下并没有文件夹myopensslout64，这是因为还没有执行安装命令，但可以在C:\openssl-1.0.2m\out32dll\下看到生成的动态链接库，比如libeay32.dll。头文件文件夹OpenSSL所在的路径为C:\openssl-1.0.2m\inc32\，有些多疑的读者可能会疑惑，为何64位的.dll文件会生成在名字是out32dll的文件夹下，看名字out32dll像是存放32位的库。笔者认为这是OpenSSL官方偷懒的地方，这样的文件夹名字的确容易引起歧义，为了消除读者的疑惑，我们可以验证一下生成的libeay32.dll到底是32位还是64位的，方法有多种：

（1）在“VS 2017的开发人员命令提示符”窗口的提示符下输入命令：

dumpbin /headers c:\openssl-1.0.2m\out32dll\libeay32.dll

如果出现machine（x64）字样，就说明该库是64位库，如图2-33所示。

图2-33

（2）如果安装的是VC 6，可以用VC 6自带的Dependency Walker工具来查看，因为VC 6自带的该工具（版本是1.0）只能查看32位的动态库，所以64位的库拖进去是看不到信息的，如图2-34所示。

图2-34

当然，现在高版本的Dependency Walker工具已经可以同时查看32位和64位的库了。不过，VC 2017不自带这个小工具，如果读者需要的话可以去官网（http://www.dependencywalker.com/）下载。

只有执行了安装命令才会把生成的库、头文件等放到我们指定的目录myOpenSSLout64下。下面执行安装命令：

nmake -f ms\ntdll.mak install

执行完毕后，如图2-35所示。

图2-35

仔细看图2-35，我们发现其实就是把out32dll下的内容复制到C:/myopensslout64下。此时我们看到C盘下有myopensslout64了。至此，64位的动态库编译安装完成。下面进入验证阶段。

【例2.10】验证64位动态库

（1）新建一个控制面板工程test。

（2）打开test.cpp，输入代码如下：

（3）打开工程属性对话框，新建一个x64平台，在工程属性中切换到Release模式，然后添加头文件包含路径：C:\myopensslout64\include，以及导入库路径：C:\myopensslout64\lib。

（4）保存工程，然后在工具栏上选择解决方案平台为x64，解决方案配置为Release，并把C:\myopensslout64\bin下的libeay32.dll复制到解决方案的x64文件夹下的Release文件夹下，然后运行工程，运行结果如图2-36所示。

图2-36

4．编译64位Debug版本的静态库

本来编译完动态库想结束本节的讲解，但考虑有朋友喜欢静态库，所以笔者再演示一下静态库的编译过程。首先把C盘下的openssl-1.0.2m文件夹删除（如果有的话），然后按下面的步骤进行：

（2）配置OpenSSL。单击“开始”→“所有程序”→“Visual Studio 2017”→“Visual Studio Tools”→“VS 2017的开发人员命令提示符”，打开VC 2017的“VS 2017的开发人员命令提示符”窗口，输入命令如下：

cd C:\openssl-1.0.2m
perl Configure debug-VC-WIN64A --prefix=c:/myopensslout64
ms\do_win64A
nmake -f ms\ntdll.mak

--prefix用于指定安装目录，就是生成的文件存放的目录。VC-WIN64A表示生成Release版本的64位的库，如果需要Debug版本，就使用debug-VC-WIN64A。稍等片刻，编译完成。