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
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
with disabled TLS 1.0, TLS 1.1 to have better security or just
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
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:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
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.
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
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
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:
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.
MQ Explorer is a Java based application so does not rely on the GSKit version but instead on Java's underlying JSSE implementation.
In general a non-java applications using MQ v7.0.1.14 could utilize TLS1.2 cipherspecs if they have installed GSKit 8 and have specified the AltGSKit=YES
setting in the SSL
stanza of the mqclient.ini
, this does not apply however to Java applications like MQ Explorer.
Supporting this is the following info in APAR IT00326: WMQ V7.X EXPLORER IS NOT ABLE TO CONFIGURE A CIPHER SPECIFICATION SUPPORTED BY GSKIT V8 FOR A V7.0.1 QUEUE MANAGER talking about using MQ Explorer to configure channels on a 7.0.1.4 or later queue manager that has the AltGSKit=YES
setting in place in the SSL
stanza of the qm.ini
. (bolded the key info below):
The WebSphere MQ Explorer has been updated to allow the configuration
of the following CipherSpecs on a channel definition when connected to
a version 7.0.1 queue manager:
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256
These CipherSpecs require GSKit 8 to be configured on the queue
manager. Attempting to set these CipherSpecs for a channel definition
on a version 7.0.1 queue manager which is using GSKit 7 will cause MQ
Explorer to display an AMQ4126 error.
It should be noted that WebSphere MQ Explorer version 7.0.1 does not
support the use of these three CipherSpecs for its communications with
the queue manager over a ServerConnection channel.
The IBM MQ Classes for Java does not support SHA2 cipherspecs until MQ v7.1.
I would recommend you download the standalone MQ v9.1 Explorer SupportPac, you can find it here: MS0T: IBM MQ Explorer.
The versions listed below are all End of Support at this time and v8 is going to be end of support on April 30th 2020:
V7.0 EOS: September 30 2015
V7.1 EOS: April 30 2017
V7.5 EOS: April 30 2018
V8.0 EOS: April 30 2020
Best Answer
(1) That webpage is dated 2014; unlimited policy is no longer used at all for Oracle Java versions after 2017, and before that (which e.g. 7u80 was) it only mattered for symmetric encryption over 128 bits which here would affect only the AES256 suites not the AES128 ones. (It was never applicable to OpenJDK, although OpenJDK below 8 was/is mostly available only on major Linux distros like RedHat and Debian that could allocate staff for building and packaging; you don't say which you are using.)
(2) Java (1.)7 does support the CBC ciphersuites you show (not the GCM ones, and for Oracle versions below 7u171 the AES256 ones do require unlimited policy) but ONLY when TLS1.2 is used (these ciphersuites did not exist in lower version protocols) and by default j7 disables TLS1.2 (and 1.1) clientside.
If you are explicitly doing the connection to this API with
HttpsURLConnection
(e.g.new URL("https://something").openConnection()
) you can tweak the socketfactory to useSSLContext.getInstance("TLSv1.2")
and/or explicitlysetEnabledProtocols
on the socket. If you are using other middleware e.g. Apache HttpComponents there are usually similar methods but they vary in detail; you would need to show us the code, and that would probably belong on StackOverflow not here. If you are calling a library that does the connection internally, it may have options, or not. For all or many calling methods, you can alter defaults likeSSLContext.setDefault()
orHttpsURLConnection.setDefaultSSLSocketFacfory()
if these defaults are not overridden in the relevant code and making a global change like that doesn't cause trouble for anything else running in your same JVM.Alternatively (and more on topic!) if you have a sufficiently recent j7 update, I'm pretty sure they backported the system property
jdk.tls.client.protocols
which you could set to e.g.TLSv1,TLSv1.1,TLSv1.2
to change the default with no code change (but again only if not overridden and not harming anything else). I don't recall exactly when this was but definitely after 7u80, so you would have it only with paid Oracle support or OpenJDK supported by somebody else with or without pay. That's easy to try and may work.