I have a question about an TLS connection I am making inside my Java application to an external party.
The TLS handshake seems to finish without any issues. (See log below).
But I still get a 403 forbidden from the web server I am trying to hit.
Because the SSL handshake has finished does it means I can rule out certificates as being the problem? i.e. Is it more likely to be like a firewall blocking me on the other side?
Also can anyone think of anything else I can do on my side to get more information about why things might be going wrong? I ask this question because at the moment I feel like I have exhausted all avenues of investigation.
thanks
[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
Because the SSL handshake has finished does it means I can rule out certificates as being the problem?
Yes.
i.e. Is it more likely to be like a firewall blocking me on the other side?
No.
It is the Web server denying you permission to access the requested resource. There is no reason why a successful TLS handshake alone should permit you that access. It is up to the Web server who can access what.
So I looked at this more. I discovered that you have to be very careful with reading the output posted.
Although the handshake reports as successful there is a message in the handshake as follows. This basically means that the handshake failed although the first packet may have been sent.
Warning: no suitable certificate found - continuing without client authentication
There was a problem with my keystore and that was that it did not have the certificate of the issuer in it.
Related
I am trying to connect to Azure IoT hub by using libmosquitto sdk using following code.
struct mosquitto *mosq_Connection_1;
bool mosq_ConnectionStatus_1;
void mqtt_init(void)
{
mosquitto_lib_init();
}
bool mqtt_ConnectToServer(struct mosquitto **mosq, char *mqtt_ip, int mqtt_port, char *mqtt_username, char *mqtt_password, int mqtt_keepAlive)
{
bool clean_session = true;
*mosq = mosquitto_new("123457", clean_session, NULL);
if(!(*mosq))
{
perror("mqtt error: Out of memory.\n");
return false;
}
printf("mqtt: mqtt_ip:%s\n",mqtt_ip);
printf("mqtt: mqtt_port:%d\n",mqtt_port);
printf("mqtt: mqtt_port:%s\n",mqtt_username);
printf("mqtt: mqtt Password:%s\n",mqtt_password);
mosquitto_log_callback_set(*mosq, my_log_callback);
mosquitto_connect_callback_set(*mosq, my_connect_callback);
mosquitto_message_callback_set(*mosq, my_message_callback);
mosquitto_subscribe_callback_set(*mosq, my_subscribe_callback);
mosquitto_disconnect_callback_set(*mosq,my_disconnect_callBack);
mosquitto_publish_callback_set(*mosq,my_publish_callBack);
// mosquitto_opts_set(*mosq, MOSQ_OPT_PROTOCOL_VERSION, "MQTT_PROTOCOL_V311");
if(mosquitto_tls_set(*mosq, "cert.cer", NULL, NULL, NULL, NULL)!= MOSQ_ERR_SUCCESS)
{
perror("mqtt: mosquitto_tls_set");
return false;
}
/* mosquitto_tls_insecure_set(*mosq, 1);
mosquitto_tls_opts_set(*mosq, 0, "tlsv1", NULL); */
if(1)//mqtt_username != NULL && mqtt_password != NULL)
{
mosquitto_username_pw_set(*mosq,mqtt_username,mqtt_password);
}
if(mosquitto_connect(*mosq, mqtt_ip, mqtt_port, mqtt_keepAlive))
{
perror("mqtt: Unable to connect.\n");
return false;
}
else
{
return true;
}
// mosquitto_loop_start(*mosq);
}
void mqtt_close(struct mosquitto *mosq)
{
printf("Closing mqtt Socket\n");
if(mosq == mosq_Connection_1)
mosq_ConnectionStatus_1 = false;
else if(mosq == mosq_Connection_2)
mosq_ConnectionStatus_2 = false;
else if(mosq == mosq_Connection_3)
mosq_ConnectionStatus_3 = false;
mosquitto_destroy(mosq);
mosquitto_lib_cleanup();
//mqtt_init();
}
int main()
{
bool clean_session = true;
mqtt_init();
mqtt_ConnectToServer(&mosq_Connection_1, <ip Address>, <Port Number>,<username>, <Password>, 60);
mosquitto_loop_start(mosq_Connection_1);
}
Now the problem is if i run this code on ubantu system then it is working fine and but i am trying to do the same on sierra wireless WP7608 board then it is not connecting to server. can somebody explain what is going wrong?
Thanks in advance.
Edited: I tried checking ssl certificate verification by using following command and it gives following logs.
Command: openssl s_client -connect UX101Test.azure-devices.net:8883 -state -debug -tls1_2
.....
09f0 - 86 c3 77 61 75 ee a1 86-ba 39 ab f2 f4 9d ad 0d ..wau....9......
0a00 - 35 7b 78 8f 94 b3 76 06-ce ad 6c 19 03 46 ef c6 5{x...v...l..F..
0a10 - 44 71 2e cd 15 35 28 70-5a 27 a5 40 7d 20 9a 26 Dq...5(pZ'.#} .&
0a20 - 89 72 6f 86 be 46 b3 fd-65 01 57 3a 67 21 81 fd .ro..F..e.W:g!..
0a30 - d5 4c ae 06 0d 00 00 1a-03 01 02 40 00 12 04 01 .L.........#....
0a40 - 05 01 02 01 04 03 05 03-02 03 02 02 06 01 06 03 ................
0a50 - 00 00 0e ...
0a56 - <SPACES/NULS>
SSL_connect:unknown state
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=9:certificate is not yet valid
notBefore=May 12 18:46:00 2000 GMT
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
write to 0xcd830 [0xdcdf8] (12 bytes => 12 (0xC))
0000 - 16 03 03 00 07 0b 00 00-03 .........
000c - <SPACES/NULS>
SSL_connect:unknown state
write to 0xcd830 [0xdcdf8] (107 bytes => 107 (0x6B))
0000 - 16 03 03 00 66 10 00 00-62 61 04 2a 95 39 c0 c2 ....f...ba.*.9..
0010 - 78 f4 8e ce c6 9e 90 7d-be f5 f4 45 b7 73 7d 59 x......}...E.s}Y
0020 - c7 c5 a2 cc 95 21 dc 09-d6 29 73 3e 67 fe ac d6 .....!...)s>g...
0030 - ba cf d5 79 c7 ea 98 05-1e 3a bf db 8a 2a 01 ec ...y.....:...*..
0040 - 57 d6 cf a1 94 23 97 11-e6 6b 77 ee 34 c0 87 8b W....#...kw.4...
0050 - 19 f1 fc de 52 f3 23 40-d7 9c 9f 71 f0 b7 a4 37 ....R.##...q...7
0060 - 86 a2 6a c8 2f e1 ac fa-32 5b 85 ..j./...2[.
SSL_connect:unknown state
write to 0xcd830 [0xdcdf8] (6 bytes => 6 (0x6))
0000 - 14 03 03 00 01 01 ......
SSL_connect:unknown state
write to 0xcd830 [0xdcdf8] (85 bytes => 85 (0x55))
0000 - 16 03 03 00 50 86 27 6f-bf ae 55 88 16 b2 00 eb ....P.'o..U.....
0010 - 93 8c e9 ec ce 27 12 e3-c9 ff d1 72 5e 35 4b 57 .....'.....r^5KW
0020 - 5c 38 f1 f8 ea ad 45 ea-ff 98 16 77 67 a3 92 0b \8....E....wg...
0030 - de 8e 27 f0 c7 45 b6 13-4e c4 49 e1 41 bf 8c ae ..'..E..N.I.A...
0040 - 4d ac 5a f6 70 58 9b 22-ec f0 e4 da 06 cc 6e 59 M.Z.pX."......nY
0050 - cf 7e e1 70 c2 .~.p.
SSL_connect:unknown state
SSL_connect:unknown state
read from 0xcd830 [0xd33eb] (5 bytes => 5 (0x5))
0000 - 14 03 03 00 01 .....
read from 0xcd830 [0xd33f0] (1 bytes => 1 (0x1))
0000 - 01 .
read from 0xcd830 [0xd33eb] (5 bytes => 5 (0x5))
0000 - 16 03 03 00 50 ....P
read from 0xcd830 [0xd33f0] (80 bytes => 80 (0x50))
0000 - ab bc 29 dc 16 05 bd 69-ba c1 00 89 88 48 72 b8 ..)....i.....Hr.
0010 - 35 63 8f 14 b5 d6 2b ac-01 66 74 fb dc cd 92 09 5c....+..ft.....
0020 - 86 99 b3 57 51 8b 84 d0-ed 4c 9d ba 13 6e 52 04 ...WQ....L...nR.
0030 - 42 f3 f9 9c 48 a3 01 e2-2b d2 73 b9 8f d8 48 cb B...H...+.s...H.
0040 - 29 74 a2 ec b5 d6 18 5e-ec 9c a1 3e d2 a1 69 64 )t.....^...>..id
SSL_connect:unknown state
---
Certificate chain
0 s:/CN=*.azure-devices.net
i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 5
1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 5
i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIADCCBeigAwIBAgITLQAF3vCaC1etBscWiQAAAAXe8DANBgkqhkiG9w0BAQsF
ADCBizELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcT
B1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEVMBMGA1UE
CxMMTWljcm9zb2Z0IElUMR4wHAYDVQQDExVNaWNyb3NvZnQgSVQgVExTIENBIDUw
HhcNMTkwNDEyMjMwMzMzWhcNMjAwNDEyMjMwMzMzWjAeMRwwGgYDVQQDDBMqLmF6
dXJlLWRldmljZXMubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
0FO0Rpkuh7KcVBFm5N8w0RpXmadeog9d9Mx1OSGPnrHpzFZPCiwDWdFOt4mrkCTx
/dRPXTI0jWc/O3ugYicaEkL05S7128jzbL+Cf9CQdw5rFPEUaORChtzKheIk5FD+
ckFQ9OchjQlvg60hK7Ctjb1QLWZUVXd2M9rWPZM9plPIrIJHfJQbCSVl2+hrByZx
dFx84vM/1pjOqTcncxa9BqczfJFnEtU3r2ADzNrjmt3V96ONPhNscgdaZyronwOE
cWsAkqOYYNPFHQmqA5yO8rC777lyzRtguIcpxu3KikVWkPrYELPMqpIWimFpSB53
9KfP+bsQVre1zhi8XFcZhwIDAQABo4IDxzCCA8MwggEFBgorBgEEAdZ5AgQCBIH2
BIHzAPEAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWoT0+aC
AAAEAwBHMEUCIQDimA41GQw92ryPf5qWX98yD2FrW/O4WhDX3paXzg64WgIgEWqL
RNXJt0IXpY46pwGkK8BtQyRl4hQhhYruvr1rpsQAdwBVgdTCFpA2AUrqC5tXPFPw
wOQ4eHAlCBcvo6odBxPTDAAAAWoT0+e5AAAEAwBIMEYCIQDyVsjPmbDq5W49ceSo
QwtTHevdroIWgt2tDQyRpoF5rQIhAKIsdhZ2mh3oXS4ikFV9yKI0j9ck1FbWP8/R
ldt0LfQXMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwEw
PgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIh9qGdYPu2QGCyYUbgbWeYYX062CB
XYTS30KC55N6AgFkAgEdMIGFBggrBgEFBQcBAQR5MHcwUQYIKwYBBQUHMAKGRWh0
dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL01pY3Jvc29mdCUyMElU
JTIwVExTJTIwQ0ElMjA1LmNydDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AubXNv
Y3NwLmNvbTAdBgNVHQ4EFgQUtUnsROINIxU8u5mj4kXjHQ+0rwEwCwYDVR0PBAQD
AgSwMF0GA1UdEQRWMFSCEyouYXp1cmUtZGV2aWNlcy5uZXSCGiouYW1xcHdzLmF6
dXJlLWRldmljZXMubmV0giEqLnN1Lm1hbmFnZW1lbnQtYXp1cmUtZGV2aWNlcy5u
ZXQwgawGA1UdHwSBpDCBoTCBnqCBm6CBmIZLaHR0cDovL21zY3JsLm1pY3Jvc29m
dC5jb20vcGtpL21zY29ycC9jcmwvTWljcm9zb2Z0JTIwSVQlMjBUTFMlMjBDQSUy
MDUuY3JshklodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwv
TWljcm9zb2Z0JTIwSVQlMjBUTFMlMjBDQSUyMDUuY3JsME0GA1UdIARGMEQwQgYJ
KwYBBAGCNyoBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cubWljcm9zb2Z0LmNv
bS9wa2kvbXNjb3JwL2NwczAfBgNVHSMEGDAWgBQI/iWfdOqHBMK8u46oOF8zxtFs
ZTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQAD
ggIBADGX1X1v9qEE1nQILzDMdSdO7bRm7V/URztxnOeXAg543ogCgUhJdtxNV066
wv/2Dz3F+pVYDPa2aiPuUJtSc/d6GKm2OFTI6nLnXPkE5nazwob9CpWOdebIK29j
J7oWcKycXUiB7Tkcw/jobajJ5O/yI27F4dWAukD/vaVnuD7+lus/qGWjVzTmznmU
7WvddtSqwJIbT9sL3QevEEs5sWMmmtma2hGofBVAEHo4BHnzeTiy0avezxVLtoyy
aLCF23EoOWvMPr6ubvAzRYmgf6OFDJXMch2LNO6UXxCK29HFg78DpWJfHNv2m9dl
KZ8XuYFpVrAy6UlkAXDjjQH1VRqoMg0n2Fjjya84IFUWtqq427qN7pCYXMUUD7zo
W/euyctxulYLkma37JrAGnJibKSTWPtxGCByEceRkE+M0Yt03MFKpWk+Vz+ZMDWG
2K/H8GIOdjHCc6cKw6vgIvRr325zQLzcbODgPNe65shWG/4ca6dSc4eGSEZAjzXH
N6FMCe21E+WSj6HZTk17eElT+KraHIdtIkJO4qdEdma4lYYjT95E1HlC9YsJBQ/T
fUOvp4nKaOQXCwnSsGIjll4LftK2G48vBTn27ezmYoxXH/Z5sOBewJPmoZUxqJko
hpAJQj4x9EIXmatFZFbMq/thgmEza/Nt/knBeRaUPwj4zlQk
-----END CERTIFICATE-----
subject=/CN=*.azure-devices.net
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 5
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA1
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 4105 bytes and written 517 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-SHA256
Session-ID: 3E270000A31239A85D6AA73B0D90EA677147146A5BDCC69C4BF34EB506B62C92
Session-ID-ctx:
Master-Key: 957B93FED2CFF6ACA05AE2F339C408FD5E5E20304745935DDDB86B88D9BE5963F0FBC07ABCCAB746741750C8A9402F7A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 315965102
Timeout : 7200 (sec)
Verify return code: 9 (certificate is not yet valid)
can anyone help me how to deal with certificates at device side.
I had to update mosquitto version 1.5.2 or above and it solved my problem.
Thank you.
I have a Rest api and am trying to implement the security in it using 2 way SSL. I have server.jks placed at a certain location on the server where the application is deployed. Now I have another java application that is acting as a client. I have a identity.jks and trust.jks as below
{
client.ssl.key-store=/cucumber/dev/identity.jks
client.ssl.key-store-password=changeme
client.ssl.trust-store=/cucumber/dev/trust.jks
client.ssl.trust-store-password=changeme
}
however when my client makes a http post request to the api, I get bad certificate error with below logs getting generated at client side.
I am not getting what is missing here.
ssl logs:
{
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
ssl: Ignoring alias server: issuers do not match
ssl: KeyMgr: no matching key found
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
***
*** ECDHClientKeyExchange
ECDH Public value: { 4, 157, 56, 226, 111, 107, 118, 232, 80, 45, 243, 230, 40, 102, 248, 0, 45, 8, 136, 14, 177, 18, 135, 204, 179, 35, 160, 73, 134, 194, 251, 79, 36, 227, 96, 119, 125, 116, 170, 222, 179, 162, 179, 2, 227, 10, 51, 198, 142, 183, 70, 247, 39, 191, 105, 2, 173, 245, 11, 104, 11, 85, 19, 206, 95 }
[write] MD5 and SHA1 hashes: len = 77
0000: 0B 00 00 03 00 00 00 10 00 00 42 41 04 9D 38 E2 ..........BA..8.
0010: 6F 6B 76 E8 50 2D F3 E6 28 66 F8 00 2D 08 88 0E okv.P-..(f..-...
0020: B1 12 87 CC B3 23 A0 49 86 C2 FB 4F 24 E3 60 77 .....#.I...O$.`w
0030: 7D 74 AA DE B3 A2 B3 02 E3 0A 33 C6 8E B7 46 F7 .t........3...F.
0040: 27 BF 69 02 AD F5 0B 68 0B 55 13 CE 5F '.i....h.U.._
finagle/netty4-1, WRITE: TLSv1.2 Handshake, length = 77
SESSION KEYGEN:
PreMaster Secret:
0000: 93 55 61 AA 21 BB 29 A9 FA B2 D9 14 9A 34 DF 90 .Ua.!.)......4..
0010: D1 2B 4E D3 0C 8A 32 E0 EB 07 84 4C F1 27 4A 22 .+N...2....L.'J"
CONNECTION KEYGEN:
Client Nonce:
0000: 5B 6D 9A 26 BB 80 E0 FB 21 14 EF EE 2C 72 F1 E2 [m.&....!...,r..
0010: B6 7C 50 A1 94 9A 20 7D 3E 0C 6F 8A 4B 3A 60 AC ..P... .>.o.K:`.
Server Nonce:
0000: 5B 6D 9A 26 A3 CE 30 1A 70 FF DA 97 E5 35 D3 17 [m.&..0.p....5..
0010: E6 60 7E 74 91 3D 0A BC F3 27 B9 BB 63 97 34 39 .`.t.=...'..c.49
Master Secret:
0000: 5F 0D 19 8D 4A 34 95 68 5E 06 D7 3B F5 1A 1E 32 _...J4.h^..;...2
0010: 07 C4 19 06 66 A7 6E A6 18 50 32 56 67 9B A6 FB ....f.n..P2Vg...
0020: F5 DF 33 9A 66 09 2F 7A DF 37 95 4E 8D BF F7 10 ..3.f./z.7.N....
Client MAC write Secret:
0000: 21 8C 67 0B BF 0C A9 19 5B 6B 27 ED 75 4E AA 49 !.g.....[k'.uN.I
0010: 90 DE EA 37 CF D5 06 19 E9 1A 96 14 3D BC 02 26 ...7........=..&
0020: B4 BA 78 A8 AC D6 0D F9 79 38 FE 94 26 2F 82 2B ..x.....y8..&/.+
Server MAC write Secret:
0000: 3C 14 31 DF 62 00 A1 41 18 1E 21 0C E1 CB 0E EF <.1.b..A..!.....
0010: B4 99 85 96 3C 30 51 FF 3C 5B D5 4E 02 EA 2A 67 ....<0Q.<[.N..*g
0020: 54 C5 72 2B 0B 45 A1 CD BC E8 AB 34 CE FD 66 64 T.r+.E.....4..fd
Client write key:
0000: 18 CF 26 CE 55 12 3C 8F 9E 9F A7 80 4D 2C B0 71 ..&.U.<.....M,.q
0010: A7 0A B9 58 07 E9 2E 38 9D AE 49 61 72 3F D1 2C ...X...8..Iar?.,
Server write key:
0000: 0A DE 66 22 5C 2F 38 1E FE 59 79 25 A3 43 6F E1 ..f"\/8..Yy%.Co.
0010: 6D 80 44 2F 60 81 1F 34 C6 C6 1B A8 63 F0 7A 56 m.D/`..4....c.zV
... no IV derived for this protocol
finagle/netty4-1, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 74, 37, 55, 128, 217, 164, 34, 181, 144, 55, 30, 12 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 4A 25 37 80 D9 A4 22 B5 90 37 1E 0C ....J%7..."..7..
Padded plaintext before ENCRYPTION: len = 96
0000: 54 34 9D E3 6A 86 B0 CC FC A9 2D C8 E1 AF B4 2B T4..j.....-....+
0010: 14 00 00 0C 4A 25 37 80 D9 A4 22 B5 90 37 1E 0C ....J%7..."..7..
0020: F5 A8 F5 FD 3B C7 AE B1 DC FC A1 42 95 04 27 3E ....;......B..'>
0030: 3D DF 96 C1 36 36 CF 77 5B 31 37 6A 1A C0 C9 8C =...66.w[17j....
0040: CF D1 5F 1B 21 05 4E F8 07 28 0C 4E DE 30 32 D2 .._.!.N..(.N.02.
0050: 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F ................
finagle/netty4-1, WRITE: TLSv1.2 Handshake, length = 96
[Raw write]: length = 82
0000: 16 03 03 00 4D 0B 00 00 03 00 00 00 10 00 00 42 ....M..........B
0010: 41 04 9D 38 E2 6F 6B 76 E8 50 2D F3 E6 28 66 F8 A..8.okv.P-..(f.
0020: 00 2D 08 88 0E B1 12 87 CC B3 23 A0 49 86 C2 FB .-........#.I...
0030: 4F 24 E3 60 77 7D 74 AA DE B3 A2 B3 02 E3 0A 33 O$.`w.t........3
0040: C6 8E B7 46 F7 27 BF 69 02 AD F5 0B 68 0B 55 13 ...F.'.i....h.U.
0050: CE 5F ._
[Raw write]: length = 6
0000: 14 03 03 00 01 01 ......
[Raw write]: length = 101
0000: 16 03 03 00 60 36 7B 78 0F A1 87 60 1F F6 0F B8 ....`6.x...`....
0010: 72 88 86 82 35 28 57 25 59 65 D7 DB 2B 37 5C 35 r...5(W%Ye..+7\5
0020: CE 36 EC 8D 85 B0 96 8D C9 8A 9F C3 DF 88 15 65 .6.............e
0030: 3B 4A 78 7D 64 02 CD 18 92 C6 6C 47 21 24 DD 4C ;Jx.d.....lG!$.L
0040: 37 1B 9B 80 64 F3 6B 14 C9 FE 7F DA DF FF 8C 55 7...d.k........U
0050: ED CB 62 77 BF F5 E5 5F C3 99 BB 70 39 5F 28 17 ..bw..._...p9_(.
0060: 4C 8B CF 85 05 L....
[Raw read]: length = 5
0000: 15 03 03 00 02 .....
[Raw read]: length = 2
0000: 02 2A .*
finagle/netty4-1, READ: TLSv1.2 Alert, length = 2
finagle/netty4-1, RECV TLSv1.2 ALERT: fatal, bad_certificate
finagle/netty4-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: bad_certificate
finagle/netty4-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: bad_certificate
finagle/netty4-1, called closeOutbound()
finagle/netty4-1, closeOutboundInternal()
finagle/netty4-1, SEND TLSv1.2 ALERT: warning, description = close_notify
Padded plaintext before ENCRYPTION: len = 80
0000: 4A 51 F2 C8 BA 3D 59 D1 E4 97 9D 88 98 EE 5A 44 JQ...=Y.......ZD
0010: 01 00 05 72 73 DF 87 14 B4 B8 2A 5D D8 D2 E8 92 ...rs.....*]....
0020: 86 DD 9F 47 6E 98 52 6F 76 53 96 9F B2 CF BF 22 ...Gn.RovS....."
0030: 27 20 18 FB 9D 82 CE D1 F0 6E D1 A8 73 67 E8 B5 ' .......n..sg..
0040: C8 72 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D .r..............
finagle/netty4-1, WRITE: TLSv1.2 Alert, length = 80
finagle/netty4-1, called closeInbound()
finagle/netty4-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
finagle/netty4-1, called closeOutbound()
finagle/netty4-1, closeOutboundInternal()
[Raw write]: length = 85
0000: 15 03 03 00 50 D3 44 48 4B 3F 93 CE 6F 0D D8 B5 ....P.DHK?..o...
0010: DE 8B 42 4F 3A EE 65 A5 7E 8A A0 20 2B 46 4D 35 ..BO:.e.... +FM5
0020: 68 E5 CB 1A 7B FD 6F F2 F2 E4 23 1A 71 C2 CF 16 h.....o...#.q...
0030: 73 10 0A B1 86 4D 84 51 BF C8 B7 9C A5 E9 AE 20 s....M.Q.......
0040: 07 73 AD B5 4D 85 81 66 10 5E 92 5B 8C DF D4 80 .s..M..f.^.[....
0050: 9E 6D 8C 7C DC .m...
Aug 10, 2018 3:59:03 PM com.twitter.finagle.netty4.channel.ChannelExceptionHandler exceptionCaught
WARNING: Unhandled exception in connection with clrv0000082211.ic.ing.net/10.44.39.4:8086, shutting down connection
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException: Received fatal alert: bad_certificate
}
I have two queue manager servers running on two boxes. QM1 has a sender channel defined , and QM2 has a receiver channel with the same name.
I have created self signed certificate for each QM , extracted and added the public part of each certificate to the other QM's key db. Altered each channel to use CipherSpec TRIPLE_DES_SHA_US.
This setup works perfectly fine, if QM names don't contain any special character. If name of the sender QM is A_QM and the other one is B_QM , the sender channel never comes up and is in RETRYING state.
while creating self-signed certificate I am using label ibmwebspheremqa_qm
in case of A_QM and ibmwebspheremqqm1 when the queue manager is QM1. Similarly when adding the public part of the certificate I am preserving the other QM's label. This is the only difference in the whole setup.
Is there any restriction in defining QM names if I want to configure SSL or TLS ?
I had no trouble creating a pair of QMgrs and channels as described and getting them to run:
[mqm#rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.
dis chs(*) all
1 : dis chs(*) all
AMQ8417: Display Channel Status details.
CHANNEL(A_QM.B_QM) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2015-04-01) CHSTATI(10.57.43)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(127.0.0.1(3115)) CURLUWID(0C031C5501020010)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000130700000001) LOCLADDR(127.0.0.1(53145))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(B_QM) SHORTRTS(10)
SSLCERTI(CN=rhel6base.ioptconsulting.com)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(B_QM)
XQTIME(0,0) RVERSION(08000001)
RPRODUCT(MQMM)
[mqm#rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremqb_qm
*- ibmwebspheremqa_qm
[mqm#rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremq_a_qm
*- ibmwebspheremqb_qm
[mqm#rhel6base ssl]$
REFRESH SECURITY TYPE(SSL)
The most likely cause for the behavior you are seeing is not issuing refresh security or restarting the QMgrs after updating their keystores. For example:
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM
or
endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM
One aspect of security for the keystore is that there is only ever one version of it in memory at a time. If it were possible for one channel to have one version and another channel to have another version, it would become impossible to determine which was the "right" one in order to detect tampering. So when the KDB is updated, the refresh security command causes the QMgr to stop all running TLS channels, dump the KDB from memory, and reload the KDB when one of the channels starts.
(MQ doesn't use SSL, by the way, never has. It uses TLS with SSL ciphers and now that SSL itself is broken, best to get used to saying TLS because that will help to remember to use TLS ciphers exclusively going forward.)
So after updating the KDB if you did not run the refresh, it is likely that the refresh was not done and the QMgr doesn't yet know about the newly added certificate for the remote QMgr.
When SSLCAUTH(OPTIONAL) is not optional
Another common problem with TLS is a misunderstanding of SSLCAUTH(OPTIONAL). Many people believe that this always results in one-way authentication so they set SSLCAUTH(OPTIONAL) and then exchange certs in only one direction. For example, QM1 has TLS channels to QM2 so obviously has its own personal certificate. Then we try to connect A_QM to it. We import A_QM's personal cert to QM1's KDB, refresh security everywhere, DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL) on both sides and try to start the channel.
The misunderstanding is that if the thing initiating the channel has a personal cert it will send it in all cases. To test with SSLCAUTH(OPTIONAL) requires removing any personal cert from the keystore on the side initiating the connection. Often people do not realize this and spend many hours (in some cases weeks) struggling to understand why this fails.
For your purposes always exchange the personal certs in both directions.
Incomplete cert exchange
The other common problem working with self-signed certs is when a cert is generated multiple times with the same label and/or CN value and there's a mismatch between the personal cert on one end versus the public portion on the other. This is easily checked by viewing the cert details and checking that the fingerprint and other details match like so:
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
Debugging
Check the error logs. In particular, it is good security design to give an attacker as little information as possible to always check the logs of the QMgr that is receiving the connection first. If it has detected the error it will have detailed logs and the sending side will have sparse logs like "the remote QMgr disconnected" which doesn't reveal much to an attacker.
If the error is actually on the sending side, then it will have most detailed error messages and the receiving side will have little or none. For example, if the sending side can't find its stash file the connection isn't ever attempted and the receiving side will have no record of the event.
Finally, there is always the possibility that you may discover a bug working with GSKit and MQ, or that you are trying to use features not relevant to version of MQ that you are working on. For this reason, it is always best to include a dspmqver -a in your question. If after all of this, you still can't get it to work, please update the question with the dspmqver -a output and the results of your further testing.
In summary
To sum up:
QMgr names like A_QM are perfectly valid.
First make sure that the QMgrs have picked up their new KDB files after changes by restarting the QMgrs or running REFRESH SECURITY TYPE(SSL).
Make sure to exchange certs in both directions every time.
Check the error logs on both sides starting with the side receiving the connection request.
Always include output from dspmqver -a when requesting help with GSKit, certs or TLS since the behavior varies by version and fix pack.
I am working in establishing a secure communication channel between a java server and a tls client. During the handshake, all goes well, the client Hello and server Hello messages are correct. Moreover, they both generate the same master secret for the engaged session. But at the really end of the handshake, server throws an exception telling "Ciphertext sanity check fails".
Client trace
0050 - 34 68 ed 2f 6e 4h./n
>>> TLS 1.2 ChangeCipherSpec [length 0001]
01
write to 0x1878b98 [0x18891f0] (6 bytes => 6 (0x6))
0000 - 14 03 03 00 01 01 ......
>>> TLS 1.2 Handshake [length 0010], Finished
14 00 00 0c 14 54 0c 4d c0 22 62 90 c2 92 a1 d1
write to 0x1878b98 [0x18891f0] (45 bytes => 45 (0x2D))
0000 - 16 03 03 00 28 b7 76 bd-36 cd cd eb 8d 9f 34 46 ....(.v.6.....4F
0010 - 25 f7 61 cc cd a3 8e af-6d da 14 60 3c 0f 50 21 %.a.....m..`<.P!
0020 - f4 cc 7a a4 af cf 75 d8-48 54 ee b9 44 ..z...u.HT..D
read from 0x1878b98 [0x187f7e3] (5 bytes => 5 (0x5))
0000 - 15 03 03 00 02 .....
read from 0x1878b98 [0x187f7e8] (2 bytes => 2 (0x2))
0000 - 02 28 .(
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
02 28
Server's side:
[Raw read]: length = 5
0000: 14 03 03 00 01 .....
[Raw read]: length = 1
0000: 01 .
Thread-0, READ: TLSv1.2 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 03 00 28 ....(
[Raw read]: length = 40
0000: B7 76 BD 36 CD CD EB 8D 9F 34 46 25 F7 61 CC CD .v.6.....4F%.a..
0010: A3 8E AF 6D DA 14 60 3C 0F 50 21 F4 CC 7A A4 AF ...m..`<.P!..z..
0020: CF 75 D8 48 54 EE B9 44 .u.HT..D
Thread-0, READ: TLSv1.2 Handshake, length = 40
%% Invalidated: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256]
Thread-0, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
Thread-0, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
Thread-0, called closeSocket()
Thread-0, handling exception: javax.net.ssl.SSLHandshakeException: ciphertext sanity check failed
What I can not understand is why the server is launching such exception while it succeeds in decrypting the ChangeCipherSpec message sent from the client? What could be the reason for such exception?
N.B: I already check and they both derived the same master key, here it is:
Server's side
CONNECTION KEYGEN:
Client Nonce:
0000: 48 B2 6C 02 B1 40 0B D9 6E 14 EB 7A 93 7D 2F 07 H.l..#..n..z../.
0010: 90 CF 1E 5D 65 8A 66 89 54 D4 60 50 BD AC AB 34 ...]e.f.T.`P...4
Server Nonce:
0000: 54 FD 9A E3 BB D4 15 61 A6 0C D3 30 FA 07 0A 16 T......a...0....
0010: 79 A8 79 0B 0A 81 00 95 9C CA C0 7A F1 FF 37 E7 y.y........z..7.
Master Secret:
0000: 39 5B EB 11 66 09 25 B5 6D E4 C7 86 E4 3E 10 BB 9[..f.%.m....>..
0010: B4 F0 D9 B7 BD 7D 8F AD 58 38 31 42 B6 90 53 AD ........X81B..S.
0020: 54 46 36 DC F5 75 8A 9D 77 58 D5 24 6C 96 90 02 TF6..u..wX.$l...
Client's side
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID: 54FD9AE3A3B3BF807F408FA830641F850702E986C27FC631AF8E8E3097038166
Session-ID-ctx:
Master-Key: 395BEB11660925B56DE4C786E43E10BBB4F0D9B7BD7D8FAD58383142B69053AD544636DCF5758A9D7758D5246C969002
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
Thanks in advance to you guys.
Over the last few days I have tried to install a working CAS server (Jasig CAS) on Ubuntu 10.10. I installed Tomcat 6 and configured (server.xml) it for SSL port 8443:
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="8443"
maxHttpHeaderSize="8192"
maxThreads="150"
minSpareThreads="25"
disableUploadTimeout="true"
acceptCount="100"
scheme="https"
secure="true"
clientAuth="false"
SSLEnabled="true"
SSLProtocol="SSLv3"
SSLCertificateFile="/etc/ssl/certs/server_cert.pem"
SSLCertificateKeyFile="/etc/ssl/private/server_key.pem"
SSLCACertificateFile="/etc/ssl/certs/ca_cert.pem"
SSLCACertificatePath="/etc/ssl/certs"
SSLPassword="password"
/>
server_cert.pem, server_key.pem are self-signed x509 certificates. Further, I created a x509v3 certificate for a windows test server (apache2 - xampp) (both servers are in the same LAN and have the IPs 10.0.0.*) . these certificate is installed in the java keystore (cacerts) which is located in the java directory. Since I had always problems with the "alternative subject name" in the client certificate I used an extended version of the openssl config file to create it.
The apache2 ssl config file looks as follows:
<IfModule ssl_module>
....
<VirtualHost 10.0.0.2:443>
SSLEngine on
ServerName 10.0.0.2:443
#ServerAlias 10.0.0.2
DocumentRoot c:/xampp/htdocs
SSLProtocol -all +SSLv3
SSLCertificateFile C:/xampp/ssl/certs/powercomputer_cert.pem
SSLCertificateKeyFile C:/xampp/ssl/private/powercomputer_key.pem
SSLCACertificateFile C:/xampp/ssl/certs/ca_cert.pem
</VirtualHost>
...
</IfModule>
SSL connections are working on both servers (tested by using IE and firefox).
Now comes the hard task. I used a module called phpCAS, programmed in php, on the windows machine to communicate with the CAS server. The module sends a callback url to the CAS server and the server sends a proxy ticket back etc. etc.
BUT I was not able to ensure a valid SSL handshake between both servers. openssl -s_client -connect... for both servers it did not show any errors so I debugged the complete SSL handshake (here is only the relevant part):
...
* ServerHelloDone
* ClientKeyExchange, RSA PreMasterSecret, SSLv3 http-apr-8443-exec-3, WRITE: SSLv3 Handshake, length = 132 SESSION
KEYGEN: PreMaster Secret: 0000: 03 00 78 96 8F EE D3 4A 2F A8 CC F8
F9 D7 2F CB ..x....J/...../. 0010: 9E 3A 58 66 43 0E D5 49 3C 8A B0
3D 3F 2C 89 A0 .:XfC..I<..=?,.. 0020: BC E2 B2 12 F8 D9 55 73 F2 2C
1F CC 81 80 94 22 ......Us.,....." CONNECTION KEYGEN: Client Nonce:
0000: 4E D1 94 ED 32 7F FA 72 40 3C 43 C8 05 E2 62 D0
N...2..r#
91 E2 D0 1C 90 3D 30 DD ..n;W6.......=0. Master Secret: 0000: EB 25
F0 A2 A3 FF 37 06 BB 79 41 C5 E5 07 1C 64 .%....7..yA....d 0010: 77
66 A3 37 71 97 63 AF DB A2 79 47 85 E2 9C 74 wf.7q.c...yG...t 0020:
5F 14 3D 26 57 E8 AD 9B A1 7C AC 33 00 04 4A E0 _.=&W......3..J.
Client MAC write Secret: 0000: C9 20 BF A5 A6 2B C1 DA A8 4E 93 E0
DE 76 06 53 . ...+...N...v.S Server MAC write Secret: 0000: 66 77 5A
3E BD E7 19 55 A4 80 1E E6 8A 9E 2A 5E fwZ>...U......*^ Client
write key: 0000: 58 D1 29 38 13 D8 83 EF 4F BD 7A 18 C8 35 D7 B4
X.)8....O.z..5.. Server write key: 0000: 3A 7B 6A 6E 66 E9 E1 42 A4
3C C3 19 D0 7F 21 FF :.jnf..B.<....!. ... no IV used for this cipher
http-apr-8443-exec-3, WRITE: SSLv3 Change Cipher Spec, length = 1
* Finished verify_data: { 71, 19, 125, 80, 118, 60, 64, 122, 243, 112, 45, 18, 254, 144, 12, 143, 221, 125, 10, 94, 15, 221, 122, 21,
90, 190, 76, 224, 224, 57, 67, 172, 228, 75, 181, 228 }
* http-apr-8443-exec-3, WRITE: SSLv3 Handshake, length = 56 http-apr-8443-exec-3,
READ: SSLv3 Alert, length = 2
http-apr-8443-exec-3, RECV SSLv3 ALERT: fatal, bad_record_mac
http-apr-8443-exec-3, called closeSocket() http-apr-8443-exec-3,
handling exception: javax.net.ssl.SSLException: Received fatal alert:
bad_record_mac 2011-11-27 02:39:57,315 ERROR
[org.jasig.cas.util.HttpClient] -
bad_record_mac> javax.net.ssl.SSLException: Received fatal alert:
bad_record_mac at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at
sun.security.ssl.Alerts.getSSLException(Alerts.java:154) at
....
I did not find any solution in the last few days and I really do not have a clue what is the problem. btw I forced the use of SSLv3.
Thank you very much for any suggestions.