Score:0

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

am flag

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?

ph flag
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.
am flag
Hey, @Gordon Davisson ! Thanks for your answer. How do you know that these certificates are expired?
ph flag
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.
ph flag
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.
am flag
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.
ph flag
I'm getting more suspicious about the TLS version -- try `openssl s_client -connect github.com:443 </dev/null` from the Mac, and see if it gets through, and if it does look for the `New, TLSv1.x, Cipher is ...` line in the output. The github servers seem to only support TLS v1.2 and 1.3 and use a DigiCert certificate, so this should make a good test of TLS version support vs certificate problems.
am flag
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?
ph flag
Net yet, at this point I'm just looking for more info to isolate what's causing the problem.
am flag
Okay. Github responded with "New, TLSv1/SSLv3, Cipher is..." Cert is DigCert High Assurance Cert.
am flag
@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.
am flag
@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?
am flag
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 ```
am flag
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...
ph flag
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?
am flag
Nope. I ran ```òpenssl s_client -connect maildomain.com:465 ```
ph flag
Would you be ok sharing the actual domain name, so I can run tests directly?
am flag
Of course, If you give me your e-mail address.... ;)
am flag
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?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.