ssl connection failed because of sanity check fail - ssl

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.

Related

Connecting to Azure IoT hub using MQTT libmosquitto C SDK

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.

Old TLS1.0 clients cannot connect to Google App Engine on Custom Domain

We have a Google App Engine project that is setup to work over a custom domain on HTTPS (Using Google managed SSL certs). For most part it is working fine e.g. on Chrome and other modern browsers but NOT for some old TL1.0 clients where it is failing the handshake.
The problem seems with ghs.googlehosted.com GFE servers. AppEngine GFEs on appspot-preview.l.google.com work fine for these clients.
Here is an example log with openssl, connecting to api.my-project.com
$ openssl s_client -connect ghs.googlehosted.com:443 -msg
CONNECTED(00000005)
>>> TLS 1.2 Handshake [length 0139], ClientHello
01 00 01 35 03 03 82 73 d6 6c 32 b7 84 f3 30 57
8f 98 a7 6e e7 c2 f5 b8 be f4 29 55 41 25 35 ab
56 51 3c 1e b9 e3 00 00 98 cc 14 cc 13 cc 15 c0
30 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a3 00 9f 00
6b 00 6a 00 39 00 38 ff 85 00 c4 00 c3 00 88 00
87 00 81 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00
9d 00 3d 00 35 00 c0 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
32 00 be 00 bd 00 45 00 44 c0 31 c0 2d c0 29 c0
25 c0 0e c0 04 00 9c 00 3c 00 2f 00 ba 00 41 c0
11 c0 07 c0 0c c0 02 00 05 00 04 c0 12 c0 08 00
16 00 13 c0 0d c0 03 00 0a 00 15 00 12 00 09 00
ff 01 00 00 74 00 0b 00 04 03 00 01 02 00 0a 00
3a 00 38 00 0e 00 0d 00 19 00 1c 00 0b 00 0c 00
1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00
06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00
01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00
0d 00 26 00 24 06 01 06 02 06 03 ef ef 05 01 05
02 05 03 04 01 04 02 04 03 ee ee ed ed 03 01 03
02 03 03 02 01 02 02 02 03
140735490237384:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_lib.c:124:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
It works connecting to my-project.appspot.com
$ openssl s_client -connect appspot-preview.l.google.com:443
CONNECTED(00000005)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot-preview.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFNjCCBB6gAwIBAgIIf6MEypLTuRMwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODA0MTcxMzQ5NTFaFw0x
ODA3MTAxMjM5MDBaMG8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgSW5jMR4w
HAYDVQQDDBUqLmFwcHNwb3QtcHJldmlldy5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCmdyEZXoKJUUXkt0edaQhKSTWt+6EUBHa2OSGrk5uT9UZo
c2El7MMFl1aFhPzDJR3quZpFXdrGYoB5sVSPHDc33EKhWSG/+4YeYMi/fOiGC3x+
Tqesk+F8TME49MTDvSdOZVuYyVJkIYatTeVdfgW7IZ34bbGviazlf236DRfrhxsQ
HpZEaSXkziDbWCbnAvJSwpmxRX8bOmkncecfwOnS0g8O8is9hmMvFo1yBkvns3bm
5gNzA9JHuLvd6T9iW/rfZbi86oinv+cEUlqxQDesTzaWs399uJDf0Glshs9wr3jM
UzwPP36bulMEfdBak3B+eI+jCm+X7WQbp7aF3GxfAgMBAAGjggHvMIIB6zATBgNV
HSUEDDAKBggrBgEFBQcDATCBxQYDVR0RBIG9MIG6ghUqLmFwcHNwb3QtcHJldmll
dy5jb22CDSouYXBwc3BvdC5jb22CFSoudGhpbmt3aXRoZ29vZ2xlLmNvbYIQKi53
aXRoZ29vZ2xlLmNvbYIRKi53aXRoeW91dHViZS5jb22CE2FwcHNwb3QtcHJldmll
dy5jb22CC2FwcHNwb3QuY29tghN0aGlua3dpdGhnb29nbGUuY29tgg53aXRoZ29v
Z2xlLmNvbYIPd2l0aHlvdXR1YmUuY29tMGgGCCsGAQUFBwEBBFwwWjAtBggrBgEF
BQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMuY3J0MCkGCCsGAQUF
BzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAdBgNVHQ4EFgQU1jst
cVQOljRrrXMTZa4vqe7cCiMwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR3wrhQ
mmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB1nkCBQMwCAYGZ4EM
AQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtpLmdvb2cvR1RTR0lB
RzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQCFibJ0MNHYQk2x6jUHCsdmswo3HACq
nhGV0KXuG0kK6bmPAYYzNuIj6Ee+Dq1x9eFrhxiCu1fQsRKJ42xHTawUBEdhKgcz
wMDxkhRsd3rO1pF8LPTyT4XDACOH20UUxOzBY4yiIP6MU8oZxEGPP7Db2UnpKBJU
/ID1DyAHntoQru/5zNbKFlCfzFgpuTkXCtZlBrY33/V3V3umsOgwOz+isDNW4N+f
RrSpGynywJiHLXFSs/tOr0dFsebG2Dil2ZVDq5aRDhGMn7WKNe8IJvI3GMr6ZUiS
o7WzSPqRij1HOgJoNsL39luSwwOxWJ4znaDkjoewxFmWMqd/7F0lVf4m
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot-preview.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
---
SSL handshake has read 3166 bytes and written 444 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-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-GCM-SHA256
Session-ID: 7C3AAFD46B8D8C8C95F336DEAFFEAB0950B61A01DE9CCD33BC1B4E00B8778ACA
Session-ID-ctx:
Master-Key: F796ECD4CA06D7B3FD8888F5B74AA70C22846CCD207AFA9BC3686AD53E3CBAEA7E2535B9051C0CE2EB96CBA80090CD14
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 00 cf 37 1b ad 9e 5d e3-33 ca 1f 1a 53 78 e0 1b ..7...].3...Sx..
0010 - 9a 7b fe 86 70 da 77 ee-b6 a4 2d 0e 5d 57 c4 b0 .{..p.w...-.]W..
0020 - 5e 3a f3 37 65 d1 bb c3-9f 47 0c e9 05 fc c0 6b ^:.7e....G.....k
0030 - 26 ed a2 27 dc 18 17 88-79 70 4f e4 92 a0 b7 fa &..'....ypO.....
0040 - b6 91 6e c0 7f c6 6e cc-35 81 02 5b 9d 4c 66 6f ..n...n.5..[.Lfo
0050 - 6e 5b d2 7e c5 8f bb 14-70 a8 dd 9b cb ff 50 07 n[.~....p.....P.
0060 - 0f 9c 86 f6 4a d3 bd c7-20 26 2a b6 c3 f7 52 1e ....J... &*...R.
0070 - ce 1d 8e 77 be 65 d6 41-44 c8 9a 30 31 29 66 93 ...w.e.AD..01)f.
0080 - 15 fc 76 f2 6a c5 68 92-23 96 d5 47 50 92 04 e0 ..v.j.h.#..GP...
0090 - 6a de d4 77 b7 bb 02 cf-fd fe 75 71 13 2c c7 34 j..w......uq.,.4
00a0 - 47 48 f3 fa a2 fc ef 7d-7a bd b9 94 8e 40 06 c6 GH.....}z....#..
00b0 - a3 55 56 ec af 29 77 27-7f 40 98 4e ef 0b dc 54 .UV..)w'.#.N...T
00c0 - 6d 8f d1 93 8f 96 2d c2-79 42 1f 4a 7b f4 d6 d9 m.....-.yB.J{...
00d0 - e7 f0 d1 5a 83 ...Z.
Start Time: 1526935566
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE

Exception while waiting for close javax.net.ssl.SSLHandshakeException:

I am working on integrating Webservice which has 2 way SSL.
One such service from same client is already integrated and works fine.
I mean Application A is already integrated with WS 1 hosted on Application B, it's working now.
Now I am integrating Application A with WS 2 hosted on Application B
The same keystore and truststore are in used for both services.
WS 1 works fine, WS 2 fails, I have no real clue of how this could happen. Details of SSL debug logs are below.
I verified the Cipher Suite it is same for both Webservices.
SSL Debug Logs for Failed SSL HandShake - WS 2:
Here I add appropriate ssl log, the difference I found between ssl logs for working service and service which is failing is the certificate chain is not sent by client.
[Raw read]: length = 5
0000: 16 03 01 00 0D .....
[Raw read]: length = 13
0000: 0D 00 00 05 02 01 02 00 00 0E 00 00 00 .............
tomcat-http-1, READ: TLSv1 Handshake, length = 13
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
[read] MD5 and SHA1 hashes: len = 9
0000: 0D 00 00 05 02 01 02 00 00 .........
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
***** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1**
[write] MD5 and SHA1 hashes: len = 269
0000: 0B 00 00 03 00 00 00 10 00 01 02 01 00 4C 1E 64 .............L.d
0010: 17 BD D1 EC E9 14 82 08 12 17 01 1F 78 A0 6A 40 ............x.j#
0020: 16 24 A4 0D 54 B6 F4 CF B5 BB A0 BF 32 CD F5 BC .$..T.......2...
0030: EF 14 3C 8B 9B 72 7A 6D 27 93 59 6A AD 11 82 07 ..<..rzm'.Yj....
0040: 37 8C 68 01 EF 20 D6 0B 00 F4 0B 72 1F DE 0C 28 7.h.. .....r...(
0050: B9 47 D2 39 AB B6 E8 72 B9 6D A7 3F 0C F0 3F 1F .G.9...r.m.?..?.
0060: 3C CE 3C A2 E3 D6 CB 9D BA 5D 93 AF 26 B4 D2 83 <.<......]..&...
0070: 68 7A D2 6B 9A 10 D6 A3 95 36 D7 C1 0F C6 F4 79 hz.k.....6.....y
0080: F9 8F 3D 4D 8C D0 E0 46 E2 5A 32 46 42 19 60 09 ..=M...F.Z2FB.`.
0090: 62 15 EE F8 5C 24 A8 78 27 CD A6 22 5F 5E 94 35 b...\$.x'.."_^.5
00A0: 6B 95 C6 42 34 4B D0 98 74 DE 92 9C 8E 79 0E 3A k..B4K..t....y.:
00B0: 07 D6 17 63 E0 CE CE 8A C0 26 A5 51 A7 E4 35 8A ...c.....&.Q..5.
00C0: 5B 2F 1C A6 3A 0B 49 65 24 24 DC F8 39 42 80 38 [/..:.Ie$$..9B.8
00D0: 03 0D 49 F4 61 32 90 8B BC B6 46 47 6E C0 8B C5 ..I.a2....FGn...
00E0: 00 2F 3D AB 56 5E 04 6A AD 27 D2 39 A3 22 C5 CB ./=.V^.j.'.9."..
00F0: 9D D5 8C 47 B7 89 D1 C2 C2 CC AE F7 ED 4D 97 2F ...G.........M./
0100: 4E 4B AA 2A C5 96 A9 2C 4B 28 E0 09 44 NK.*...,K(..D
tomcat-http-1, WRITE: TLSv1 Handshake, length = 269
[Raw write]: length = 274
0000: 16 03 01 01 0D 0B 00 00 03 00 00 00 10 00 01 02 ................
0010: 01 00 4C 1E 64 17 BD D1 EC E9 14 82 08 12 17 01 ..L.d...........
0020: 1F 78 A0 6A 40 16 24 A4 0D 54 B6 F4 CF B5 BB A0 .x.j#.$..T......
0030: BF 32 CD F5 BC EF 14 3C 8B 9B 72 7A 6D 27 93 59 .2.....<..rzm'.Y
0040: 6A AD 11 82 07 37 8C 68 01 EF 20 D6 0B 00 F4 0B j....7.h.. .....
0050: 72 1F DE 0C 28 B9 47 D2 39 AB B6 E8 72 B9 6D A7 r...(.G.9...r.m.
0060: 3F 0C F0 3F 1F 3C CE 3C A2 E3 D6 CB 9D BA 5D 93 ?..?.<.<......].
0070: AF 26 B4 D2 83 68 7A D2 6B 9A 10 D6 A3 95 36 D7 .&...hz.k.....6.
0080: C1 0F C6 F4 79 F9 8F 3D 4D 8C D0 E0 46 E2 5A 32 ....y..=M...F.Z2
0090: 46 42 19 60 09 62 15 EE F8 5C 24 A8 78 27 CD A6 FB.`.b...\$.x'..
00A0: 22 5F 5E 94 35 6B 95 C6 42 34 4B D0 98 74 DE 92 "_^.5k..B4K..t..
00B0: 9C 8E 79 0E 3A 07 D6 17 63 E0 CE CE 8A C0 26 A5 ..y.:...c.....&.
00C0: 51 A7 E4 35 8A 5B 2F 1C A6 3A 0B 49 65 24 24 DC Q..5.[/..:.Ie$$.
00D0: F8 39 42 80 38 03 0D 49 F4 61 32 90 8B BC B6 46 .9B.8..I.a2....F
00E0: 47 6E C0 8B C5 00 2F 3D AB 56 5E 04 6A AD 27 D2 Gn..../=.V^.j.'.
00F0: 39 A3 22 C5 CB 9D D5 8C 47 B7 89 D1 C2 C2 CC AE 9.".....G.......
0100: F7 ED 4D 97 2F 4E 4B AA 2A C5 96 A9 2C 4B 28 E0 ..M./NK.*...,K(.
0110: 09 44 .D
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 93 71 B9 48 72 57 3D 0A BB 31 75 96 FD 0D ...q.HrW=..1u...
0010: CA 96 42 DD C9 44 B7 A8 B1 F1 A9 C1 C3 27 9F 5F ..B..D.......'._
0020: 9D 52 23 E3 36 AC EA A5 3A 05 1F F8 8D 5D 14 21 .R#.6...:....].!
CONNECTION KEYGEN:
Client Nonce:
0000: 53 8F 60 0E 0B DC B6 61 EB F5 3D C8 8C 7E 62 6D S.`....a..=...bm
0010: 5C 42 CB 7A 31 BC B0 0B D5 6F 0F B2 3C D7 3D A2 \B.z1....o..<.=.
Server Nonce:
0000: 53 8F 60 0E 6A EF 4B 22 15 D3 FB 2B 47 60 66 59 S.`.j.K"...+G`fY
0010: 95 FF 2F 5A 5E CD 24 FD AB BC 53 DA AE DE EE 6E ../Z^.$...S....n
Master Secret:
0000: 81 91 2E C9 84 28 03 2A 96 B7 50 3F 4E A6 F6 6D .....(.*..P?N..m
0010: BA E6 A3 97 90 BA 36 43 7F CC 09 DC 6C 49 23 2A ......6C....lI#*
0020: 08 F9 9A 28 37 E9 6A 7D A7 3D DF 5C 1D EE B8 C8 ...(7.j..=.\....
Client MAC write Secret:
0000: 02 6B 86 CF 08 1C F8 E1 3F 37 56 C3 E9 56 AF 7E .k......?7V..V..
0010: 8C AA 30 AD ..0.
Server MAC write Secret:
0000: 60 3E 08 7B D0 B4 23 48 79 D9 56 4E 98 17 AD 9D `>....#Hy.VN....
0010: E1 DA 9D 33 ...3
Client write key:
0000: 42 6D F6 86 E0 A5 CD 25 C1 32 EB C0 40 82 70 7C Bm.....%.2..#.p.
Server write key:
0000: 3D 28 B3 C1 E6 23 94 5F 3E F9 66 77 B1 42 EE AF =(...#._>.fw.B..
Client write IV:
0000: D1 AF 77 1A 7B 63 55 99 0D 20 EA 5F C9 35 C8 33 ..w..cU.. ._.5.3
Server write IV:
0000: 69 95 12 2F F0 85 8D 2B 8F 1F 96 73 A6 1A D7 10 i../...+...s....
tomcat-http-1, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01 ......
*** Finished
verify_data: { 69, 40, 167, 235, 209, 255, 39, 90, 171, 21, 67, 200 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 45 28 A7 EB D1 FF 27 5A AB 15 43 C8 ....E(....'Z..C.
Padded plaintext before ENCRYPTION: len = 48
0000: 14 00 00 0C 45 28 A7 EB D1 FF 27 5A AB 15 43 C8 ....E(....'Z..C.
0010: F5 F5 5A E3 50 8B BE B4 0A 9C 72 2E FA D7 A2 CD ..Z.P.....r.....
0020: 9A AB 6B FD 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B ..k.............
tomcat-http-1, WRITE: TLSv1 Handshake, length = 48
tomcat-http-1, waiting for close_notify or alert: state 1
[Raw read]: length = 5
0000: 15 03 01 00 02 .....
[Raw read]: length = 2
0000: 02 28 .(
tomcat-http-1, READ: TLSv1 Alert, length = 2
tomcat-http-1, RECV TLSv1 ALERT: fatal, handshake_failure
tomcat-http-1, called closeSocket()
tomcat-http-1, Exception while waiting for close javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
tomcat-http-1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
tomcat-http-1, called close()
tomcat-http-1, called closeInternal(true)
Please help me if you find any clue of what's going wrong here.
I solved this problem by installing Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files + importing ca certificate. Just importing certificate did not work.

Unspecified bytes in SSL serverhello message

During SSL 3.0 handshaking server responses with the following serverhello message
16 03 00 00 51 02 00
00 4d 03 00 4f a1 c1
eb e3 fb 00 a9 c8 25
25 48 6f 89 27 ec bb
80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d
02 20 54 ab 20 ea 05
a6 38 6f ee 55 40 ae
af e2 5d ae 2a 4d c1
c6 f4 09 a7 08 b1 c5
49 39 87 82 d3 f7 00
39 00 00 05 ff 01 00
01 00
I understand this response as follows:
Content-type: 22 (Handshake protocol)
Version: 3.0
Length: a1 (81 bytes)
Content-type: 02 (ServerHello)
Length: 4d (77 bytes)
Version: 3.0
Random: 4f a1 c1 eb e3 fb 00 a9
c8 25 25 48 6f 89 27 ec
bb 80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d 02
SessionID Length: 20 (32 bytes)
SessionID: 54 ab 20 ea 05 a6 38 6f
ee 55 40 ae af e2 5d ae
2a 4d c1 c6 f4 09 a7 08
b1 c5 49 39 87 82 d3 f7
Cipher Suite: 00 39
Compression method: 00
But i can't understand how the last 7 bytes should be interpreted: 00 05 ff 01 00 01 00
That would be the renegotiation_info extension, as defined in RFC 5746:
o If this is the initial handshake for a connection, then the
"renegotiated_connection" field is of zero length in both the
ClientHello and the ServerHello. Thus, the entire encoding of the
extension is ff 01 00 01 00. The first two octets represent the
extension type, the third and fourth octets the length of the
extension itself, and the final octet the zero length byte for the
"renegotiated_connection" field.

SSL over TDS, SQL Server 2005 Express

I capture packets sent/received by Win Xp machine when connecting to SQL Server 2005 Express using TLS encryption.
Server and Client exchange Hello messages
Server and Client send ChangeCipherSpec message
Then Server and Client server send strange message that is not described in TLS protocol
What is the message?
Server side capture:
16 **SSL Handshake**
03 01
00 4a
02 ServerHello
00 00 46
03 01
4b dd 68 59 GMT
33 13 37 98 10 5d 57 9d ff 71 70 dc d6 6f 9e 2c Random[00..13]
cb 96 c0 2e b3 2f 9b 74 67 05 cc 96 Random[14..27]
20 72 26 00 00 0f db 7f d9 b0 51 c2 4f cd 81 4c Session ID
3f e3 d2 d1 da 55 c0 fe 9b 56 b7 6f 70 86 fe bb Session ID
54 Session ID
00 04 Cipher Suite
00 Compression
14 03 01 00 01 01 **ChangeCipherSpec**
16 03 01 ???? Finished ???
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b ???? ???
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41 ???? ???
8e 24
16 03 01
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41
8e 24
This message is already encrypted, therefore to see
14 03 01 00 00 0c
it needs to be decrypted first