OpenSSL hangs at CONNECTED(00000003)

Question

I am setting up the https connection of my AEM application in a RHEL server hosted in AWS. Followed the documentation provided by Adobe. For the 1st author instance it worked successfully, but on my 2nd server and 3 server, it didnt.

I tried a couple of debugging to make sure that the connectivity is working and that no firewalls are blocking.

When I tried to openssl in debug mode I got the following:

It just hangs and doesn't proceed to the next one like in the 1st server:

2nd Server (with Issue):

openssl s_client -connect localhost:5433 -debug -msg
CONNECTED(00000003)
write to 0xfb16d0 [0xff5270] (249 bytes => 249 (0xF9))
0000 - 16 03 01 00 f4 01 00 00-f0 03 03 57 fe bd 40 06   ...........W..@.
0010 - 00 bf 15 c5 e0 83 79 18-b4 a3 f8 f0 2f b6 a8 70   ......y...../..p
0020 - b7 4f fc 48 6f e6 c6 0a-ef 08 de 00 00 84 c0 30   .O.Ho..........0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b   .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a   .j.9.8.....2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f   .&.......=.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67   .+.'.#.........g
0070 - 00 40 00 33 00 32 c0 12-c0 08 00 9a 00 99 00 45   [email protected]
0080 - 00 44 00 16 00 13 c0 31-c0 2d c0 29 c0 25 c0 0e   .D.....1.-.).%..
0090 - c0 04 c0 0d c0 03 00 9c-00 3c 00 2f 00 96 00 41   .........<./...A
00a0 - 00 0a 00 07 c0 11 c0 07-c0 0c c0 02 00 05 00 04   ................
00b0 - 00 ff 01 00 00 43 00 0b-00 04 03 00 01 02 00 0a   .....C..........
00c0 - 00 08 00 06 00 19 00 18-00 17 00 23 00 00 00 0d   ...........#....
00d0 - 00 22 00 20 06 01 06 02-06 03 05 01 05 02 05 03   .". ............
00e0 - 04 01 04 02 04 03 03 01-03 02 03 03 02 01 02 02   ................
00f0 - 02 03 01 01 00 0f 00 01-01                        .........
>>> TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 57 fe bd 40 06 00 bf 15 c5 e0
83 79 18 b4 a3 f8 f0 2f b6 a8 70 b7 4f fc 48 6f
e6 c6 0a ef 08 de 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 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 c0 12 c0 08 00 9a 00 99 00 45 00 44 00 16 00
13 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 c0 0d c0
03 00 9c 00 3c 00 2f 00 96 00 41 00 0a 00 07 c0
11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 00 23 00 00 00 0d 00 22 00 20 06
01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00
0f 00 01 01

Server 1 (without issue):

>>> TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 57 fe cb 7b 28 ba ea e1 89 71
ad fb 1d 8b 97 e9 83 2b dc e4 53 c5 bf 75 8f 58
74 42 63 29 6b 20 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 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 c0 12 c0 08 00 9a 00 99 00 45 00 44 00 16 00
13 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 c0 0d c0
03 00 9c 00 3c 00 2f 00 96 00 41 00 0a 00 07 c0
11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 00 23 00 00 00 0d 00 22 00 20 06
01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00
0f 00 01 01
read from 0x17796d0 [0x17c27d0] (7 bytes => 7 (0x7))
0000 - 16 03 03 06 35 02                                 ....5.
0007 - <SPACES/NULS>
read from 0x17796d0 [0x17c27da] (1587 bytes => 1587 (0x633))
0000 - 00 4d 03 03 57 fe cb 7b-51 64 70 bc 08 c8 91 24   .M..W..{Qdp....$
0010 - c4 da 8c cf 94 94 7d c5-0f 45 ee 2c 86 99 1d ff   ......}..E.,....
0020 - b6 a9 3e 66 20 57 fe cb-7b e7 b2 a4 56 15 3b 46   ..>f W..{...V.;F
0030 - 98 92 b4 95 56 7f 95 4e-4e f3 cd ce d8 cd 98 29   ....V..NN......)
0040 - c7 fe 1e 6f 8b 00 9f 00-00 05 ff 01 00 01 00 0b   ...o............
0050 - 00 03 cd 00 03 ca 00 03-c7 30 82 03 c3 30 82 02   .........0...0..
0060 - ab a0 03 02 01 02 02 04-6e 0d a4 0f 30 0d 06 09   ........n...0...
0070 - 2a 86 48 86 f7 0d 01 01-0b 05 00 30 81 91 31 0b   *.H........0..1.

Lorollas

Does this same client have full handshake with server 1? – Infatuated

Yeah it does in server 1. I have added the output of the 1st server, showing that it continues. It seems that stop reading after that for the 2nd and 3rd server. – Lorollas

What happens when you run s_server on the said port in S2 & S3 instead of your application? – Infatuated

Thanks Prabhu. What do you mean by running s_server? – Lorollas

I've generated the keystore using the below command: keytool -genkeypair -keyalg RSA -validity 3650 -alias cqse -keystore [quickstart_dir]/ssl/keystorename.keystore -keypass key_password -storepass storepassword -dname "CN=Host Name, OU=Group Name, O=Company Name,L=City Name, S=State, C=Country_ Code" – Lorollas

It's a OpenSSL to just like s_client that you are trying. It can be used to debug server side issues. I wanted to check if that would respond to client hello form s_client – Infatuated

I've am using the java keytool. Do not the cert files to test for openssl s_server. – Lorollas

Answer 1

This is MTU problem Change MTU size

ifconfig ens160  mtu 1400

Leader

how on earth did you figure it out? :) – Virulent

I'm utterly lost. I'm running Manjaro and pretty much "out of the blue" some pages stopped working (DNS ok, connection is established, but no content on HTTPS). Among others, github.com, so rather annoying. While triaging the issue, I came across this thread, (I got the same error) and surprisingly decreasing the MTU to 1400 from 1500 (on Arch based distros, "ip link set <device> mtu 1400") did the trick. I'm very curious to know what's going on since I've never meddled with the MTU size. – Inlaw

Answer 2

Its your firewall. You need to add a route or rule from the source Default GW to the target IP address.

Recollect