Problem: Our mobile app can no longer establish a secure connection to our web-service since iOS 9 now uses ATS.

Background: iOS 9 introduces App Transport Security

Server Setup: Windows Server 2008 R2 SP1 (VM) IIS 7.5, SSL certs from digicert. Windows firewall off.

Key RSA 2048 bits (e 65537)

Issuer DigiCert SHA2 Secure Server CA

Signature algorithm SHA512withRSA

These are the App Transport Security requirements:

The server must support at least Transport Layer Security (TLS) protocol version 1.2. Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.) Certificates must be signed using a SHA256 or better signature hash algorithm, with either a 2048 bit or greater RSA key or a 256 bit or greater Elliptic-Curve (ECC) key. Invalid certificates result in a hard failure and no connection. These are the accepted ciphers:


What has been tried:

  1. Adding exceptions in the mobile app to allow our domain works, but I do not want to go with this unsecured method, I want to fix our SSL.
  2. Used IIS Crypto to use 'best practice', tried 'pci', and custom setups. Even tried modifying the crypto suite to just the list above, and reordering. After each attempt, server is rebooted, and and SSL Labs was ran (after clearing cache). I was successful at going from a F rating to an A, and even A-, but this only resulted in iOS 8 and 9 being unable to establish secure connections. (NSURLErrorDomain Code=-1200 and _kCFStreamErrorCodeKey=-9806) enter image description here
  3. Restored VM and tried a powershell script Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2 I even made a second attempt where I edited out cyphers from the power script to a minimal list of what is required.

Results: Always similar, ratings of A or A-. iOS8 and iOS9 can't negotiate secure connection. Handshake Simulation results in "Protocol or cipher suite mismatch" for Safari and iOS products. enter image description here enter image description here

UPDATE After working with Apple support, we did some packet trace capture:

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

The first three packets are the classic SYN - SYN-ACK - ACK three way handshake that sets up the TCP connection. The fourth packet is iOS sending your server a TLS Client Hello message, the first step in setting up a TLS connection over that TCP connection. I’ve pulled apart this message and it looks reasonable enough. In the fifth packet the server simply drops the connection (by sending a RST).

Does anyone know why IIS 7.5 would be doing a RST?

  • I have contacted Digicert again, we changed out my RSA cert for a ECC cert. I now have iOS 9 working securely, but now iOS 8 will not connect under several configuration attempts.
    – RobDigital
    Sep 30, 2015 at 14:13

3 Answers 3


The question is old, but it will be found during searching. I spent some time to find solution to the same problem. Thus I decide to write the answer to share my results with others.

Short answer: you should not use IIS Crypto to specify the order of Cipher Suites. I recommend you to click on "Defaults" buttons to remove previously set order and then use Group Policy ("Computer Configuration" \ "Administrative Templates" \ "Network" \ "SSL Configuration Settings") to configure Cipher Suites via local policy.

The reason of the error "protocol or cipher suite mismatch" can be one from below:

  • your server support some "bad cipher suite"
  • your server don't support some cipher suite, which MUST be supported corresponds to TLS specification.
  • your server supports HTTP/2 and it has some protocols from the the black list above the other protocols, which are not in the list. It's typically enough the change the order of the cipher suites to fix the problem.

The exact black list could be different on different systems. You can find in Internet some blacklist. For example, Appendix A of RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP/2)) contains one list. The cipher suites are TLS_RSA_WITH_AES_128_CBC_SHA for TLS 1.2 (see here) and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.3 (see here). The TLS_ECDHE_ECDSA_* are important only is you use certificate with elliptic curves. Other very good cipher suite TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is not yet implemented by Microsoft. Additionally you can consider to add at least TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA to support connection from old systems and TLS_RSA_WITH_AES_128_CBC_SHA to support very old systems (Android 2.3.7, , Java 6u45, OpenSSL 0.9.8y) and TLS_RSA_WITH_3DES_EDE_CBC_SHA only if you need support IE 8 / XP. Thus you can use today, for example


with disabled TLS 1.0, TLS 1.1 to have better security or just


if you need to have good security and the best performance.

You can set the following short set of cipher suite for example to solve your problem:


Below I includes an example of configuration on Windows 10. I configured IIS 10 to have A+ rating from Qualys SSL Labs with RSA 2048 key and free SSL certificate from Let's Encrypt.

enter image description here

I disabled DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, Triple DES 168/168, NULL, MD5, Multi-Protocol Unified Hello, PCT 1.0, SSL 2.0, SSL 3.0 and TLS 1.0/1.1 manually in the registry (see KB245030). I disabled TLS 1.0 and TLS 1.1 protocols only because TLS_FALLBACK_SCSV (Downgrade attack) can't be prevented in IIS till now, which makes impossible to get A+ rating of www.ssllabs.com. I see it as an disadvantage, but TLS 1.2 is supported currently very wide. By the way you can use DisabledByDefault: 1, but Enabled: 1 for TLS 1.0 and TLS 1.1. It could be helpful if you would run SQL Server 2008/2012 on the computer. The web server will not use TLS 1.0 and TLS 1.1, but SQL Server do use.

The most important step, which get many my time and which is your main problem was configuration of the the Cipher Suites. I made it using gpedit.msc. I chosen "Computer Configuration" \ "Administrative Templates" \ "Network" \ "SSL Configuration Settings" and configured "SSL Cipher Suite Order" value to the following


The above order could be not optimal and I'm not sure, that all above protocols are supported on IIS 7.5 (I used IIS 10.0 from Windows 10). Nevertheless I'm sure that your problem is related with the list of the Cipher Suite, because I had exactly the same problem like you described during my experiments with the list of Cipher Suite.

In any way, after configure the above settings in Group Polity and rebooting the computer (gpupdate /force /target:computer was not enough in my tests) I get A+ ratings and the following list of testing results of the "Handshake Simulation" part:

enter image description here enter image description here enter image description here enter image description here

One can see that iOS is successfuly supported for the following clients:

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

The clients which don't supports TLS 1.2 seems for me now not so important and I think that the above configuration is a good compromise between the support of legacy clients and the usage of safe protocols.

  • +1 for watch yourself with IISCrypto, i have seen it incorrectly setting 112 bit 3DES disable keys on windows... apprehensive when using this tool.
    – felickz
    Sep 14, 2016 at 11:20

If your IIS Crypto image is recent keep the settings as they are but enable SHA, Diffie-Hellman, and PKCS. This will get you the A rating but allow iOS 8 and lower to connect.

  • I enabled SHA, Diffie-Hellman, and PKCS as you recommended. Restarted server and redid the ssl labs test. No luck. still cant connect with ios 9, and still getting "protocol or cipher suite mismatch" on SSL Labs.
    – RobDigital
    Sep 29, 2015 at 17:33

I struggled with this for a few days. In particular I was connecting from an iOS app using Xamarin Forms PCL to connect to a ASP.NET Web Api 2 rest service with OAuth2 Bearer Token authentication.

What worked for me in the end was to use IIS Crypto's Best practices. Then edit the registry key which it set for the cipher suite order:


I had success with the following value:


The last one was found by using Charles Proxy, which negotiated TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 automatically. The thing that lead me to this was that the connections were succeeding with Charles Proxy on (with simulator certificates installed), but failed otherwise. Adding the suite it used in the negotiation did the trick. It appears(?) that the proxy was renegotiating with my rest service with something that was supported by my server, but not the iOS client.

Note many of the cipher suites were obtained from ssllabs's specification of preferred suites for various iOS/OSX devices. The value above should handshake with everything but IE 6 on XP according to ssllabs, with an A rating.

You must log in to answer this question.

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