java - 删除 SHA1 证书 : Received fatal alert: bad_certificate. 服务器日志后出现 SSLHandshakeException:SEC_ERROR_REUSED_ISSUER_AND_SERIAL

Question

我们的 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 和根 SHA256，但是现在当所有 SHA1 证书都被删除，它只能找到具有相同序列号的 SHA256，所以这可能是原因，但我错了。

因为现在我们有另一个用户使用此链如他的证书的公开部分所示:

ancert root cert (sha256)
        |
        - ancert sub-root cert (sha256) 
                    |
                    - user cert (sha256)

如果我的理论成立，这个用户不会提示，因为服务器端始终存在 SHA256 证书，但现在他也提示了。

那么是什么原因呢？

Answer 1

我找到了答案:原来在IE truststore中删除与服务器端SHA256序列号相同的SHA1根CA证书后，一切又开始起作用了。中间CA证书序列号不重复。

我相信我之前的猜测部分成立:在进行身份验证时，在构建用户证书链时，并没有像用户证书指示的那样尝试构建链，Java 似乎会查找中间证书和根证书证书 来自 Windows 系统证书存储，即我们可以在 certmgr 中看到的证书，在“受信任的中间/根 CA”部分。不幸的是，在安装用户证书时，安装程​​序会将 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 代码不会出现这种错误/重复，而此时 Java 更容易受到攻击。

这个问题的修正:

我猜序列号的重复是由于注意，迫使用户更新证书，而没有意识到可能造成混淆的结果；

而且，服务器管理员应该提前通知我们这个变化；我们在用户报告一周后得到了这些信息。

最后，它再次证明了主动响应式编程之间长期存在的争论。我认为 Java 更喜欢前者，因为我遇到了另一个与一个证书存储中不同证书的重复别名相关的问题，在那里我看到了 Java 读取证书的方式(通过遍历所有别名并选择它看到的第一个，这类似于此处)强烈建议 Java 人员认为证书存储中不应有重复的别名。这是一个已知错误，描述为 here .但是，我认为这完全取决于您的目标是什么人，是经验丰富的网络管理员还是普通用户。