根本原因是私钥未持久化或访问受限；必须显式使用X509KeyStorageFlags.MachineKeySet | PersistKeySet | Exportable加载PFX，否则签名时系统找不到密钥句柄。
为什么 X509Certificate2 加载 PFX 后调用 SignData 会报“Key does not exist”？
根本原因不是证书没加载成功，而是 PFX 中私钥未被正确提取或访问受限。Windows 默认启用“密钥容器保护”，即使你用密码打开了 X509Certificate2，私钥句柄仍可能因 keyStorageFlags 设置不当而不可用。
实操建议：
- 加载时必须显式传入
X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable—— 尤其PersistKeySet是关键，它把私钥持久化到当前用户或机器密钥存储中，否则签名时系统找不到可用密钥句柄 - 避免只用
new X509Certificate2("cert.pfx", "pwd")这种无标志的构造方式，它默认使用UserKeySet，在服务环境（如 IIS、Windows Service）下极易失败 - 验证私钥是否可用：加载后检查
cert.HasPrivateKey，再调用cert.GetRSAPrivateKey()（.NET Core 2.1+ / .NET 5+）或cert.PrivateKey（.NET Framework），若返回 null 或抛异常，说明私钥不可访问
如何用 RSACryptoServiceProvider 或 RSA 对数据做 SHA256 签名？
.NET Framework 和 .NET Core+ 的签名 API 差异明显，不能混用。老项目常用 RSACryptoServiceProvider.SignData，但该类在 .NET Core 3.0+ 已标记为过时；新项目应统一走 RSA.SignData + HashAlgorithmName.SHA256 + RSAEncryptionPadding.Pkcs1。
实操建议：
- 不要手动拼接哈希再签名 ——
SignData内部已自动哈希，重复哈希会导致验签失败 - 签名前确认数据是
byte[]，不是 Base64 字符串或 UTF-8 编码后的多余字节；常见错误是把 JSON 字符串直接转Encoding.UTF8.GetBytes后签名，但接收方解码时用了不同编码（如 BOM 头、换行符差异） - 示例（.NET 6+）：
using var rsa = cert.GetRSAPrivateKey(); byte[] signature = rsa.SignData(data, HashAlgorithmName.SHA256, RSAEncryptionPadding.Pkcs1);
签名后怎么让 Java 或 OpenSSL 验证通过？
跨语言验签失败，90% 出在签名格式和填充方式不一致。C# 默认用 PKCS#1 v1.5 填充，但 Java 的 Signature.getInstance("SHA256withRSA") 要求完全匹配；OpenSSL 则对 DER 编码敏感。
实操建议：
- 确保公钥导出为标准 PEM 格式（
-----BEGIN CERTIFICATE-----），而非 PFX 或 DER 二进制 —— Java/OpenSSL 通常不直接读 PFX - 签名结果是原始字节数组，别自动转 Base64 再传给对方，除非协议明确约定；Java 验签时需用
signature.update(data); signature.verify(sigBytes)，其中sigBytes必须与 C# 输出的byte[]完全一致（包括字节序、长度） - 如果对方坚持用 OpenSSL 命令行验证，先用
openssl x509 -in cert.pem -pubkey -noout > pub.key提取公钥，再用openssl dgst -sha256 -verify pub.key -signature sig.bin data.bin，注意data.bin必须与 C# 签名时输入的原始字节完全相同
生产环境部署 PFX 证书要注意哪些权限陷阱？
本地开发能跑通，一上服务器就报“拒绝访问”或“对象同步方法被调用”，大概率是证书私钥 ACL 权限缺失，尤其 Windows Server + IIS 或 Windows Service 场景。
实操建议：
- 用
certmgr.msc或FindPrivateKey.exe工具定位私钥文件路径（通常在%ProgramData%\Microsoft\Crypto\RSA\MachineKeys\下某随机命名文件），然后右键 → 属性 → 安全 → 添加运行应用的账户（如IIS_IUSRS、NETWORK SERVICE或自定义服务账号），赋予“读取”权限 - 避免在代码里硬编码 PFX 路径和密码；改用 Windows Certificate Store（
StoreLocation.LocalMachine）+ 指纹查找，并设置好存储区访问控制 - 若用 Azure App Service 或 Docker，PFX 无法写入 MachineKeys，必须改用
X509KeyStorageFlags.EphemeralKeySet并确保每次加载都带完整密码 —— 但该标志不支持导出私钥，所以不能用于需要后续加密的场景
实际用起来最麻烦的往往不是签名逻辑本身，而是证书生命周期管理：PFX 密码轮换、私钥 ACL 更新、跨平台编码一致性、以及那个永远查不到日志的“Access is denied”错误——它背后可能只是少点了一次“高级安全设置”里的继承复选框。
