如何使用相互身份验证解决TLSv1握手问题?

前端之家收集整理的这篇文章主要介绍了如何使用相互身份验证解决TLSv1握手问题?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我有一点时间让我的Web服务客户端与我的Web服务通信,这需要客户端证书.我正在使用JAX-WS 2.1,Web服务请求首先通过IIS,然后在身份验证后转发到JBoss.

我使用自签名证书作为客户端证书,它安装在Windows“服务器”的“受信任的根证书颁发机构”部分中.

如果我尝试使用Internet Explorer访问服务的WSDL,系统会提示我输入证书,然后选择我创建的证书,一切似乎都正常.这让我相信所有证书都是正确的,并且所有人都信任
对“人”.

下面我可以看到服务器包含对我的“happyFunBall”的引用作为它信任的权限,因为它包含在握手的CertificateRequest部分中:

  1. *** CertificateRequest
  2. Cert Types: RSA,DSS`
  3. Cert Authorities:
  4. ...

我几乎是这个东西的新手,所以我可能会遗漏一些非常基本的东西,我可能不会包含所有相关信息…无论如何,我使用keytool生成了我的客户端证书,它的类型为“PKCS12” .因此,当我启动客户端时,我定义了以下系统属性

  1. javax.net.ssl.keyStore="C:\placeWhereFunBallLives\funBall.p12"
  2. javax.net.ssl.keyStorePassword=

当我打电话给Web服务时,我从服务器收到403.在我看来,底层的TLS / SSL实现没有找到要发送的客户端证书,或者由于某种原因即使它确实试图找到它也没有发送它.

握手成功后我应该看到什么?在上面的块之后有这样的:

  1. *** Certificate chain
  2. ***
  3. *** ClientKeyExchange,RSA PreMasterSecret,TLSv1
  4. main,WRITE: TLSv1 Handshake,length = 157
  5. SESSION KEYGEN:
  6. PreMaster Secret:
  7. 0000: 03 01 37 1B 02 E4 DB 34 87 A4 4C D0 03 83 74 0B ..7....4..L...t.
  8. 0010: 8D 31 A0 B1 70 B8 31 F8 EB 72 AB 88 3B 69 B5 43 .1..p.1..r..;i.C
  9. 0020: 19 EA 24 BD 59 50 16 7D C0 99 DC A6 EC 4F EF 64 ..$.YP.......O.d
  10. CONNECTION KEYGEN:
  11. Client Nonce:
  12. 0000: 4B 56 1E E4 66 09 1D 6C EE 95 F1 47 3E 12 DA 22 KV..f..l...G>.."
  13. 0010: 63 8E 23 93 76 7D FB CB 27 7B 2E C5 8E DC 93 C2 c.#.v...'.......
  14. Server Nonce:
  15. 0000: 4B 56 1E E4 A7 70 0F 2F 1A 17 0D 8F 2D 79 7D AE KV...p./....-y..
  16. 0010: 70 0E C9 5C 16 A9 B5 25 B0 99 22 B3 F8 89 D8 EC p..\...%..".....
  17. Master Secret:
  18. 0000: C3 ED 84 D6 63 CD 6C 59 94 14 06 4B 37 EC EE C4 ....c.lY...K7...
  19. 0010: AE 99 97 1B 0E B9 61 25 AF DB C4 54 30 C5 4C 80 ......a%...T0.L.
  20. 0020: 47 74 47 E8 B0 B5 13 32 BA 93 62 33 B6 CA C4 A8 GtG....2..b3....
  21. Client MAC write Secret:
  22. 0000: 3C E8 3A 6A B2 74 F0 ED 6C FE DE 70 77 E8 EB 36 <.:j.t..l..pw..6
  23. Server MAC write Secret:
  24. 0000: BD 41 C5 EB 3B ED E9 E0 0C 61 28 C2 11 7A 75 1C .A..;....a(..zu.
  25. Client write key:
  26. 0000: 79 43 DD AD 44 B0 A0 61 1D EB 71 AB 4F 39 9D EF yC..D..a..q.O9..
  27. Server write key:
  28. 0000: C9 43 22 2A 48 50 FA 67 E0 01 1B 8A 48 0F C8 CF .C"*HP.g....H...
  29. ... no IV used for this cipher
  30. main,WRITE: TLSv1 Change Cipher Spec,length = 17
  31. *** Finished
  32. verify_data: { 52,94,173,217,26,70,12,243,6,71,27,163 }
  33. ***
  34. main,length = 32
  35. main,READ: TLSv1 Change Cipher Spec,length = 17
  36. main,READ: TLSv1 Handshake,length = 32
  37. *** Finished
  38. verify_data: { 56,254,211,144,48,35,4,235,65,127,237,94 }
  39. ***
  40. %% Cached client session: [Session-2,SSL_RSA_WITH_RC4_128_MD5]

Heeeeeeelp!

最佳答案
好的,所以我发现问题是什么(或至少是问题的症状),并认为我会在这里分享它的历史类型.

我因此使用keytool来生成我的客户端密钥库:

  1. keytool -genkeypair -alias funBall -keyalg rsa -dname "CN=happyFunBall,O=thing.thing.com,C=US" -keystore

然后我用这个keytool命令签名:

  1. keytool -selfcert -alias funBall -validity 1825 -keystore

显然,这并不好.上面的“-selfcert”命令需要将“-dname”参数设置为与“-genkeypair”中使用的值相同的值,因为否则证书链或其他(我不完全理解)不正确并且证书不会被识别为服务器在其CertificateRequest中给出的列表的有效证书.

猜你在找的Java相关文章