📚 课程目录第4章 Windows平台PKI SDK环境搭建

第4章 Windows平台PKI SDK环境搭建：OpenSSL、CNG、CAPI的安装与配置

大家好啊，我是老赵。做跨平台PKI测试这么多年，Windows这块踩过的坑排第一。你想想看，Windows下面同时杵着三套主子——OpenSSL、CNG、CAPI，每套脾气都不一样。本章咱们就把它们一个个请进系统，安好了、配顺了，后面跑测试才不闹心。

核心目标：在三台Windows机器（或一台虚拟机快照）上分别装好OpenSSL 3.0、CNG SDK工具和CAPI的cryptoAPI接口，确保各自能签发证书、做加密运算，且彼此不冲突。

4.1 整体环境鸟瞰

先画个图，帮你把这三套东西在系统里的位置看清楚。

我的习惯：在搭建前先打好快照。万一哪个SDK把系统CSP弄乱，恢复起来只需一分钟。嗯，真遇到过——装某版本OpenSSL时它自己注册了一个legacy provider，把CAPI的默认RSP给冲了。

4.2 OpenSSL 安装与配置

OpenSSL在Windows上其实没那么“纯原生”，我个人更推荐用vcpkg或预编译包。但为了测试兼容性，建议手工装一个完全独立的版本。

4.2.1 安装步骤

下载：从官方GitHub releases或slproweb.com获取Windows版OpenSSL 3.0.x（选择全安装包，带开发库）。
安装路径：强烈建议装到 C:\OpenSSL-Win64\ ，别带空格，别用Program Files——我在项目里吃过CMake找不到路径的亏。
系统环境变量：
- 添加 OPENSSL_ROOT_DIR=C:\OpenSSL-Win64
- 追加 PATH=%OPENSSL_ROOT_DIR%\bin
验证：新开命令行执行 openssl version，应输出 OpenSSL 3.0.x。

4.2.2 配置要点

记得把 openssl.cnf 拷贝到 %OPENSSL_ROOT_DIR%\ssl\ 下。默认的配置里dir路径是Unix风格，你要改成Windows路径，否则后面ca、req命令会报错。

# 修改 openssl.cnf 中的 [ CA_default ]
dir = C:/OpenSSL-Win64/ssl/demoCA

曾经遇过：某同事把 dir 写成 C:\OpenSSL-Win64\ssl\demoCA，反斜杠在config中被当成转义符，OpenSSL直接挂了半小时。结论：在config文件里老老实实用正斜杠。

4.3 CNG 环境搭建

CNG（Cryptography Next Generation）是Windows Vista之后的主打加密框架。它最大的好处是——原生集成，装好Windows SDK就等于拥有了CNG的头文件和库。

4.3.1 获取SDK

你只需要安装 Windows 10/11 SDK（建议版本10.0.20348.0以上）。安装时勾选「Windows SDK for Desktop Apps」即可。

组件	路径示例	说明
头文件	`C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0\um\`	ncrypt.h, bcrypt.h, wincrypt.h
库文件	`C:\Program Files (x86)\Windows Kits\10\Lib\10.0.20348.0\um\x64\`	ncrypt.lib, bcrypt.lib
工具	`C:\Program Files (x86)\Windows Kits\10\bin\10.0.20348.0\x64\`	certutil.exe（用于测试CNG密钥存储）

4.3.2 验证CNG是否正常

certutil -csp "Microsoft Software Key Storage Provider" -key

如果输出列出了一些密钥容器，就说明CNG的KSP工作正常。我一般还会写个小测试程序调用 NCryptOpenStorageProvider，确认能打开MS KSP。

避坑：不要用 CertOpenStore 去枚举CNG密钥——那是CAPI的老接口。CNG要用 NCryptEnumKeys。这两套的密钥存储格式完全不同。

4.4 CAPI 环境准备

CAPI（Cryptographic API，也叫CryptoAPI）是老大哥。从Windows 2000就存在了。它的SDK其实也藏在Windows SDK里，不过CAPI不需要额外安装——系统自带。

但要注意，CAPI有两套Provider：

Base CSP：软件实现，默认可用
Enhanced CSP：支持更强算法，但部分老系统可能缺失

我建议你在 C:\CAPI_Test 下放一个测试脚本，专门验证CAPI基本功能：

# PowerShell 调用 CAPI 测试
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class CAPITest {
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool CryptAcquireContext(
        out IntPtr phProv, string pszContainer,
        string pszProvider, uint dwProvType, uint dwFlags);
    public static void Test() {
        IntPtr hProv;
        bool res = CryptAcquireContext(out hProv, null, null, 1, 0x80000000);
        Console.WriteLine("CAPI AcquireContext: " + res);
    }
}
"@
[CAPITest]::Test()

4.4.1 需要手动配置吗？

基本不需要。但如果你做硬件安全模块(HSM)兼容测试，可能需要安装HSM厂商提供的CSP，然后在注册表 HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider 下注册。嗯，这部分和CNG的KSP注册机制不同，后面专门章节讲。

4.5 三者共存时的互操作检查

三套SDK装好之后，还需要确认它们能和平共处——尤其不能互相干扰密钥存储。

检查项	OpenSSL	CNG	CAPI
密钥存储位置	文件（.pem/.der）	KSP（注册表/TPM）	CSP（注册表/硬件）
默认算法	RSA/ECC	RSA/ECC/ECDH	RSA/DSA/DH
证书格式	PEM/DER/PKCS12	PFX (CNG密钥容器)	PFX (CAPI密钥容器)
导出兼容性	通用	需CNG导出策略	需CAPI导出标志

我个人会做一组交叉测试：用OpenSSL生成一个RSA2048私钥，通过PKCS12导入到Windows证书存储，然后用CAPI和CNG分别读取该证书的私钥，看能否签名。你会发现奇怪的事——同一份PKCS12，CAPI能读出来，CNG有时会拒绝，因为CNG要求私钥标记为「可导出」。这就是后来在兼容性那章要重点讲的坑。

曾经翻车：我在一次自动化测试里，先用CNG生成密钥，然后用CAPI的CryptAcquireCertificatePrivateKey去拿。结果返回NTE_BAD_KEY_STATE。后来才明白CNG的密钥默认是NCRYPT_MACHINE_KEY_FLAG，CAPI那边需要设置特殊标志才能访问。所以环境搭好后一定要先跑这个交叉验证。

4.6 本章小结与练习

好，装完这三样东西，你的Windows测试机基本就绪了。我建议你动手做个检查清单：

☐ OpenSSL 命令行输出版本号
☐ 能用OpenSSL生成自签证书并写入文件
☐ 能用certutil -csp列举CNG密钥
☐ 能用CAPI的CryptAcquireContext拿到Provider句柄
☐ 能通过PKCS12文件在OpenSSL、CNG、CAPI之间传递密钥

把这些步骤写成批处理或PowerShell脚本，以后重装环境时一键跑通。嗯，这也是自动化测试的起点——环境本身必须先可重复构建。