Debugging TLS connection to MS Exchange Server 2007

[Anton Shepelev]

Hello.

Please, help me debug connetcing to Windows Server Exchange
2007 via TLS. My e-mail client (Sylpheed 3.7.0) fails with:

* creating IMAP4 connection to ex-07.git.ru:143 ...
[16:55:42] IMAP4< * OK The Microsoft Exchange IMAP4 service is ready.
[16:55:42] IMAP4> 1 CAPABILITY
[16:55:42] IMAP4< * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS IDLE NAMESPACE LITERAL+
[16:55:42] IMAP4< 1 OK CAPABILITY completed.
[16:55:42] IMAP4> 2 STARTTLS
[16:55:42] IMAP4< 2 OK Begin TLS negotiation now.
** LibSylph-WARNING: SSL_connect() failed with error 5, ret = 0 (error:00000000:lib(0):func(0):reason(0))

Testing the connection with:

openssl s_client -tls1_2 -connect ex-07.git.ru:143 -starttls imap -msg -debug

produces slightly different results (attached) from an in-
domain Windows machine (test-win.txt) and from a Linux
machine in the same local network (test-lin.txt). Both
invocations report:

no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 191 bytes and written 238 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.2
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1792332202
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Does it mean no TLS 1.2 was detected? The Winows invocation
has:

read from 0000005979D9A280 [0000005979D0D5F0] (16384 bytes => -1)
Connecting to 192.168.0.14
write:errno=10053

at the end, whereas the Linux invocation has:

write:errno=104
write to 0x565291e25b20 [0x565291e32ea0] (212 bytes => 212 (0xD4))

after

>>> TLS 1.2, Handshake [length 00cf], ClientHello

and no write error at the end:

read from 0x565291e25b20 [0x565291cd4880] (16384 bytes => 0)

If I don't specify -tls1_2 (which is certainly supported MS
Exchange 2007), the traces are very similar, with different
binary blocks and with 1.2 replaced with 1.3.

Consequently, when I try to connect via stunnel on Windows,
my client fails with:

** LibSylph-WARNING: fd_recv(): failed with 10054 (errno = 0)
** LibSylph-WARNING: [17:14:03] Cannot get greeting message (2)
** Cannot get greeting message (2)

and the following stunnel log:

2026.10.18 17:14:03 LOG5[0]: Service [exchange-imap] accepted connection from 127.0.0.1:57783
2026.10.18 17:14:03 LOG6[0]: s_connect: connecting 192.168.0.14:143
2026.10.18 17:14:03 LOG5[0]: s_connect: connected 192.168.0.14:143
2026.10.18 17:14:03 LOG5[0]: Service [exchange-imap] connected remote server from 192.168.0.212:57784
2026.10.18 17:14:03 LOG6[0]: SNI: sending servername: ex-07.git.ru
2026.10.18 17:14:03 LOG6[0]: Peer certificate required
2026.10.18 17:14:03 LOG3[0]: SSL_connect: ssl/record/rec_layer_s3.c:698: error:0A000126:SSL routines::unexpected eof while reading: client 127.0.0.1:57783
2026.10.18 17:14:03 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Please, help me undestand the situation, in order (at least)
to ask the admininstrator the right questions.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

[Alicja Kario]

Server rejects the ClientHello. Now _why_ that happens can be caused by
many different reasons.

Comparing a working ClientHello with one that doesn't work is realistically
the only way to diagnose it.

Kind regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

[Anton Shepelev]

Alicja Kario:

> Anton Shepelev:

>
> > Please, help me debug connetcing to Windows Server
> > Exchange 2007 via TLS.

> > [...]

>
> Server rejects the ClientHello. Now _why_ that
> happens can be caused by many different reasons.

Thank you, Alicja. Does your observation apply to my
s_client trace from the Linux machine, which has:

>>> TLS 1.2, Handshake [length 00cf], ClientHello

[binary data elided]

write:errno=104
write to 0x565291e25b20 [0x565291e32ea0] (212 bytes => 212 (0xD4))

or to the corresponding trace collected from a Windows
machine, which has:

>> TLS 1.2, Handshake [length 00d1], ClientHello
[binary data elided]
write to 000000C64B9E8A40 [000000C64B9FEC60] (214 bytes => 214 (0xD6))

showing no error message after the ClientHello packet?
The Windows trace has a different error, at the very end
of the exchange. The difference may be caused by the
Windows machine being part of the (NT) domain, whereas
the Linux machine is not.

> Comparing a working ClientHello with one that doesn't
> work is realistically the only way to diagnose it.

Thanks. Hopefully, I'll find a working IMAP server with
STARTTLS and use it as reference.

[Dimitri Ledkov]

Compile statically linked https://github.com/rbsec/sslscan

Use it against the server under question.

Then compile sslscan as dynamically linked and test it again.

This will tell you what server supports, and what your dynamically linked openssl supports as a client.

TLSv1.2 came out in 2008, thus maybe Exchange Server 2007 caps out at TLSv1.0.

You might want to compile a statically linked openssl into stunnel with a default security level of 0 or 1, to front that server to add TLSv1.3 capability in front of it.

Also look at envoy proxy, it might also be able to help here.

Regards,

Dimitri.

[Alicja Kario]

Windows TLS implementations are well known for not sending Alert messages
but rather closing the connection with no error at all.

Neither of the connections you showed are actually sucessful.
Without a successful connection to compare to it is not possible to guess
what is the reason for the server rejecting the connection.

But as Dimiti mentioned, TLS version intolerance is a likely reason:
try connecting with `-tls1` switch instead of `-tls1_2` (you might need to
use @SECLEVEL=0 for it to work if you use modern OpenSSL).

[Anton Shepelev]

Alicja Kario:

> Windows TLS implementations are well known for not
> sending Alert messages but rather closing the
> connection with no error at all.

Thanks. It may explain the behavior I am observing.

> Neither of the connections you showed are actually
> sucessful. Without a successful connection to compare
> to it is not possible to guess what is the reason for
> the server rejecting the connection.

403-fs.txt contains the trace of what I think is a
successful connection, using OpenSSL 4.0.3 against
freeshell.de. I have not been able to prevent openssl
from hanging and waiting for user input in this test.
Although I invoked it with all of the options said to
disable interactive mode:

-no-interactive -quiet -ign_eof

I still had to press Enter to terminate the session.

> But as Dimiti mentioned, TLS version intolerance is a
> likely reason: try connecting with `-tls1` switch
> instead of `-tls1_2` (you might need to use
> @SECLEVEL=0 for it to work if you use modern OpenSSL).

Indeed earlier I failed to make -tls1 or -tls1_1 to have
effect: they were accepted but ignored to my surprise.
Since Windows OpenSSL is looking for its configuration
file at a path that can exist only on Unix, I tried to
supply my own configuraiton file, but some reason or
other, `openssl' didn't recognize that option:

s_client: Unknown option: -config

(Does s_client not support -config by design?)

With `-cipher default@seclevel=0', it indeed tries
TLSv1, and fails (403-ms-tls1.txt).

I also found a Windows binary of the historical OpenSSL
0.9.8h from 2008.05.28, and it fails to connect to our
MS Exchange in exactly the same way (098-ms.txt).

I will answer Dimitri's post a bit later.

[Anton Shepelev]

Dimitri Ledkov:

> Compile statically linked https://github.com/rbsec/sslscan
>
> Use it against the server under question.

I have been able to use the official binary, which happens
to test for TLSv1, and writes:

TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 disabled
TLSv1.3 disabled

The full output is attached in sslscan.txt.

> Then compile sslscan as dynamically linked and test it
> again. This will tell you what server supports, and what
> your dynamically linked openssl supports as a client.

Looks like the server does not support anything? Thanks for
suggesting sslscan.

> > If I don't specify -tls1_2 (which is certainly supported
> > MS Exchange 2007)
>

> TLSv1.2 came out in 2008, thus maybe Exchange Server 2007
> caps out at TLSv1.0.

I goofed and hallucinated. I clearly remember searching for
`TLS' in "The Reference" and finding an instance of TLS 1.2,
yet I cannot find it anymore. Mandela effect... Mefears I
found what I /wanted/ to find.

> You might want to compile a statically linked openssl into
> stunnel with a default security level of 0 or 1, to front
> that server to add TLSv1.3 capability in front of it.

Even as Alicja told me to specify the zero security level to
cause openssl actually to obey my orders for it to try
TLSv1, which I did, but it failed connect anyway (see my
reply to her for details).

> Also look at envoy proxy, it might also be able to help
> here.

The scope of that project makes one's head spin. I don't
know I might use it at all. Can it work as an IMAP-to-
Exchange gateway of sorts?