Ask Your Question
0

TLS1.2 RST After Server Key Exchange, Server Hello Done

asked 2023-11-27 20:07:43 +0000

maxcoder88 gravatar image

I am not sure if this is a TLS1.2 connection issue or something else. I have this WireShark trace summary.

I have a client and Exchange server. I am using below command on client machine.

Invoke-WebRequest -Uri https://autodiscover.contoso.com -UseBasicParsing

As far as I understand , The client is closing the connection after receiving the server certificate - which suggest that the client does not like the server certificate.

What could be causing this?

Please let me know if you need anymore info.

Wireshark Output :

2647    6.854017    SOURCE  DESTINATION TCP 66  18543 → 443 [SYN, ECE, CWR] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
2649    6.869529    DESTINATION SOURCE  TCP 66  443 → 18543 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 WS=256 SACK_PERM
2650    6.869602    SOURCE  DESTINATION TCP 54  18543 → 443 [ACK] Seq=1 Ack=1 Win=262656 Len=0
2651    6.870704    SOURCE  DESTINATION TLSv1.2 217 Client Hello (SNI=autodiscover.companyB.com)
2703    6.883765    DESTINATION SOURCE  TCP 1514    443 → 18543 [PSH, ACK] Seq=1 Ack=164 Win=130816 Len=1460 [TCP segment of a reassembled PDU]
2708    6.885744    DESTINATION SOURCE  TCP 1514    443 → 18543 [PSH, ACK] Seq=1461 Ack=164 Win=130816 Len=1460 [TCP segment of a reassembled PDU]
2709    6.885775    SOURCE  DESTINATION TCP 54  18543 → 443 [ACK] Seq=164 Ack=2921 Win=262656 Len=0
2710    6.885900    DESTINATION SOURCE  TLSv1.2 914 Server Hello, Certificate
2713    6.887267    SOURCE  DESTINATION TCP 54  18543 → 443 [FIN, ACK] Seq=164 Ack=3781 Win=261888 Len=0
2753    6.904773    DESTINATION SOURCE  TLSv1.2 396 Server Key Exchange, Server Hello Done
2754    6.904773    DESTINATION SOURCE  TCP 60  443 → 18543 [FIN, ACK] Seq=4123 Ack=165 Win=130816 Len=0
2757    6.904839    SOURCE  DESTINATION TCP 54  18543 → 443 [RST, ACK] Seq=165 Ack=4123 Win=0 Len=0
2758    6.904889    SOURCE  DESTINATION TCP 54  18543 → 443 [RST] Seq=165 Win=0 Len=0

FROM WORKING MACHINE WIRESHARK RESULT :

1636    11.029014   SOURCE  DESTINATION TCP 66  62424 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
1639    11.042309   DESTINATION SOURCE  TCP 66  443 → 62424 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 WS=256 SACK_PERM
1640    11.042440   SOURCE  DESTINATION TCP 54  62424 → 443 [ACK] Seq=1 Ack=1 Win=262656 Len=0
1641    11.045394   SOURCE  DESTINATION TLSv1.2 217 Client Hello (SNI=autodiscover.contoso.com)
1642    11.058038   DESTINATION SOURCE  TCP 1514    443 → 62424 [PSH, ACK] Seq=1 Ack=164 Win=130816 Len=1460 [TCP segment of a reassembled PDU]
1643    11.058672   DESTINATION SOURCE  TCP 1514    443 → 62424 [PSH, ACK] Seq=1461 Ack=164 Win=130816 Len=1460 [TCP segment of a reassembled PDU]
1644    11.058700   SOURCE  DESTINATION TCP 54  62424 → 443 [ACK] Seq=164 Ack=2921 Win=262656 Len=0
1645    11.059453   DESTINATION SOURCE  TLSv1.2 914 Server Hello, Certificate
1647    11.070975   DESTINATION SOURCE  TLSv1.2 396 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2023-11-27 21:15:17 +0000

André gravatar image

Most likely the certificate is invalid.

In frame 2651 the Client Hello contains the SNI "autodiscover.companyB.com". In frame 2710 the server sends its certificate. This is followed by a TCP FIN -- that should have been a TLS alert by the way.
So the client concludes something is wrong. For example the certificate does not match the SNI name or the certificate chain is invalid.

Without a proper TLS alert, the only way to know the reason is to dig in the application (debug?) logging.

You can also check the certificate manually with the opensll command:

openssl s_client -connect autodiscover.companyB.com:443 -servername autodiscover.companyB.com
edit flag offensive delete link more

Comments

As you said , I am using openssl command.

btw, I have an environment like below.

I am using wildcard certificate for autodiscover URL. I think it is not a problem with the certificate.

Source machine behind F5 Load Balancer

Destination machine (which is hosting autodiscover.companyB.com) behind Citrix Netscaler.

if I use on the source machine not behind load balancer then it works.

.\openssl.exe s_client -connect autodiscover.companyB.com:443 -servername autodiscover.companyB.com

CONNECTED(000001B4)

187A0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl\statem\extensions.c:893:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 3776 bytes and written 338 bytes

Verification: OK

New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: BFC22EBD41A51EB5BF3434010F53BB0092F896FE607210D9848611104A8FC420 Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP ...(more)

maxcoder88 gravatar imagemaxcoder88 ( 2023-11-28 11:10:28 +0000 )edit

So there is an F5 and Netscaler in the network path. If the F5 is in full-proxy mode and the Netscaler does deep-packet inspection, then you have 3 TLS sessions in series instead of 1. You'll have to check each of them. I know the F5 can do network capture as well.

André gravatar imageAndré ( 2023-11-28 21:47:27 +0000 )edit

I figured it out my issue. Very strange. I've exported SCHANNEL reg from working machine. First , I have removed SCHANNEL reg key on-working machine. After I've imported exported reg key again. And reboot. Voila! :) I am assuming , IISCrypto will break my Exchange TLS configuration

maxcoder88 gravatar imagemaxcoder88 ( 2023-11-29 20:00:56 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2023-11-27 20:07:43 +0000

Seen: 356 times

Last updated: Nov 27 '23