使用 -Djavax.net.debug=all 调试 Java SSL 握手 [英] Debug Java SSL Handshake using -Djavax.net.debug=all
问题描述
我的 Node.js 客户端正在使用 SSL 连接到 Java 服务器.它似乎一直工作到 CertificateVerify 然后我得到一个缓存会话，我的客户端打印 SSL 无法授权.
My Node.js client is connecting to a Java server with SSL. It seems to work up until the CertificateVerify where then I get a cache session, and my client prints SSL Couldn't Authorize.
这是使用 -Djavax.net.debug=all 从 ssl 握手记录的 Java 服务器调试语句的片段.问题是，Java 没有明确提出任何危险信号，例如无法验证签名.这是它停止的日志尾部.注意:我在日志末尾的缓存服务器会话之后添加了一个省略号.
Here is a snippet of the Java server debug statements logged from the ssl handshake using -Djavax.net.debug=all. The problem is, Java does not explicitly raise any red flags like couldn't verify signature. This is the tail of the log where it stops. Note: I added an ellipses after the Cache Server Session at the end of the log.
谁能帮我破译这个日志输出以确定 ssl 握手失败的原因?我猜它最终无法验证证书的签名，但我没有看到明确说明这一点.
Can anyone help me decipher this log output to determine why the ssl handshake is failing? I'm guessing that ultimately it can't verify the signature of the certificate, but I do not see this being explicitly stated.
pool-1-thread-2, READ: TLSv1.2 Handshake, length = 264
*** CertificateVerify
Signature Algorithm SHA512withRSA
[read] MD5 and SHA1 hashes: len = 264
0000: 0F 00 01 04 06 01 01 00 1E F6 13 87 8C 77 81 2D .............w.-
0010: E3 33 EB E0 8F 80 49 C6 90 F9 B5 4C 9B A0 69 77 .3....I....L..iw
0020: B1 14 6C E3 B2 15 15 1F 26 D5 69 31 64 36 0D D1 ..l.....&.i1d6..
0030: DA AD BA 58 BF 76 6D 25 1D 49 BA 4A C6 80 1C 49 ...X.vm%.I.J...I
0040: DC 5B D8 F0 FC B3 34 86 93 71 0D 3D 92 DB AB 0E .[....4..q.=....
0050: 6A 34 62 FC F5 09 61 65 68 12 64 BB 6F 6E 39 96 j4b...aeh.d.on9.
0060: BC C6 40 D4 A1 63 4D 0E 68 61 02 8E 14 4B DF 6D ..@..cM.ha...K.m
0070: B1 C2 D6 D5 E6 09 19 E9 31 A6 20 07 44 BB AD 43 ........1. .D..C
0080: D4 3C 91 9C 56 FC A8 70 8B 5C 8D 87 F2 61 30 CA .<..V..p.\...a0.
0090: 6B 82 88 FA 3D B3 27 84 12 FE EF 2B 51 3A DD 5B k...=.'....+Q:.[
00A0: 0E 03 D6 44 E9 B8 04 EF 62 4B 7A 51 7E 6D 85 79 ...D....bKzQ.m.y
00B0: 1A 78 C8 5E 21 C8 E8 CA 2A 7D 2F 5E 6C 90 1B 00 .x.^!...*./^l...
00C0: B5 97 5F 8D FC D5 C3 D8 ED 2D 05 B6 DA 51 16 B7 .._......-...Q..
00D0: 39 14 44 46 DE 80 DD 98 31 F8 B5 DD E8 89 8C 64 9.DF....1......d
00E0: 4E DF 3C 99 38 10 87 F4 D0 67 4E C3 AA FE 25 F3 N.<.8....gN...%.
00F0: 7E F1 48 60 52 09 2C 2B C4 32 A4 58 92 3E 15 4A ..H`R.,+.2.X.>.J
0100: DA 11 CB 19 45 16 5D 79 ....E.]y
[Raw read]: length = 5
0000: 14 03 03 00 01 .....
[Raw read]: length = 1
0000: 01 .
pool-1-thread-2, READ: TLSv1.2 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 03 00 50 ....P
[Raw read]: length = 80
0000: CE F7 6C D4 32 5C 12 6E 02 47 11 1E DA C8 7C 13 ..l.2\.n.G......
0010: F0 F5 92 42 82 3D 58 FF 70 A3 05 D9 1F D8 00 1E ...B.=X.p.......
0020: 88 77 06 11 78 B5 A7 AA 23 69 D5 54 E9 22 78 D6 .w..x...#i.T."x.
0030: 08 A8 B2 D8 AF CE 78 91 34 28 78 6B 50 8D 7E 32 ......x.4(xkP..2
0040: 1A 30 79 ED 31 51 FD 8D 79 59 5A 9D 99 27 B4 25 .0y.1Q..yYZ..'.%
pool-1-thread-2, READ: TLSv1.2 Handshake, length = 80
Padded plaintext after DECRYPTION: len = 80
0000: A8 92 6E 76 A7 44 8F 3F 0A 85 B0 7B 5F D9 21 CE ..nv.D.?...._.!.
0010: 14 00 00 0C 86 62 B5 EF 19 0C 5C C2 DF 60 35 5C .....b....\..`5\
0020: 84 2D 2D 20 C9 87 0A 37 33 44 5D E9 95 2D 3B B9 .-- ...73D]..-;.
0030: E3 50 F1 31 1C 54 F9 41 FB 4E C4 B6 81 C5 DF 78 .P.1.T.A.N.....x
0040: 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F ................
*** Finished
verify_data: { 134, 98, 181, 239, 25, 12, 92, 194, 223, 96, 53, 92 }
***
[read] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 86 62 B5 EF 19 0C 5C C2 DF 60 35 5C .....b....\..`5\
pool-1-thread-2, WRITE: TLSv1.2 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 03 00 01 01 ......
*** Finished
verify_data: { 166, 60, 137, 232, 242, 208, 180, 127, 89, 133, 80, 93 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C A6 3C 89 E8 F2 D0 B4 7F 59 85 50 5D .....<......Y.P]
Padded plaintext before ENCRYPTION: len = 80
0000: 9C F6 B8 F4 10 05 57 5C DE 38 27 7A 82 F5 04 88 ......W\.8'z....
0010: 14 00 00 0C A6 3C 89 E8 F2 D0 B4 7F 59 85 50 5D .....<......Y.P]
0020: 73 1C 58 7B 9D FD 88 E4 40 1A 04 AB A3 B3 57 38 s.X.....@.....W8
0030: 7B 22 19 CB F0 24 AE 16 69 63 04 F9 9E 20 7D 00 ."...$..ic... ..
0040: 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F ................
pool-1-thread-2, WRITE: TLSv1.2 Handshake, length = 80
[Raw write]: length = 85
0000: 16 03 03 00 50 AB AE B3 92 D6 B2 9B D4 3F 51 A7 ....P........?Q.
0010: F6 FF B8 11 FF 81 26 33 2F 70 64 71 FF 33 F3 DA ......&3/pdq.3..
0020: EB B8 9E 5E 66 69 49 20 05 0F 1A A2 C1 C6 81 EC ...^fiI ........
0030: 07 23 7E C8 26 11 49 8F 02 1F 53 8F 49 26 30 13 .#..&.I...S.I&0.
0040: DA 10 33 9F 0A 94 B5 39 86 C8 5F D9 8A 22 49 68 ..3....9.._.."Ih
0050: C1 31 0A 7D CE .1...
%% Cached server session: ...
更多有用的信息.我检查了证书的有效期.它将于 2044 年 11 月到期，因此我确信握手不会因为证书过期而失败.
More helpful information. I've checked the expiration of the certificate. It expires November 2044, so I'm assured that the hand shake isn't failing due to an expired certificate.
推荐答案
感谢 EJP 的评论，我决定深入研究客户端错误消息.我添加了一个调试语句来打印客户端得到的错误，如下所示:
Thanks to the comment of the EJP, I decided to dig into the client error message. I added a debug statement that printed the error the client was getting, which was the following:
Hostname/IP doesn't match certificate's altnames
我在客户端检查了这个字符串，但我升级到节点 v0.12，看起来他们在该语句中添加了一些额外的输出.当前的逻辑是忽略此错误，并继续加密会话.
I have a check in the client for this string, but I upgraded to node v0.12 and it appears they added some extra output in that statement. The logic currently is to just ignore this error, and continue with the encrypted session.
感谢您的帮助.
这篇关于使用 -Djavax.net.debug=all 调试 Java SSL 握手的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
