Secure connection to web-/mailserver fails under MacOS/iOS

Question

I am desperate: I moved two domains from one server to another which was running smooth. I secured both domains (web & mail) with Letsencrypt certificates. Now the owner of these domains complained about a not working mailserver. But this could not be, because other domains could send and receive e-mails. While troubleshooting, I noticed that no web pages could be retrieved from my server on macOS or iOS. (Connection refused - No secure connection can be established). Under Windows/Linux/Android, all this is no problem and the mail traffic also works flawlessly. So, wtf is going on? It looks like Apple can't work with the created Letsencrypt certificates. What I can't imagine.

Does anyone have any ideas about this? Thanks for your help.

Server: Ubuntu 20.04, Plesk managed

Client: macOS Catalina, Apple Mail

---[EDIT]--- I ran

openssl s_client -connect maildomain.com:465

on a Windows machine AND a Mac, to check out, whats going on at connection with my mailserver. The result on a PC:

    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 = maildomain.com
verify return:1
---
Certificate chain
 0 s:CN = maildomain.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFJzCCBA+gAwIBAgISBBHHETtaspqio7t1ZKYQ36xHMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDUwNzQyMjVaFw0yMjAx ... etc.
-----END CERTIFICATE-----
subject=CN = maildomain.com

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4676 bytes and written 395 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
    Session-ID: DDE8ED4DBF7BD8E8F2D411EDE00C7522C0A15927E3D0C75F58F174B7464270D3
    Session-ID-ctx:
    Master-Key: 6D3167E0283ED9BA1F6427841212C8BAF37FF75998B369DE4184618EF9BFBE9F8860809CC9B7xxxxxxxxxxxxxxxxxxxx
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 21 be ab 05 b8 95 30 14-cf c1 ff 7d 98 aa 3c 82   !.....0....}..<.   ... etc...

    Start Time: 1633683311
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
220 my.server.com ESMTP Postfix (Debian/GNU)
quit
221 2.0.0 Bye
closed

And here comes the response on a Mac:

CONNECTED(00000003)
341:error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version:S23_clnt.c:596:

So, it looks like the Mac can't handle TLS1.2/TLS1.3...

Any suggestions what to do?

macOS Catalina should be able to handle both TLS v1.2 and 1.3 (at least using the system's TLS library; not sure about the `openssl` command). I'd try removing the "ISRG Root X1" certificate from the bundle the server uses -- it's a cross-signed cert from "DST Root CA X3", which just expired, and this may be confusing the clients. — Gordon Davisson, Oct 08 '21 at 17:51
Hey, @Gordon Davisson ! Thanks for your answer. How do you know that these certificates are expired? — Olma67, Oct 09 '21 at 08:15
See [this message at LetsEncrypt](https://letsencrypt.org/2021/10/01/cert-chaining-help.html), and [this from Scott Helme](https://scotthelme.co.uk/lets-encrypt-root-expiration-post-mortem/). Note that the intermediate you're serving has not expired, but the root it's signed by has. This is a bit weird, but was done to support older Android clients (older than 7.1.1). Do you need to support older Android versions? If so, that intermediate will be needed. But I'd try the test anyway, so at least you can tell if it's that intermediate that's confusing the Mac clients. — Gordon Davisson, Oct 09 '21 at 08:48
BTW, another thing to try is adding the actual "ISRG Root X1" (the self-signed one, not the intermediate one with the same name), available [here](https://letsencrypt.org/certificates/), to the chain. It's generally not necessary to include root certs in the server's bundle, but in this case it's worth a try to see if it de-confuses the Mac clients. — Gordon Davisson, Oct 09 '21 at 08:52
Hi, @Gordon. Sorry for the late reply. I removed the certificate thru dpkg but it seems its still there. On connect to my mailserver, I still see the first line after CONNECT. (Initial post, first log). What I am doing wrong? Thanks and regards. — Olma67, Oct 19 '21 at 20:07
I'm getting more suspicious about the TLS version -- try `openssl s_client -connect github.com:443 — Gordon Davisson, Oct 20 '21 at 07:49
Hey @Gordon. Thanks a lot for your tip. I will give it a try. I'm guessing more of a server issue though, as no SSL encrypted websites can be accessed from that server either. But as I said, only from iOS devices and Macs. Do you have any other ideas? — Olma67, Oct 22 '21 at 09:23
Net yet, at this point I'm just looking for more info to isolate what's causing the problem. — Gordon Davisson, Oct 22 '21 at 09:31
Okay. Github responded with "New, TLSv1/SSLv3, Cipher is..." Cert is DigCert High Assurance Cert. — Olma67, Oct 23 '21 at 16:14
@Gordon, I have since been able to use my kids' IPhones and iPads to access the websites hosted on this server. So it looks like there is a problem with the user's Macs after all. Is there a possibility that his computers are infected with something? I am not an Apple freak.... sorry. — Olma67, Oct 23 '21 at 16:22
@GordonDavisson: Even after a software update of the Mac, theres no way to get this working. I am thinking about supporting the old TLS/SSL version. How can I do that? — Olma67, Oct 26 '21 at 18:08
I need to ask, if I removed the expired certificate from server the right way. Because, still: ```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 = maildomain.com verify return:1 ``` — Olma67, Oct 26 '21 at 18:47
The Chain: `Certificate chain 0 s:CN = maildomain.com i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3` I dont get it... — Olma67, Oct 26 '21 at 18:52
Ok, now I'm really confused. That latest OpenSSL result in your comment (is that from Windows?) shows it's still serving the cross-signed intermediate. I'm not familiar with Plesk at all, so I don't have any suggestions about removing it. But as for the github test, the "New, TLSv1/SSLv3" part seems completely wrong, since as far as I can see none of their servers support TLSv1 or SSLv3 (see [this SSL Labs test result](https://www.ssllabs.com/ssltest/analyze.html?d=github.com). So maybe there is some sort of malware/SSL interception/something like that going on? — Gordon Davisson, Oct 26 '21 at 20:16
Nope. I ran ```òpenssl s_client -connect maildomain.com:465 ``` — Olma67, Oct 26 '21 at 22:03
Would you be ok sharing the actual domain name, so I can run tests directly? — Gordon Davisson, Oct 26 '21 at 22:09
This error persists, even after switching to a brand new server. SSLLabs shows green on secured domain but I cant call the webpage. Only with Edge its possible to get the content. Firefox and Chrome: Nope! And Safari is complaining about that it cant establish a secure connection. Wtf is going on? — Olma67, Oct 27 '21 at 19:57

Secure connection to web-/mailserver fails under MacOS/iOS

0 Answers0