Issue Problems with SMTP and port 465 SSL/TLS encryption on iOS and iPadOS

[httPete]

I have a problem that has been bothering me for a few days. I'm running a mail server with Plesk that establishes connections over port 465 with SSL/TLS encryption and over port 587 via STARTTLS (which is considered error prone and insecure). Since I don't actually allow the connection over port 587 and only opened it because of my current issue, I'm looking for help here for my problem.

When I set up a mail account in iOS or iPadOS, it takes about 5 minutes to connect / check settings before a connection is established to the mail server via port 465. If I use port 587 the verification is completed immediately. I do not have this problem when connecting to other systems / clients. Even on my MacBook Pro with Apple Mail or Postbox (Thunderbird offshoot), I can successfully and quickly establish a connection via port 465 to my mail server. Therefore, I think I can rule out a basic misconfiguration of the mail server.

Does anyone have the same problems or maybe tips on how I find out what exactly the problem is?

 

[learning_curve]

~~
Does anyone have the same problems or maybe tips on how I find out what exactly the problem is?

No, but FWIW For outgoing IMAP SMTP mail, all of our iOS devices have always seemed to favour Port 587 over Port 465, yet all of our MacOS devices work exactly the same, on either port (!) which is far from perfect, but... Assuming that you're using IMAP only, thus Port 993 for incoming SMTP mail by default, then IF you're using DANE and DNSSEC and MTA-STS on your own mail server and you're using TLS v1.2 for legacy & TLS v1.3 by default, then any previous security risks (e.g. MITM attacks / STARTTLS / Port 587 etc) have been negated, so your iOS devices' port preference then becomes slightly irrelevant really. You can test absolutely everything of course e.g. here's a quick summary image / sample from checktls.com (I've not posted all the actual test data - it's too detailed!).

 

[httPete]

Hello,

i think the problem could be the following:


According to a test on Qualys SSL Labs the DST Root CA X3 certificate has expired. Which I can't understand though, because according to the following support article you don't have to do anything else with Linux Basis....

Also in my browser the certificate path is displayed clean and everything is up to date?!

 

[learning_curve]

@httPete Yes, that DST Root CA X3 Expiration (September 2021) was covered a long time ago now, by seemingly everybody from Let's Encrypt downwards... There was lots of config/browser certs/warning error online debates & 'anxious moments', but they all seemed to fizzle out in the end.

Not sure if you're aware, but you can issue your SSL Certs with "ISRG Root X1" only, as the root (as we do - see sanitised image below) so those warnings then don't appear and/or have any effect, anywhere at all anymore.

FWIW For us, these didn't cause us any issues on any Apple iOS devices anyway, but some of the Non-Apple browser certs on the macOS Devices did need a few 'adjustments', back when this first occurred, but...Neither OS has had any issues since and that includes when visiting sites that still have the issue in place - like yours, which we can easily & quickly resolve on macOS or iOS right now, even though the new SSL Cert has been issued today, still has that ^ issue present, as you've already seen. So, having said all that, it's not impossible, but it's unlikely that it's just this issue alone.

On the SSL Labs Test, you'll have also seen that on SSL Certificate #2, you've got the Alternative name / Mismatch issue, in the first part of the chain, which then results in that SSL Certificate #2 itself having the status of "Not Trusted'. In theory... that shouldn't actually matter (e.g. it's not caused us any problems visiting your domain / url today, so...) but, you never quite know with Apple.

Can't comment on the browser certificate path that you've posted, as it looks like a Windows browser, but regardless, that does makes sense, as most of the browsers now automatically chose to ignore the expired DST Root CA X3 (if present) and focus on the ISRG Root X1 aspect of the SSL Certs (but a couple needed a helping hand previously - see above). All the different macOS browsers that we use, show all of your SSL Cert in fine detail, but they do indeed, just see the ISRG Root X1 aspect and NOT the expired DST Root CA X3 aspect, just as your own browser certificate path does, in the image you've posted.

 

[Bitpalast]

When I set up a mail account in iOS or iPadOS, it takes about 5 minutes to connect / check settings before a connection is established to the mail server via port 465.

This could be caused by different algorithms for password encryption being checked by your mail software, too. For example, it first trieds CRAM-MD5, then goes on to DIGEST-MD5 etc., until it hits the right one that it can work with and it might spend a long while on some of these when the response is not as expected.

 

[httPete]

hey, thanks a lot for your answers. Unfortunately, I haven't made any progress with the problem yet. I tried different algorithms, but that didn't make any difference either. @learning_curve Unfortunately, I didn't quite make sense out of your answer.

Does anyone have a tip what I can do?

 

[httPete]

... sory I had forgotten something. I took two more screenshots of the certificate on my Apple device.

 

[learning_curve]

@learning_curve Unfortunately, I didn't quite make sense out of your answer.

Which part? There's a few different parts in that post.

 

[learning_curve]

... sory I had forgotten something. I took two more screenshots of the certificate on my Apple device.

According to the forum rules, yuu need to post everything on here in English, but (to be fair) in this case, it's easy enough for us to see & understand anyway (as we use lots of Apple Devices). The original issue that you posted about is NOT to do with that certificate (view) from that Apple device that you've posted...

It's to do with your own Port 587 / Port 465 choices - which you might want to re-visit again etc plus, the fact that the SSL certificate that you've issued, still has an alternative path (path #2 - that you've already posted an image of in post #3 above) which includes, the now outdated and effectively defunct - apart from some Android devices - see the Let's Encrypt Article - DST Root CA X3 source. Port 587 / Port 465 choices / reasons for them / security of each / etc is a seperate topic, but changing them on any of your Apple devices is a very, very simple task - even if you only do it temporarily for testing & comparing results. You could re-issue your SSL certificate and make it "ISRG Root X1" only (there are several ways to do this within and/or outside of Plesk) and perhaps (if you have time) correct your No - DNS CAA & the No - Session resumption (caching) issues too, which are shown on SSLLabs as this would also add benefit for you.

Most (but not all) browsers and OS ignore the path2 now by defaut and will only take and use the "ISRG Root X1" path anyway, as has been mentioned, but some still don't (e.g. some Android) and/or needed slight mods back when this first happened, to ensure that they did. The easiest way (unless you definitely do need to retain some of those Android devices' usability) is to re-issue your SSL certificate with "ISRG Root X1" only, which then makes it the only path available.