成功进行SSL握手后会导致禁止403的原因是什么?

时间:2017-09-24 10:31:44

标签: ssl https

我对我在Java应用程序中向外部方进行的TLS连接有疑问。

TLS握手似乎没有任何问题。 (见下面的日志)。 但是我仍然从我试图访问的网络服务器上获得403禁用。

因为SSL握手已经完成,这意味着我可以排除证书作为问题吗?即是否更像是阻挡我的防火墙?

也可以有人想到我能做的其他任何事情,以获得有关为什么会出现问题的更多信息吗?我问这个问题,因为此刻我觉得我已经筋疲力尽了所有的调查途径。

感谢

[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Handshake, length = 2704
*** ServerHello, TLSv1
RandomCookie:  GMT: 1489311495 bytes = { 24, 166, 5, 115, 96, 245, 87, 168, 201, 0, 140, 169, 246, 167, 17, 130, 35, 82, 180, 20, 78, 118, 197, 139, 115, 85, 149, 249 }
Session ID:  {240, 31, 0, 0, 187, 150, 112, 197, 105, 66, 166, 30, 38, 101, 157, 77, 70, 251, 210, 109, 66, 5, 150, 39, 144, 252, 165, 154, 98, 139, 28, 247}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 24:d2:f9:be:4f:9b:34:9d:97:0a:87:7e:b3:00:a5:3b:9e:fd:13:83:1b:7c:57:f5
***
%% Initialized:  [Session-5, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=myComppany.dns.com.au
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
  Key:  Sun RSA public key, 2048 bits
  modulus: 20347157146520353095861639278208184247286986690713431491420841394784858170529375449223849853534354840929149706378303297947541892423057001636130580267149963843615721783983566141638311949114700827164868954418508313798333746643037746007234047993830271943749361746071066892915327273997666547176023092823087128341412638685856170738104070682226405621117015097115212087323270530842662099589771387988512876505892653094995664532977115190036204521785829075338794419227119436542735750611752914553559131212700916410969902308936242124816342527509957358809361641507658744635443218654637212447896897323865396709669621261450063512703
  public exponent: 65537
  Validity: [From: Tue May 16 10:07:21 AEST 2017,
               To: Thu May 16 10:07:20 AEST 2019]
  Issuer: CN=EDS_RootCA
  SerialNumber: [    3f6b1b9d 4e6a8491 479d4580 318d46b6]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.1 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 4F 30 4D 80 10 1F 88   3D 3B E3 7C 8A 45 C0 4C  .O0M....=;...E.L
0010: 36 EF 64 C8 23 A5 A1 27   30 25 31 23 30 21 06 03  6.d.#..'0%1#0!..
0020: 55 04 03 1E 1A 00 45 00   44 00 53 00 5F 00 56 00  U.....E.D.S._.
0030: 52 00 5F 00 52 00 6F 00   6F 00 74 00 43 00 41 82  ._.R.o.o.t.C.A.
0040: 10 1F E5 AA 89 7F E6 11   82 4D FE D1 DB FA F4 7E  .........M......
0050: 8D                                                 .
]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 26 94 B7 78 21 EC 60 24   28 6E 7D C0 93 43 7A F8  &..x!.`$(n...Cz.
0010: 27 E8 BF 36 E1 B9 6E 41   4F 3B B7 7D 48 FB F4 77  '..6..nAO;..H..w
0020: 56 30 85 5E C1 5E 73 1A   79 7A B8 7F 48 DE 85 2F  V0.^.^s.yz..H../
0030: 03 93 8F 78 15 28 65 4D   78 E1 DE 83 83 10 B0 97  ...x.(eMx.......
0040: 0C F2 8E D3 E7 E3 16 8E   1C C8 0D 6D 04 B9 64 81  ...........m..d.
0050: 59 B1 34 D7 2E 86 1C E0   CD D7 19 8E 7C 00 CA CD  Y.4.............
0060: A5 3D 37 F0 31 24 E6 DC   01 66 9C D2 6A 25 FE 0A  .=7.1$...f..j%..
0070: F9 02 B7 41 17 38 BA 74   05 34 EC 5D 3D DB 20 CB  ...A.8.t.4.]=. .
]
***
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE>
<CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US>
<CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US>
<CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE>
<CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE>
<CN=GeoTrust Global CA, O=GeoTrust Inc., C=US>
<CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=SercoTcsRootCA>
<CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.>
<CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US>
<CN=Tenix IMES CA>
<CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com>
<CN=SercoTcsRootCA, DC=, DC=ap, DC=ser, DC=com>
<CN=EDS__RootCA>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Handshake, length = 304
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 B3 1D 9D 31 6C 7D   0D D7 92 73 03 F0 6D 84  .....1l....s..m.
0010: 4D 6C BB 52 D7 26 C1 B0   58 82 90 23 29 DB AC 1C  Ml.R.&..X..#)...
0020: DA 19 E1 6C A0 63 31 22   0D 39 05 FD 92 A6 43 A6  ...l.c1".9....C.
CONNECTION KEYGEN:
Client Nonce:
0000: 59 C5 17 07 63 E9 79 F6   63 5A 7A 43 66 8D 1C B2  Y...c.y.cZzCf...
0010: 60 6C 4A CF E4 86 9A 81   A2 2B C6 F0 5E 76 6A 93  `lJ......+..^vj.
Server Nonce:
0000: 59 C5 17 07 18 A6 05 73   60 F5 57 A8 C9 00 8C A9  Y......s`.W.....
0010: F6 A7 11 82 23 52 B4 14   4E 76 C5 8B 73 55 95 F9  ....#R..Nv..sU..
Master Secret:
0000: 74 FC 19 66 31 63 EB 6D   77 D0 90 35 89 AF 5E 2D  t..f1c.mw..5..^-
0010: 92 07 CD 77 18 D4 8A B0   A4 ED D6 87 79 EC BA DC  ...w........y...
0020: B5 85 EF BF 6E 44 60 08   93 10 18 89 42 37 58 45  ....nD`.....B7XE
Client MAC write Secret:
0000: C1 EA 83 8C DB D9 FC 4D   BA B3 F0 CA 63 98 5F 3E  .......M....c._>
0010: 5B E0 87 F0                                        [...
Server MAC write Secret:
0000: 8C 01 99 66 54 26 87 2A   16 96 6F 6B 96 8A F3 6B  ...fT&.*..ok...k
0010: 84 8C 9E D9                                        ....
Client write key:
0000: 96 E6 14 E2 F6 85 B8 93   51 90 2C CA 86 05 0F FE  ........Q.,.....
Server write key:
0000: 96 4C 43 E0 3A FB 05 72   3B 91 6B DB D8 1D 41 67  .LC.:..r;.k...Ag
Client write IV:
0000: BB AA 2B 91 63 10 62 EA   B6 8E 2D 48 DD 8A 6C EE  ..+.c.b...-H..l.
Server write IV:
0000: 25 30 3F 0A 96 D4 D9 1B   F2 B1 92 29 62 CD 0D 4D  %0?........)b..M
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Change Cipher Spec, length = 32
*** Finished
verify_data:  { 232, 153, 163, 243, 22, 33, 213, 172, 119, 46, 247, 107 }
***
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Handshake, length = 48
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Change Cipher Spec, length = 32
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Handshake, length = 48
*** Finished
verify_data:  { 232, 126, 65, 13, 112, 166, 63, 121, 201, 0, 57, 110 }
***
%% Cached client session: [Session-5, TLS_RSA_WITH_AES_128_CBC_SHA]
WARN  2017-09-22 23:58:32,052 [[api-blah-v1-132].apiHttpListenerConfig.worker.02] org.apache.cxf.phase.PhaseInterceptorChain: Interceptor for {http://support.cxf.module.mule.org/}ProxyService#{http://support.cxf.module.mule.org/}invoke has thrown exception, unwinding now\norg.apache.cxf.interceptor.Fault: Response code 403 mapped as failure.\n

2 个答案:

答案 0 :(得分:1)

  

因为SSL握手已经完成,这意味着我可以排除证书问题吗?

  

即。是否更像是防火墙挡住了我的另一面?

没有

Web服务器拒绝您访问所请求资源的权限。没有理由单独成功进行TLS握手就可以允许您进行访问。 Web服务器可以访问哪些内容。

答案 1 :(得分:0)

所以我更多地看了这个。我发现你必须非常小心地阅读所发布的输出。

虽然握手报告成功,但握手中有一条消息如下。这基本上意味着虽然第一个数据包可能已被发送,但握手失败了。

警告:找不到合适的证书 - 没有客户端身份验证继续

我的密钥库存在问题,那就是它没有发行者的证书。