删除 SHA1 证书后出现 SSLHandshakeException：收到致命警报：bad_certificate。服务器日志：SEC_ERROR_REUSED_ISSUER_AND_SERIAL
SSLHandshakeException after deleting SHA1 cert: Received fatal alert: bad_certificate. Server log: SEC_ERROR_REUSED_ISSUER_AND_SERIAL
我们的 Java Swing + Visual Basic APP 允许用户通过 SSL 连接对服务器进行身份验证。现在在同一个实体客户端共享一张智能卡的两个用户突然遇到一个问题：使用Java部分无法连接到服务器，但是使用VB模块是正常的。
在服务器端，我们以前同时拥有 ancert SHA1 和 SHA256 根。 当服务器管理员删除 ANCERT SHA1 根和子根证书时，我们开始遇到 "bad_certificate" 的问题。
添加 -Djavax.net.debug=all 后，在生成的日志的最后，我们看到错误发生在 CertificateVerify 和 Client Finish 之后：
...
*** CertificateVerify
[write] MD5 and SHA1 hashes: len = 262
0000: 0F 00 01 02 01 00 0C F5 8A 0A 9C 38 E9 6B E4 B6 ...........8.k..
0010: AC 2D 35 26 61 E3 56 72 66 DE B9 E0 AE CD B2 7B .-5&a.Vrf.......
0020: 41 AF EB 66 9B 48 05 11 94 75 0D 0F 01 4B CA E6 A..f.H...u...K..
0030: 64 60 B7 5D 85 5D 61 1B EA 7F 38 F1 5D D4 91 AE d`.].]a...8.]...
0040: 04 84 19 3A 76 75 1E 87 4D C7 42 AB 16 9E 07 AD ...:vu..M.B.....
0050: 7D 60 9A A2 A8 94 B9 2F 08 79 40 AA 96 14 2E F4 .`...../.y@.....
0060: 88 CA 72 00 46 8F EF D5 A2 6D 6B 7C B9 99 44 52 ..r.F....mk...DR
0070: FB CA F8 F8 00 D1 95 5E 15 B9 AD C6 1B 51 71 FB .......^.....Qq.
0080: 6E 34 17 EC 0D D0 1B 8E 49 D7 DF F0 96 82 E6 27 n4......I......'
0090: F7 1B 2B 39 42 D5 CE 92 30 27 E5 07 7D 6C 87 6F ..+9B...0'...l.o
00A0: CE CD 81 DD 8A 04 D6 F2 EE 36 D4 2D FC 3B 00 58 .........6.-.;.X
00B0: 93 D5 85 D9 EB C4 DC 30 FC 91 E5 CB 44 8B 6A A2 .......0....D.j.
00C0: 38 96 DD 21 B0 C5 C3 27 34 FC 55 97 00 26 5F 17 8..!...'4.U..&_.
00D0: F3 53 05 45 23 81 00 C2 36 FC C1 0B B7 45 8B 87 .S.E#...6....E..
00E0: 61 F1 21 65 AA F6 34 B4 15 85 AF A5 B2 21 C3 65 a.!e..4......!.e
00F0: 7E 9D B1 F3 F8 13 8D 58 14 1A F1 CE 9A 7F 53 6C .......X......Sl
0100: 6F 96 A3 77 8F 9F o..w..
Thread-7, WRITE: TLSv1.1 Handshake, length = 262
[Raw write]: length = 267
0000: 16 03 02 01 06 0F 00 01 02 01 00 0C F5 8A 0A 9C ................
0010: 38 E9 6B E4 B6 AC 2D 35 26 61 E3 56 72 66 DE B9 8.k...-5&a.Vrf..
0020: E0 AE CD B2 7B 41 AF EB 66 9B 48 05 11 94 75 0D .....A..f.H...u.
0030: 0F 01 4B CA E6 64 60 B7 5D 85 5D 61 1B EA 7F 38 ..K..d`.].]a...8
0040: F1 5D D4 91 AE 04 84 19 3A 76 75 1E 87 4D C7 42 .]......:vu..M.B
0050: AB 16 9E 07 AD 7D 60 9A A2 A8 94 B9 2F 08 79 40 ......`...../.y@
0060: AA 96 14 2E F4 88 CA 72 00 46 8F EF D5 A2 6D 6B .......r.F....mk
0070: 7C B9 99 44 52 FB CA F8 F8 00 D1 95 5E 15 B9 AD ...DR.......^...
0080: C6 1B 51 71 FB 6E 34 17 EC 0D D0 1B 8E 49 D7 DF ..Qq.n4......I..
0090: F0 96 82 E6 27 F7 1B 2B 39 42 D5 CE 92 30 27 E5 ....'..+9B...0'.
00A0: 07 7D 6C 87 6F CE CD 81 DD 8A 04 D6 F2 EE 36 D4 ..l.o.........6.
00B0: 2D FC 3B 00 58 93 D5 85 D9 EB C4 DC 30 FC 91 E5 -.;.X.......0...
00C0: CB 44 8B 6A A2 38 96 DD 21 B0 C5 C3 27 34 FC 55 .D.j.8..!...'4.U
00D0: 97 00 26 5F 17 F3 53 05 45 23 81 00 C2 36 FC C1 ..&_..S.E#...6..
00E0: 0B B7 45 8B 87 61 F1 21 65 AA F6 34 B4 15 85 AF ..E..a.!e..4....
00F0: A5 B2 21 C3 65 7E 9D B1 F3 F8 13 8D 58 14 1A F1 ..!.e.......X...
0100: CE 9A 7F 53 6C 6F 96 A3 77 8F 9F ...Slo..w..
Thread-7, WRITE: TLSv1.1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 02 00 01 01 ......
*** Finished
verify_data: { 54, 35, 53, 118, 12, 242, 190, 4, 226, 234, 192, 46 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 36 23 35 76 0C F2 BE 04 E2 EA C0 2E ....6#5v........
Padded plaintext before ENCRYPTION: len = 64
0000: A9 E5 26 50 4D 1D BE 8B 92 2E 77 12 24 0E DB C5 ..&PM.....w.$...
0010: 14 00 00 0C 36 23 35 76 0C F2 BE 04 E2 EA C0 2E ....6#5v........
0020: A5 44 16 F6 70 AC 7F 9A 40 CD 5B 4C B9 CD 88 7D .D..p...@.[L....
0030: 42 78 85 30 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B Bx.0............
Thread-7, WRITE: TLSv1.1 Handshake, length = 64
[Raw write]: length = 69
0000: 16 03 02 00 40 0C A2 DA FC 1A 9E CE B0 D6 2F 7B ....@........./.
0010: 23 9E A9 00 D3 3B FC 2A C7 DD 5D 22 A6 36 B3 E1 #....;.*..]".6..
0020: CE EB FD 48 C7 55 D3 5B AF FC 37 3E 49 86 9A 6F ...H.U.[..7>I..o
0030: 79 A5 FD 5B 60 06 F4 A9 89 CD F4 26 D9 FE F3 9B y..[`......&....
0040: 78 E0 65 2D 56 x.e-V
[Raw read]: length = 5
0000: 15 03 02 00 02 .....
[Raw read]: length = 2
0000: 02 2A .*
Thread-7, READ: TLSv1.1 Alert, length = 2
Thread-7, RECV TLSv1.1 ALERT: fatal, bad_certificate
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
Thread-7, called closeSocket()
Thread-7, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
在服务器端，当客户端连接时，出现这个错误：
[07/Jul/2017:13:33:18] failure (3354): HTTP3068: Error receiving request from 37.222.168.137 (SEC_ERROR_REUSED_ISSUER_AND_SERIAL: Attempting to import a cert which conflicts with issuer/serial of existing cert.)
我们不知道为什么它停止工作。
- VB 模块也连接到相同的服务器，相同的 URL 并且可以正常工作。我没有 VB 代码。所以我觉得卡还是不错的。
- 应用程序中的信任存储文件已包含发行者
ANCERT Certificados para empleados V2（子根）以及根 ANCERT CGN V2（根）。
为什么会这样？
编辑：
在本地信任库中，我们有这些证书：
ancert root cert (sha1)
|
- ancert sub-root cert (sha1)
以及问题之前链是如何构建的：
ancert root cert (sha1)
|
- ancert sub-root cert (sha1)
|
- user cert (sha256)
在服务器端，SHA1 根证书与 SHA256 根证书具有相同的序列号。
所以我认为这是因为在构建链时，Java查看用户证书中的链，并希望按照该链中的指示在服务器中找到一条链，因此它期望中间 SHA1 和root SHA256，但是现在当所有的SHA1证书都被删除时，它只能找到具有相同序列号的SHA256，所以这可能是原因，但我错了。
因为现在我们有另一个用户使用此链 ，如他的证书的 public 部分所示 :
ancert root cert (sha256)
|
- ancert sub-root cert (sha256)
|
- user cert (sha256)
如果我的理论成立，这个用户不会抱怨，因为服务器端始终存在 SHA256 证书，但现在他也抱怨了。
那么是什么原因呢？
我找到了答案：原来在IE truststore中删除与服务器端SHA256序列号相同的SHA1根CA证书后，一切又开始了。中间CA证书序列号不重复
我相信我之前的猜测部分成立：在验证时，在构建用户证书链时，而不是像用户证书指示的那样尝试构建链，Java 似乎从 Windows 系统证书库 中查找中间证书和根证书 ，即我们可以在 certmgr 部分看到的 [=40] =].而且，不幸的是，在安装用户证书时，安装程序会将 SHA1 和 SHA256 根证书添加到该存储中。
而且，Java似乎假设在这家店里一切都井井有条，不希望有任何重复，如序列号；它在看到 SHA256 根证书之前先看到 SHA1 证书。 因此，它用它构建链，并将其发送到服务器；但在服务器端它看到具有相同序列号的 SHA2，因此发生冲突。
至于VB方面，我猜是因为MS以另一种方式构建了证书链（并且考虑了另一种意识形态：假设找到的第一个链不一定是最好的，有时，它很容易失败），尝试构建所有可能的链，最后选择正确的链。根据this answer:
If we talk about Microsoft implementation (just an example which I'm familiar with), their CCE builds one or more chains (as much as possible) without performing immediate validation. They just fetch certificates and attempt to perform basic rules to bind each certificate at the correct place in the chain. When all chains are built, each of them are validated according to rules described in RFC5280. Once validated, there might be a case that there are multiple trusted and valid chains. CCE uses its own selection logic to select only one chain from a collection of chains.
因此，VB 代码对这种 error/repetition 免疫，而 Java 目前更容易受到攻击。
本题修正：
我猜序列号的重复是由于注意，迫使用户更新证书，而没有意识到可能因此造成的混淆；
而且，服务器管理员应该提前通知我们这个变化；我们在用户报告后一周得到了这些信息。
终于，它又一次证明了主动式编程与被动式编程之间长期存在的争论。我认为 Java 支持前者，因为我遇到了另一个与一个证书存储中不同证书的重复别名相关的问题，在那里我看到 Java 读取证书的方式（通过迭代所有别名和拿起它看到的第一个，这与此处相似）强烈建议 Java 伙计们认为证书存储 中不应有重复的别名。这是一个已知错误，描述为 here。但是，我认为这完全取决于您的目标是谁，是经验丰富的网络管理员还是普通用户。
我们的 Java Swing + Visual Basic APP 允许用户通过 SSL 连接对服务器进行身份验证。现在在同一个实体客户端共享一张智能卡的两个用户突然遇到一个问题：使用Java部分无法连接到服务器，但是使用VB模块是正常的。
在服务器端，我们以前同时拥有 ancert SHA1 和 SHA256 根。 当服务器管理员删除 ANCERT SHA1 根和子根证书时，我们开始遇到 "bad_certificate" 的问题。
添加 -Djavax.net.debug=all 后，在生成的日志的最后，我们看到错误发生在 CertificateVerify 和 Client Finish 之后：
...
*** CertificateVerify
[write] MD5 and SHA1 hashes: len = 262
0000: 0F 00 01 02 01 00 0C F5 8A 0A 9C 38 E9 6B E4 B6 ...........8.k..
0010: AC 2D 35 26 61 E3 56 72 66 DE B9 E0 AE CD B2 7B .-5&a.Vrf.......
0020: 41 AF EB 66 9B 48 05 11 94 75 0D 0F 01 4B CA E6 A..f.H...u...K..
0030: 64 60 B7 5D 85 5D 61 1B EA 7F 38 F1 5D D4 91 AE d`.].]a...8.]...
0040: 04 84 19 3A 76 75 1E 87 4D C7 42 AB 16 9E 07 AD ...:vu..M.B.....
0050: 7D 60 9A A2 A8 94 B9 2F 08 79 40 AA 96 14 2E F4 .`...../.y@.....
0060: 88 CA 72 00 46 8F EF D5 A2 6D 6B 7C B9 99 44 52 ..r.F....mk...DR
0070: FB CA F8 F8 00 D1 95 5E 15 B9 AD C6 1B 51 71 FB .......^.....Qq.
0080: 6E 34 17 EC 0D D0 1B 8E 49 D7 DF F0 96 82 E6 27 n4......I......'
0090: F7 1B 2B 39 42 D5 CE 92 30 27 E5 07 7D 6C 87 6F ..+9B...0'...l.o
00A0: CE CD 81 DD 8A 04 D6 F2 EE 36 D4 2D FC 3B 00 58 .........6.-.;.X
00B0: 93 D5 85 D9 EB C4 DC 30 FC 91 E5 CB 44 8B 6A A2 .......0....D.j.
00C0: 38 96 DD 21 B0 C5 C3 27 34 FC 55 97 00 26 5F 17 8..!...'4.U..&_.
00D0: F3 53 05 45 23 81 00 C2 36 FC C1 0B B7 45 8B 87 .S.E#...6....E..
00E0: 61 F1 21 65 AA F6 34 B4 15 85 AF A5 B2 21 C3 65 a.!e..4......!.e
00F0: 7E 9D B1 F3 F8 13 8D 58 14 1A F1 CE 9A 7F 53 6C .......X......Sl
0100: 6F 96 A3 77 8F 9F o..w..
Thread-7, WRITE: TLSv1.1 Handshake, length = 262
[Raw write]: length = 267
0000: 16 03 02 01 06 0F 00 01 02 01 00 0C F5 8A 0A 9C ................
0010: 38 E9 6B E4 B6 AC 2D 35 26 61 E3 56 72 66 DE B9 8.k...-5&a.Vrf..
0020: E0 AE CD B2 7B 41 AF EB 66 9B 48 05 11 94 75 0D .....A..f.H...u.
0030: 0F 01 4B CA E6 64 60 B7 5D 85 5D 61 1B EA 7F 38 ..K..d`.].]a...8
0040: F1 5D D4 91 AE 04 84 19 3A 76 75 1E 87 4D C7 42 .]......:vu..M.B
0050: AB 16 9E 07 AD 7D 60 9A A2 A8 94 B9 2F 08 79 40 ......`...../.y@
0060: AA 96 14 2E F4 88 CA 72 00 46 8F EF D5 A2 6D 6B .......r.F....mk
0070: 7C B9 99 44 52 FB CA F8 F8 00 D1 95 5E 15 B9 AD ...DR.......^...
0080: C6 1B 51 71 FB 6E 34 17 EC 0D D0 1B 8E 49 D7 DF ..Qq.n4......I..
0090: F0 96 82 E6 27 F7 1B 2B 39 42 D5 CE 92 30 27 E5 ....'..+9B...0'.
00A0: 07 7D 6C 87 6F CE CD 81 DD 8A 04 D6 F2 EE 36 D4 ..l.o.........6.
00B0: 2D FC 3B 00 58 93 D5 85 D9 EB C4 DC 30 FC 91 E5 -.;.X.......0...
00C0: CB 44 8B 6A A2 38 96 DD 21 B0 C5 C3 27 34 FC 55 .D.j.8..!...'4.U
00D0: 97 00 26 5F 17 F3 53 05 45 23 81 00 C2 36 FC C1 ..&_..S.E#...6..
00E0: 0B B7 45 8B 87 61 F1 21 65 AA F6 34 B4 15 85 AF ..E..a.!e..4....
00F0: A5 B2 21 C3 65 7E 9D B1 F3 F8 13 8D 58 14 1A F1 ..!.e.......X...
0100: CE 9A 7F 53 6C 6F 96 A3 77 8F 9F ...Slo..w..
Thread-7, WRITE: TLSv1.1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 02 00 01 01 ......
*** Finished
verify_data: { 54, 35, 53, 118, 12, 242, 190, 4, 226, 234, 192, 46 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 36 23 35 76 0C F2 BE 04 E2 EA C0 2E ....6#5v........
Padded plaintext before ENCRYPTION: len = 64
0000: A9 E5 26 50 4D 1D BE 8B 92 2E 77 12 24 0E DB C5 ..&PM.....w.$...
0010: 14 00 00 0C 36 23 35 76 0C F2 BE 04 E2 EA C0 2E ....6#5v........
0020: A5 44 16 F6 70 AC 7F 9A 40 CD 5B 4C B9 CD 88 7D .D..p...@.[L....
0030: 42 78 85 30 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B Bx.0............
Thread-7, WRITE: TLSv1.1 Handshake, length = 64
[Raw write]: length = 69
0000: 16 03 02 00 40 0C A2 DA FC 1A 9E CE B0 D6 2F 7B ....@........./.
0010: 23 9E A9 00 D3 3B FC 2A C7 DD 5D 22 A6 36 B3 E1 #....;.*..]".6..
0020: CE EB FD 48 C7 55 D3 5B AF FC 37 3E 49 86 9A 6F ...H.U.[..7>I..o
0030: 79 A5 FD 5B 60 06 F4 A9 89 CD F4 26 D9 FE F3 9B y..[`......&....
0040: 78 E0 65 2D 56 x.e-V
[Raw read]: length = 5
0000: 15 03 02 00 02 .....
[Raw read]: length = 2
0000: 02 2A .*
Thread-7, READ: TLSv1.1 Alert, length = 2
Thread-7, RECV TLSv1.1 ALERT: fatal, bad_certificate
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
Thread-7, called closeSocket()
Thread-7, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
在服务器端，当客户端连接时，出现这个错误：
[07/Jul/2017:13:33:18] failure (3354): HTTP3068: Error receiving request from 37.222.168.137 (SEC_ERROR_REUSED_ISSUER_AND_SERIAL: Attempting to import a cert which conflicts with issuer/serial of existing cert.)
我们不知道为什么它停止工作。
- VB 模块也连接到相同的服务器，相同的 URL 并且可以正常工作。我没有 VB 代码。所以我觉得卡还是不错的。
- 应用程序中的信任存储文件已包含发行者
ANCERT Certificados para empleados V2（子根）以及根ANCERT CGN V2（根）。
为什么会这样？
编辑：
在本地信任库中，我们有这些证书：
ancert root cert (sha1)
|
- ancert sub-root cert (sha1)
以及问题之前链是如何构建的：
ancert root cert (sha1)
|
- ancert sub-root cert (sha1)
|
- user cert (sha256)
在服务器端，SHA1 根证书与 SHA256 根证书具有相同的序列号。
所以我认为这是因为在构建链时，Java查看用户证书中的链，并希望按照该链中的指示在服务器中找到一条链，因此它期望中间 SHA1 和root SHA256，但是现在当所有的SHA1证书都被删除时，它只能找到具有相同序列号的SHA256，所以这可能是原因，但我错了。
因为现在我们有另一个用户使用此链 ，如他的证书的 public 部分所示 :
ancert root cert (sha256)
|
- ancert sub-root cert (sha256)
|
- user cert (sha256)
如果我的理论成立，这个用户不会抱怨，因为服务器端始终存在 SHA256 证书，但现在他也抱怨了。
那么是什么原因呢？
我找到了答案：原来在IE truststore中删除与服务器端SHA256序列号相同的SHA1根CA证书后，一切又开始了。中间CA证书序列号不重复
我相信我之前的猜测部分成立：在验证时，在构建用户证书链时，而不是像用户证书指示的那样尝试构建链，Java 似乎从 Windows 系统证书库 中查找中间证书和根证书 ，即我们可以在 certmgr 部分看到的 [=40] =].而且，不幸的是，在安装用户证书时，安装程序会将 SHA1 和 SHA256 根证书添加到该存储中。
而且，Java似乎假设在这家店里一切都井井有条，不希望有任何重复，如序列号；它在看到 SHA256 根证书之前先看到 SHA1 证书。 因此，它用它构建链，并将其发送到服务器；但在服务器端它看到具有相同序列号的 SHA2，因此发生冲突。
至于VB方面，我猜是因为MS以另一种方式构建了证书链（并且考虑了另一种意识形态：假设找到的第一个链不一定是最好的，有时，它很容易失败），尝试构建所有可能的链，最后选择正确的链。根据this answer:
If we talk about Microsoft implementation (just an example which I'm familiar with), their CCE builds one or more chains (as much as possible) without performing immediate validation. They just fetch certificates and attempt to perform basic rules to bind each certificate at the correct place in the chain. When all chains are built, each of them are validated according to rules described in RFC5280. Once validated, there might be a case that there are multiple trusted and valid chains. CCE uses its own selection logic to select only one chain from a collection of chains.
因此，VB 代码对这种 error/repetition 免疫，而 Java 目前更容易受到攻击。
本题修正：
我猜序列号的重复是由于注意，迫使用户更新证书，而没有意识到可能因此造成的混淆；
而且，服务器管理员应该提前通知我们这个变化；我们在用户报告后一周得到了这些信息。
终于，它又一次证明了主动式编程与被动式编程之间长期存在的争论。我认为 Java 支持前者，因为我遇到了另一个与一个证书存储中不同证书的重复别名相关的问题，在那里我看到 Java 读取证书的方式（通过迭代所有别名和拿起它看到的第一个，这与此处相似）强烈建议 Java 伙计们认为证书存储 中不应有重复的别名。这是一个已知错误，描述为 here。但是，我认为这完全取决于您的目标是谁，是经验丰富的网络管理员还是普通用户。