“bad_decrypt”错误通常由密码错误或密钥格式问题引发，而非文件权限问题；真正因权限导致的失败表现为permission denied、nte_bad_keyset或keyset does not exist等系统级错误。

“bad_decrypt”错误看似指向解密失败，但实际常与私钥权限无关——它多由密码错误或密钥格式问题引发。真正因权限导致的解密失败，通常不会直接报这个字符串，而是表现为系统级拒绝访问（如Permission denied、Keyset does not exist或NTE_BAD_KEYSET），尤其在Windows CryptoAPI或Azure扩展场景中。

先确认是不是真权限问题

OpenSSL类报错（如PHP中openssl_pkey_get_private()返回false并伴随bad decrypt）90%以上是密码输错，不是文件没读权限。因为：

• OpenSSL加载私钥时，若密码错误，会触发asn1 encoding routines:ASN1_get_object:too long或bad decrypt，而非系统IO错误
• Linux/macOS下用ls -l key.pem确认属主和权限（推荐600），但即使权限为644，只要内容正确+密码对，依然能解密成功
• Windows上私钥若存于CNG密钥容器，权限问题表现为CryptAcquireContext失败并返回NTE_BAD_KEYSET，不是“bad_decrypt”

哪些场景才真要查权限？

以下情况需重点检查文件或密钥容器权限：

• Azure VM扩展失败：日志出现FailedToDecryptProtectedSettings + Keyset does not exist → 检查Crypto\RSA\MachineKeys目录权限，确保NT AUTHORITY\NETWORK SERVICE有读取权
• Windows服务调用CryptoAPI：使用CryptAcquireContext打开私钥容器失败 → 验证是否用了CRYPT_MACHINE_KEYSET标志，且服务账户对机器级密钥容器有访问权
• Java应用读取PKCS#12密钥库：抛java.security.UnrecoverableKeyException: Get Key failed → 检查keystore文件权限，以及JVM运行用户能否访问该路径（特别是Docker容器内挂载卷时）

快速验证权限是否生效

不依赖猜测，用最小动作验证：

• Linux：切换到应用运行用户执行cat /path/to/key.pem 2>/dev/null || echo "fail"
• Windows（PowerShell）：Get-Acl 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' | fl，确认对应SID有ReadAndExecute
• Java服务：在启动脚本中加-Djavax.net.debug=ssl:handshake，观察握手日志是否卡在“reading private key”之前

别让“bad_decrypt”带偏方向

看到这个词，第一反应不该是改chmod或加ACL，而应：

• 立刻调用openssl_error_string()（PHP）或检查javax.net.debug输出（Java），看底层真实错误
• 用openssl rsa -in key.pem -check -noout验证私钥结构是否完整（无需密码）
• 确认私钥是否加密：含DEK-Info:行即为密码保护，此时必须传对密码；否则传空密码也会报“bad decrypt”