Windows client cannot connect to mail server

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: ftv-spandau.de

I ran this command:
openssl s_client -starttls smtp -showcerts -connect mail.ftv-spandau.de:25

It produced this output:
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = ftv-spandau.de
verify return:1

Certificate chain
0 s:CN = ftv-spandau.de
i:C = US, O = Let's Encrypt, CN = R3
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 24 04:35:13 2023 GMT; NotAfter: Dec 23 04:35:12 2023 GMT
-----BEGIN CERTIFICATE-----
...

My web server is (include version): Apache2 2.4.57-2

The operating system my web server runs on is (include version): Debian 12.1

My hosting provider, if applicable, is: Netcup

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.6.0

The above result looks ok, and I can access my mail server via IMAP and SMTP on my Linux client. However, when my friend tries to send email, he gets certificate errors. When he runs the same openssl command in the windows shell, he gets this output:

openssl s_client -starttls smtp -showcerts -connect mail.ftv-spandau.de:25
CONNECTED(000001CC)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1

What may be wrong on his box?

2

Most likely his version of openssl is outdated and doesn't know the ISRG Root X1 root certificate (in its ca bundle trust store), but more importantly which email client is being used - a Windows native one will normally understand ISRG Root X1 just fine. Either way it suggests just outdated software.

1 Like
3

His email client is outlook AFAIK

4

Ok, make sure you are using the full chain file and not just a leaf certificate file for your service certificate. The openssl status on windows is pretty much irrelevant as openssl is not indicative of the windows client status and is largely unused on Windows (windows has it's own tls stack and certificate store). It's extremely unlikely their windows machine does not know ISRG Root X1 because it would have been a problem before now.

1 Like
5

Yeah, I think from your openssl output that you're using cert.pem instead of fullchain.pem, which is probably your problem.

Also, you may want to check across all ports and services being used. It's possible the configuration is different on 25, 143, 465, 587, & 993, or at least whichever of those ports you're using.

4 Likes
6

Possibly unrelated...
But I see different IPv6 addresses for those names:

Name:      mail.ftv-spandau.de
Addresses: 2a03:4000:4a:c52::1001
           45.142.177.191

Name:      ftv-spandau.de
Addresses: 2a03:4000:4a:c52::1410
           45.142.177.191
3 Likes
7

I use the full chain. Here is the complete output for port 993, that is actually used by the mail client:
https://pastebin.com/mUstqzew

8

is used by the email server.

is used by the web server.

1 Like
10

As I said in another post, I use the full chain. Also, on my Linux client the problem does not show up, and on the Windows 10 of another colleague it does not show up either. It seems to be a problem on this specific user. However it worked until 2 weeks before.

11

Windows does things as Microsoft defines - which isn't always as the rest of the Internet does things.
If you use OpenSSL, you can see what is being served.
If you are serving things correctly, then it is a Windows issue.

2 Likes
12

It turned out I had a too restrictive setting in my /etc/postfix/main.cf. Now I have a line there:

smtp_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED

while the old entry was

#smtp_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH, MD5,
#                            DSS, ECDSA, CAMELLIA128, 3DES, CAMELLIA256,
#                            RSA+AES, eNULL

This works now, the error described did not show up anymore. Why it only occurred on
one client, I cannot say.

1 Like
13

I think you can make it even tighter than that - and still allow that Windows client to connect.

Like, why should you have to remove:
aNULL, LOW, EXP, ADH, DSS, eNULL

2 Likes
14

Have fun: Mozilla SSL Configuration Generator

4 Likes
15

These are not in the new exclude line. They were in the old (commented) setting.

1 Like
16

Cipher suite (and TLS default protocol) issues tend to be more prominent if the OS is very old and EOL. E.g. Windows 8 or lower. I'd be surprised to see that problem in Windows 10 unless the users is a developer etc and has manually adjusted their client cipher suites in the registry. They can tweak stuff using Nartac Software - IIS Crypto but for old versions of windows some ciphers etc are not available by default.

2 Likes
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.