【发布时间】：2016-07-05 02:58:02
【问题描述】：
== 我的问题可能需要一些背景知识：
我正在使用来自 Oracle (Oracle Access Manager) 的产品，尝试配置一个测试配置，其中我拥有他们所谓的“webgate”，但在 webgate 和 OAM 服务器之间使用“CERT”模式进行通信。
启用 CERT 模式通常包括拥有证书、密钥和根 CA 证书，并且：
在 OAM 服务器上： - 将 CA 证书导入 Oracle 特定的 JKS 密钥库 - 将证书和加密密钥导入另一个 Oracle 特定的 JCEKS 密钥库
在 webgate 上： - 将证书文件、加密密钥文件和根 CA 文件的副本放入特定目录
通过测试，相同的证书+密钥（和根 CA 证书）可用于 OAM 服务器端和 webgate 端。
== 问题：
我使用从工作中获得的 cert+key (+ root CA) 使配置工作（由他们的 CA 颁发），但我希望能够使用我自己生成的证书，所以我已经一直在尝试使用 openssl 命令创建证书 + 密钥，但到目前为止，我还没有成功。当我对我创建的 cert/key/root CA 证书进行导入等操作时，我最终会收到“decrypt_error”：
NioProcessor-1，RECV TLSv1 ALERT：致命，decrypt_error
我一直在改进我用来颁发证书的 openssl.cnf，我发现我颁发的证书看起来与办公室的证书几乎相同，例如：
> [root@oam ~]# openssl x509 -in /apps/ca2/foo13.crt -text Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 15375053440205592664 (0xd55f29a4b21a1858)
> Signature Algorithm: sha1WithRSAEncryption
> Issuer: C=US, O=My Company, CN=JL-Test-CA
> Validity
> Not Before: Jul 5 01:03:02 2016 GMT
> Not After : Jul 3 01:03:02 2026 GMT
> Subject: C=US, ST=VA, L=Herndon, O=o, OU=ou, CN=foo13
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
> 00:e3:71:40:0f:a5:08:72:50:33:67:6e:57:a5:c0:
> 7d:b5:a7:26:4a:4c:af:ed:59:f1:42:57:a6:0e:a1:
> d5:aa:10:40:f5:d9:cf:bb:21:52:59:4b:54:0d:ca:
> ef:b6:6a:b7:c4:dd:d6:81:c0:d8:cb:5a:2d:69:ca:
> d4:ec:f1:c1:b7:03:32:f9:bd:9c:b8:77:43:1d:c0:
> c9:48:be:62:08:f2:57:29:a2:66:98:dd:c6:a2:97:
> 5c:53:8c:de:78:f1:b2:21:ef:eb:c2:83:9b:94:cb:
> a1:c1:df:20:f6:7f:b6:20:41:53:0a:4a:a2:a4:fa:
> c7:b7:3c:d9:09:7b:a5:7f:31:00:c9:9d:a4:cf:a1:
> 87:24:7f:9b:b0:62:0a:8a:ee:90:9c:56:61:e4:9f:
> f0:dc:1a:fb:66:34:95:3e:29:3d:50:27:b4:fb:5d:
> 7f:84:c2:c1:c1:6b:34:8f:cb:c1:de:51:5f:46:89:
> 74:00:a2:13:60:4a:36:7b:1c:70:90:c5:80:74:0f:
> 1c:0b:3e:3f:ed:6d:72:d5:4a:e9:2d:e4:88:4a:c7:
> c3:ff:d4:fa:8d:00:55:80:a4:51:59:3a:a1:9e:83:
> 2e:66:13:00:52:fc:aa:80:eb:f5:a0:55:6b:ee:99:
> 1e:cb:60:a6:e0:b8:21:e3:91:9c:c1:5f:6d:4e:62:
> 24:a3
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Certificate Policies:
> Policy: 2.16.840.1.101.2.1.11.7
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment
> X509v3 Extended Key Usage:
> TLS Web Server Authentication, TLS Web Client Authentication
> X509v3 Subject Key Identifier:
> F6:3D:09:31:E1:45:B1:96:0C:B8:A0:68:FE:40:1D:07:B6:D0:44:63
> X509v3 Authority Key Identifier:
> keyid:F9:56:E1:66:6C:B2:E0:31:F6:FF:E3:98:17:BB:15:88:45:55:4A:B8
>
> Signature Algorithm: sha1WithRSAEncryption
> 45:4e:91:32:44:be:1a:31:62:96:5a:42:61:94:13:6f:3a:ca:
> 44:1b:0c:6a:a2:10:3b:61:44:58:b2:34:b4:41:0d:2a:0c:26:
> ae:bc:e7:b2:9a:1e:c9:8a:25:5e:f2:55:19:22:06:44:4b:67:
> 83:39:b8:80:2d:b1:9f:06:b7:a7:ec:4c:08:3d:11:ec:c7:32:
> 03:49:70:05:7c:4b:4c:05:30:4d:06:a4:f1:0d:cf:f3:a6:37:
> 4d:d9:31:af:e1:f8:e6:b7:d7:62:7b:06:e0:82:dd:72:2c:1e:
> 92:f8:cd:03:f4:c0:67:cb:0b:ba:af:a6:1c:0b:ff:f2:44:07:
> 83:db:ac:5e:8d:94:fb:51:5c:a7:c3:89:9c:fb:69:c6:4f:49:
> b7:07:2d:c2:07:9f:46:b2:9a:2c:51:c5:50:c4:57:bf:b1:c7:
> e0:4b:02:d5:cb:f0:4c:14:a2:cf:73:fc:43:d2:4b:3e:19:0c:
> 25:d0:38:7e:98:f5:db:e6:15:12:bc:d0:3f:9d:93:10:9f:c3:
> be:29:bd:54:7f:97:ed:80:16:c7:28:1e:39:13:90:a1:15:fd:
> df:7b:d8:27:52:13:d4:6f:16:90:97:b6:dc:c0:a7:5a:6f:3e:
> e0:20:88:58:d4:e5:cf:49:bb:1c:00:3a:38:fb:fc:ab:f3:23:
> fd:89:45:73:9a:65:e9:72:a5:f2:f4:6e:08:a7:06:3e:2d:83:
> 1b:4d:9b:b9:9e:ef:a0:53:7a:3c:de:fb:b3:ee:6c:ab:46:d9:
> 42:f4:ee:0c:0a:88:59:7f:c4:31:33:53:57:a1:26:92:8b:f6:
> fd:95:82:d5:2a:7d:b8:72:fb:52:a3:35:6d:60:9d:2c:99:41:
> 29:6d:9f:48:91:1c:c1:78:1f:0f:6f:17:c9:42:51:3d:00:cd:
> f3:9c:69:9a:33:5d:0f:ca:3a:ee:d5:02:ca:e4:4d:d2:35:fc:
> 83:c9:f0:46:b2:a5:14:f8:56:59:c6:43:30:b7:33:40:2c:a3:
> 7e:07:76:d8:55:8d:35:ca:87:db:57:dd:30:25:90:68:84:89:
> ac:d8:61:a4:58:a5:08:56:64:95:5e:3c:6b:ac:2f:15:8e:02:
> f2:4d:e8:6b:e1:b3:af:4e:b0:30:97:c5:d1:00:8c:59:6b:f2:
> c6:9e:cb:3b:ed:a8:c3:af:8d:4f:75:d8:f3:65:5b:38:1e:18:
> 6b:03:ce:31:e3:8a:8a:02:84:3e:c0:e8:bb:ee:b5:4a:9c:f4:
> 51:f6:be:ac:b1:ea:0f:fc:0e:7d:98:78:8f:b5:8e:24:14:32:
> 64:52:bf:6a:94:59:70:e0:75:c8:17:7b:0e:00:5a:3b:a3:63:
> ff:ab:1a:0c:e1:43:e5:03
但是，无论我尝试过什么，当我尝试颁发的证书时，我总是会收到 decrypt_error。
所以，我一直在直观地比较“openssl x509”的输出，比较好的证书和我的证书，我注意到一个区别是我的证书中的“签名算法：sha1WithRSAEncryption”比良好/工作证书中的“签名算法：sha1WithRSAEncryption”，例如：
Signature Algorithm: sha1WithRSAEncryption 5b:47:09:64:41:d8:11:49:73:a3:ac:47:b2:07:5b:1b:75:a9: 19:09:62:94:c6:46:fa:fa:84:b1:22:c6:f8:0b:b9:20:5a:5e: 0b:51:df:e2:7a:ea:6f:4a:82:e4:57:f0:c9:69:25:ef:f9:92: 17:91:f2:53:d4:08:a0:b6:2f:4b:58:bd:4b:3b:1f:1e:6f:00: fc:e8:35:26:04:b7:03:bc:fa:8d:da:cb:ad:15:d2:7f:7a:d8: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx: 51:45:7c:08:cb:45:d5:b9:99:45:c5:14:c8:07:07:2c:c4:9a: de:d2:a3:6e:bd:c8:ec:dc:c3:df:4f:0f:31:02:66:f3:45:e1: 92:29:9e:0f:82:65:cf:62:c8:99:ae:73:da:d9:d0:0a:66:f3: 4e:7c:60:d9:02:86:d2:1b:8f:de:1d:0b:c0:ef:10:2b:47:58: 22:73:2d:19:66:ed:e0:e8:e2:76:32:4a:f1:af:a1:ab:63:ae: c9:7b:94:4f:54:7f:65:b8:ad:82:6b:57:d7:e9:38:2b:78:d7: ac:3f:18:92:7d:42:72:e2:7f:11:f8:67:ab:da:29:ca:8c:ec: c3:f8:94:00:a3:1a:4a:00:6b:e6:82:90:ee:7f:0d:50:a3:c3: 0b:ca:34:28
对比
Signature Algorithm: sha1WithRSAEncryption
45:4e:91:32:44:be:1a:31:62:96:5a:42:61:94:13:6f:3a:ca:
44:1b:0c:6a:a2:10:3b:61:44:58:b2:34:b4:41:0d:2a:0c:26:
ae:bc:e7:b2:9a:1e:c9:8a:25:5e:f2:55:19:22:06:44:4b:67:
83:39:b8:80:2d:b1:9f:06:b7:a7:ec:4c:08:3d:11:ec:c7:32:
03:49:70:05:7c:4b:4c:05:30:4d:06:a4:f1:0d:cf:f3:a6:37:
4d:d9:31:af:e1:f8:e6:b7:d7:62:7b:06:e0:82:dd:72:2c:1e:
92:f8:cd:03:f4:c0:67:cb:0b:ba:af:a6:1c:0b:ff:f2:44:07:
83:db:ac:5e:8d:94:fb:51:5c:a7:c3:89:9c:fb:69:c6:4f:49:
b7:07:2d:c2:07:9f:46:b2:9a:2c:51:c5:50:c4:57:bf:b1:c7:
e0:4b:02:d5:cb:f0:4c:14:a2:cf:73:fc:43:d2:4b:3e:19:0c:
25:d0:38:7e:98:f5:db:e6:15:12:bc:d0:3f:9d:93:10:9f:c3:
be:29:bd:54:7f:97:ed:80:16:c7:28:1e:39:13:90:a1:15:fd:
df:7b:d8:27:52:13:d4:6f:16:90:97:b6:dc:c0:a7:5a:6f:3e:
e0:20:88:58:d4:e5:cf:49:bb:1c:00:3a:38:fb:fc:ab:f3:23:
fd:89:45:73:9a:65:e9:72:a5:f2:f4:6e:08:a7:06:3e:2d:83:
1b:4d:9b:b9:9e:ef:a0:53:7a:3c:de:fb:b3:ee:6c:ab:46:d9:
42:f4:ee:0c:0a:88:59:7f:c4:31:33:53:57:a1:26:92:8b:f6:
fd:95:82:d5:2a:7d:b8:72:fb:52:a3:35:6d:60:9d:2c:99:41:
29:6d:9f:48:91:1c:c1:78:1f:0f:6f:17:c9:42:51:3d:00:cd:
f3:9c:69:9a:33:5d:0f:ca:3a:ee:d5:02:ca:e4:4d:d2:35:fc:
83:c9:f0:46:b2:a5:14:f8:56:59:c6:43:30:b7:33:40:2c:a3:
7e:07:76:d8:55:8d:35:ca:87:db:57:dd:30:25:90:68:84:89:
ac:d8:61:a4:58:a5:08:56:64:95:5e:3c:6b:ac:2f:15:8e:02:
f2:4d:e8:6b:e1:b3:af:4e:b0:30:97:c5:d1:00:8c:59:6b:f2:
c6:9e:cb:3b:ed:a8:c3:af:8d:4f:75:d8:f3:65:5b:38:1e:18:
6b:03:ce:31:e3:8a:8a:02:84:3e:c0:e8:bb:ee:b5:4a:9c:f4:
51:f6:be:ac:b1:ea:0f:fc:0e:7d:98:78:8f:b5:8e:24:14:32:
64:52:bf:6a:94:59:70:e0:75:c8:17:7b:0e:00:5a:3b:a3:63:
ff:ab:1a:0c:e1:43:e5:03
需要明确的是，我不知道“签名算法”中的长度差异是否存在，但这是我目前可以辨别的唯一差异，所以我想知道我怎么能制作与良好证书长度相似的证书？怎么控制的？
对不起，如果这是一个奇怪的问题，但我已经研究了很长一段时间，并且有点“抓住稻草”:(...
【问题讨论】：
-
我认为我已经确定如何使“签名算法”与“好”证书的大小相同：看起来我已经创建了根 CA 密钥具有 4096 位，如果我创建一个具有 2048 位的新 CA 密钥，然后从该 CA 颁发证书，那么“签名算法”就是 256 个字节。不幸的是，从那个新 CA 颁发了一个证书，并在 OAM 服务器和 webgate 中重新部署了新证书，并且得到了完全相同的“decrypt_error”，所以我再次对为什么我的证书感到困惑发行不适用于此 OAM 配置？
-
Stack Overflow 是一个编程和开发问题的网站。这个问题似乎离题了，因为它与编程或开发无关。请参阅帮助中心的What topics can I ask about here。也许Super User 或Unix & Linux Stack Exchange 会是一个更好的提问地方。另见Where do I post questions about Dev Ops?。
-
签名算法肯定不是问题。可能是将证书或 CA 导入密钥库的问题。我建议使用 GUI 工具 portecle 检查 JKS 的内容。还要确保证书由您的 CA 正确签名
-
pedrofb：谢谢... [oracle@oam ca2]$ openssl verify -verbose -CAfile rootCA.crt foo13.crt foo13.crt：好的，所以我认为 CA 证书的证书链可以。仅供参考，在服务器端，证书 + 密钥进入名为 .oamkeystore 的 JCEKS 存储，我使用 Oracle 提供的名为 importcert.jar 的 Java 应用程序将证书和关联密钥都导入 .oamkeystore。当我之后列出 .oamkeystore（使用 storetype JCEKS）时，密钥对条目看起来没问题。另外顺便说一句，这与我导入从办公室获得的“良好”证书+密钥的方式相同，之前 DID 测试正常。
标签： ssl ssl-certificate pki