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.
  • I think this problem also applies to some of the big mail services. My wife, for example, is seeing "Cannot get mail" for imap.gmail.com when she tries to access Gmail via the Mail app. Oddly she only gets the error while using the wi-fi at her work. I've found similar reports from others using Gmail, Yahoo, etc. Following the steps listed in the following link didn't help: support.apple.com/en-us/HT203330
    – azsromej
    Sep 23, 2015 at 11:16
  • Great quality analysis! Was your test with TLS 1.2 successful?
    – dan
    Sep 24, 2015 at 14:38
  • @danielAzuelos As I wrote I made a test connection with openssl s_client to verify that the server has TLS 1.2 capability, and the result of that test was positive. If that's not what you mean, can you be more specific?
    – herzbube
    Sep 25, 2015 at 5:42
  • I clearly understood you verified this version with openssl. I also clearly understood you need to support TLSv1 for MacOS X 10.10.3 . What wasn't clear (for me) is if iOS9 is still failing in the context TLSv1.2 only. I mean is iOS9 closing the compatibility with TLSv1, i.e. does iOS9 implement: "If the server has this capability then I refuse to talk to it!"?.
    – dan
    Sep 25, 2015 at 5:51
  • @danielAzuelos I would hope not. I have not made any attempt to debug a specific connection made from the iPhone to the server (simple network sniffing is out the window because of encryption), so I can only speculate. But as I wrote, my older devices with iOS 8 do work, and I cannot imagine that iOS 9 has suddenly dropped support for TLS 1.2. I also cannot imagine that iOS 9 was shipped with such a huge bug as a general lack of TLS 1.2 support. It is far more likely that the CAcert certificates are somehow involved.
    – herzbube
    Sep 25, 2015 at 6:09

4 Answers 4


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:


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)
        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:


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


(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.

  • I would suggest chmod 600 /etc/courier/dhparams…chmod 400 /etc/courier/dhparams…. (missing return) High level technical answer :) !
    – dan
    Sep 28, 2015 at 13:51
  • @danielAzuelos You are right, 400 is more secure. I believe it's 600 on my machine because there is supposed to be a cron job that generates a new dhparams file from time to time. Google for mkdhparams to read more. I assume anyone who is reading this answer will be able to figure out the correct permissions (esp. owner/group) for his or her system type.
    – herzbube
    Sep 28, 2015 at 19:28

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 -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
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 4E1B8D0D14AC480A4203C1898A0C75D57DE646547A9F9FC3D47CDFD1926B7C0C
    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 -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
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 7B733E6F86EDC34FB2C399E6571263286DB3A3BE94CA04BD0146A9EE3602D6CF
    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...

  • 1
    See: security.stackexchange.com/a/61723/9792 .
    – dan
    Sep 25, 2015 at 6:01
  • I found out that in my case I have to disable ephemeral ciphers. I also found out that, strangely, iOS 9 seems to support only TLS1 (see my answer). It would be great if you could make a few protocol version tests to either confirm or discard my findings.
    – herzbube
    Sep 26, 2015 at 17:21
  • Revised my answer once more with the final solution - you probably have to update /etc/courier/dhparams.pem.
    – herzbube
    Sep 26, 2015 at 20:56

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.)


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.

  • 1
    As written, @herzbube is using standard port 143.
    – dan
    Sep 24, 2015 at 14:38
  • standard port for imaps = imap/ssl is 993
    – Sebastian
    Oct 2, 2015 at 8:03
  • standard port for imap STARTTLS is 143
    – Sebastian
    Oct 2, 2015 at 8:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .