IMAP account stopped working after upgrade to iOS 9 - problem with CAcert certificate?

Question

After upgrading my iPhone 6+ from iOS 8 to iOS 9, my IMAP email account stopped working. When the Mail app tries to connect to the server, it fails and displays an alert with the title "Cannot get Mail" and the message "The mail server x.y.z is not responding. Verify that you have entered the correct account info in Mail settings.".

I did check the account info, and it is indeed correct. Interestingly, I do not get any error messages from the settings app when I try to save the account. I have tried entering wrong information on purpose (wrong username, wrong password, wrong TCP port), and whenever I do that and try to save the account, the settings app shows an alert "The IMAP server x.y.z is not responding.". So I am really sure that the information I have entered is correct.

Moreover, I have two other iOS devices in the household (an iPad 2 and an iPhone 4S) which are configured to use the same account and which are still on iOS 8 - from these devices the account works properly, so I also know that the problem is not something basic like the IMAP server is down.

I have tried various things (see below), but without success. The only thing I know for certain is that the problem is somehow connected to TLS and/or certificates. Taking into account the information from this AskDifferent question I suspect it's a problem with the CAcert certificate, but I am not sure.

Do you know anything about changes in iOS 9 regarding the handling of certificates (untrusted or otherwise)? Or do you have other clues that might help me solve this problem?

---

Information about the server:

• The IMAP server runs on a Debian machine over which I have full control
• The IMAP server is Courier IMAP
• The IMAP server accepts connections on the standard IMAP port 143
• The IMAP server requires STARTTLS to enforce that all traffic is encrypted via TLS
• The IMAP server uses a wildcard certificate
• The IMAP server provides the whole certificate chain to the client
• The root CA is CAcert.org (link to root and intermediate CA certificates)
• Because CAcert.org is not, by default, in the trusted CA store of iOS 9, I have manually installed the root and intermediate CA certificates on the iPhone 6+
• Courier version = 0.73.1 (/usr/bin/imapd --version)
• OpenSSL version = 1.0.2d (/usr/bin/openssl version)

---

What have I tried?

• The first thing I did is, I deleted the entire account configuration in the iPhone's settings app, then created a new account and re-entered the configuration details. No success.
• I upgraded various packages on the Debian machine, including Courier and OpenSSL, to make sure that the server has the "latest and greatest" security capabilities. No success.
• I read somewhere that iOS 9 might require TLS 1.2 on the server side, so I double-checked that the IMAP server indeed offers that version of TLS to its clients. It does. This is the command I used for verification: openssl s_client -connect mail.herzbube.ch:143 -starttls imap. If you run this you will see a block with information about the SSL session towards the end, this block contains a line that shows the TLS version that is used (Protocol : TLSv1.2). Note that in order to get TLS v1.2, your client-side version of OpenSSL must also support this. For instance, OpenSSL on my Mac OS X Yosemite (10.10.3) laptop is too old, i.e. it is only version 0.9.8.zd and does not seem to understand TLS 1.2, so I get Protocol : TLSv1.
• I deleted the CAcert root and intermediate certificates on the iPhone, then re-installed them. Nope, didn't help.
• I temporarily disabled the requirement for TLS on the server-side, and this solves the issue, i.e. now the Mail app can connect, login and get emails from the server. Obviously this is not a real solution, since I don't want the traffic to the IMAP server to be in clear-text, but at least now I know that the problem is somehow connected to TLS (and/or certificates).
• I updated the iPhone to iOS 9.0.1. No success.

Answer 1

It turns out that in my case the problem is not the CAcert certificate, nor the TLS version - it's the enryption ciphers offered by OpenSSL on the server, or rather, that some of them use parameters that are too weak.

When Apple shipped their iOS 8.4 update a while ago, they made improvements to their TLS library coreTLS in order to prevent the so-called Logjam attack. It is safe to assume that these improvements are also part of iOS 9. As Apple mentions in this technote, coreTLS no longer accepts export-strength ephemeral DH cipher suites. In my case, this is not the problem, though, because my server does not offer such ciphers to its clients.

What Apple "forgot" to say in their technote is that they also added new requirements for the remaining DH ciphers. In this, they probably followed the Guide to Deploying Diffie-Hellman for TLS, which is an "official" document with recommendations made by the people who discovered the Logjam attack. Specifically, coreTLS now requires that DH cipher suites use a minimum DH group size.

The "DH group" is a parameter for DH ciphers whose strength is measured by its size in bits. The guide referenced above mentions that modern browsers now require a minimum DH group size of 1024. Apparently coreTLS has also adopted this requirement, because this is what I discovered on my server...

The Courier IMAP server has the following line in its config file /etc/courier/imapd-ssl:

TLS_DHPARAMS=/etc/courier/dhparams.pem

When I examine the DH params file, I get the following output:

$ openssl dhparam -in /etc/courier/dhparams.pem -noout -text
    DH Parameters: (768 bit)
        prime:
            00:e0:01:64:54:ec:1c:17:86:f3:02:81:08:44:75:
            67:e6:ab:5c:dd:61:0a:a6:49:1e:23:48:98:29:e9:
            48:36:d3:6b:9c:0f:0f:89:7d:7b:7a:17:1f:03:f3:
            53:4f:cf:d7:4d:a3:8f:00:6e:af:fb:e2:95:e6:45:
            71:c3:8b:74:d2:b4:8c:7c:7d:4b:e1:11:12:eb:7e:
            31:fb:c2:ff:f0:60:3d:07:69:d8:36:19:43:03:00:
            52:43:5b:99:21:5f:c3
        generator: 2 (0x2)

As can be seen, this DH group only has a size of 768 bits, which is definitely not up to modern standards.

To solve the problem I created a new DH group with increased size. I followed the advice in the "Guide to Deploying DH" and created a group with size 2048 bits:

openssl dhparam -out /etc/courier/dhparams-2048-bit.pem 2048

Change permissions of the new file so that they match the original file's permissions:

chmod 600 dhparams-2048-bit.pem
chown daemon:daemon dhparams-2048-bit.pem

I then updated the Courier IMAP config file:

TLS_DHPARAMS=/etc/courier/dhparams-2048-bit.pem

and restarted the server

/etc/init.d/courier-imap restart

After that the Mail app worked fine. Problem solved.

---

PS: Above I said that the coreTLS changes were shipped with iOS 8.4, yet in my question I claim that I have iOS 8 devices that do not have any IMAP connection problems. Both statements are true, but as I now realize I forgot to mention in my question that those iOS 8 devices are still using iOS 8.1.x. Sorry for that.

---

Additional Protocol tests: I played around with the Courier IMAP setting TLS_STARTTLS_PROTOCOL, in order to force the client (iOS 9 Mail app) to a specific TLS protocol version. Strangely enough I discovered that neither TLSv1.2 nor TLSv1.1 seem to work (SSL3 also does not work, but that's OK). The only option that does work is

TLS_STARTTLS_PROTOCOL=TLS1

(this remains true even after I upgraded the DH group size)

I tested the same settings with iOS 8.1.2 - there the Mail application is able to connect with all 3 protocol versions (TLSv1.2, TLSv1.1, TLS1), and even SSL3.

This is really, really weird. Although it's hard to believe, at the moment it seems as if iOS 9 Mail app can only use TLS1. Despite improvements in security on the DH cipher front, not supporting TLSv1.2 would be a bad regression, IMO. It might also be that my server is somehow misconfigured in a way that I don't recognize at the moment. It would therefore be useful if someone else could make similar tests to either confirm or discard my findings.

Answer 2

I have the same problem, but no answer yet. I hope that I am closing in on a solution and I that have pertinent information for you.

I have the iOS 9 problem as you describe with my Courier IMAP, but not with my SASL SMTP AUTH. The cryptography on the 2 servers is similar.

Notably, they both use self signed certificates.

Here are the "openssl s_client" outputs that I am looking at:

Courier IMAP (iOS 9 rejects)
------------
$ openssl s_client -connect 127.0.0.1:143 -starttls imap

No client certificate CA names sent
---
SSL handshake has read 3092 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 4E1B8D0D14AC480A4203C1898A0C75D57DE646547A9F9FC3D47CDFD1926B7C0C
    Session-ID-ctx:
    Master-Key: 4E9D26764E93204AE2C7232E72328C30B38A272B6500D1E524FDA25FEA86EDEBEA22416BECEF78DC8713E5CC5850060D
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - ad ad c0 42 ad 10 be 6b-2b 3e c0 79 79 8c 12 03   ...B...k+>.yy...
    0010 - 74 06 9d ed 1b 72 90 0b-f7 ff f5 f7 1e 2f 6f ec   t....r......./o.
    0020 - a2 ea 8f ac 5a 64 b2 9e-b8 3f 09 56 31 b0 c3 76   ....Zd...?.V1..v
    0030 - c8 b7 83 94 dc 04 81 1a-fe a7 72 4d 50 9c 18 e7   ..........rMP...
    0040 - bd b2 2a cf 0b 29 1c f5-23 75 30 0e fe c9 0a 94   ..*..)..#u0.....
    0050 - 6f c2 e9 ba fa fd b7 f2-33 83 34 91 75 bb 30 4a   o.......3.4.u.0J
    0060 - f1 68 5f 3b 3d f4 12 db-5e 52 82 e7 6f 35 83 c9   .h_;=...^R..o5..
    0070 - 49 39 03 a4 08 8e 60 26-9a a7 5f 18 26 47 f7 ae   I9....`&.._.&G..
    0080 - 07 29 68 7b 5a 5d ad 2f-7d ea 02 f9 00 c8 53 64   .)h{Z]./}.....Sd
    0090 - 1e c9 6e e6 b1 e9 59 83-f2 7a 13 0c 7f c7 44 7a   ..n...Y..z....Dz

    Start Time: 1442747573
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
. OK CAPABILITY completed


SMTP AUTH (iOS 9 accepts)
---------
$ openssl s_client -connect 127.0.0.1:25 -starttls smtp

No client certificate CA names sent
---
SSL handshake has read 1637 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 7B733E6F86EDC34FB2C399E6571263286DB3A3BE94CA04BD0146A9EE3602D6CF
    Session-ID-ctx:
    Master-Key: F72207EFCC8AF316D3BD120C2F11D45FBE9861EF0155CAEFE08395F239541FEE5AEA0D27CDB18B2BB7C5CAF9A8D22832
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - ff 5b be 3e 40 a4 c9 6f-f8 67 00 c9 ac 86 16 27   .[.>@..o.g.....'
    0010 - a9 df 68 57 d1 5c 16 1a-27 e5 2a 74 91 2f b0 28   ..hW.\..'.*t./.(
    0020 - 3f ec 58 2c 0c 23 d9 cb-8b 03 c5 7d 97 de 96 c7   ?.X,.#.....}....
    0030 - fb 25 47 0d b8 7b 5a 45-0c 55 8e 7c 6d 2e 12 76   .%G..{ZE.U.|m..v
    0040 - 8c 2b 1f 2b 27 3f d6 98-fd 23 3f 26 07 de f5 3e   .+.+'?...#?&...>
    0050 - be e7 ed 08 3d 0d b9 d3-6d a0 6d 25 2f cf b1 65   ....=...m.m%/..e
    0060 - e1 36 f2 78 1d f4 36 4f-f4 e5 67 a1 16 e7 22 4c   .6.x..6O..g..."L
    0070 - c1 80 59 dc 58 72 16 15-73 73 8d 9f ef 67 bb 37   ..Y.Xr..ss...g.7
    0080 - db a8 24 32 ee ce 5e 67-c1 8a 94 11 5c 3c b0 ff   ..$2..^g....\<..
    0090 - 3a 73 6a bf 77 07 94 d4-06 6c 27 00 9d 3f 61 4e   :sj.w....l'..?aN

    Start Time: 1442747626
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
250 DSN

So now I am looking into the difference between "ECDHE" and "DHE", and whether the 4096- versus 2048-bit server public keys make a difference.

I am just assuming that Apple is holding STARTTLS for both SMTP and IMAP to the same standards...

Answer 3

Mail was working fine in iOS 9.1 until I changed the "alert" in Notifications to "alert" today. Then I got a message saying something like "Cannot get Mail" and that I was using the wrong sign in info. (Sorry I don't recall the exact wording of the message.)I tried it twice and got the same message both times, but I immediately remembered what I had changed in "Settings" earlier today so I went back to Settings>Notifications>Notifications Style>Mail>Alert Style and then I selected "None". When I went back to my Mail app it worked fine again. (I use GMail.)

Answer 4

we had the same problem in our company. We have nearly the same setup Debian, Courier IMAP and IOS9. For us it resolved itself when we used the port 143 for the ssl imap connection.