Here are the most common questions asked about IIS Crypto. If you have any other questions, feel free to contact us.

There are a couple reasons. First, make sure that you have clicked the Apply button and rebooted your server. The other common reason we have seen is that there is a proxy or load balancer in front of your server intercepting TLS traffic. Usually those systems are hardware based running some form of OpenSSL. Unfortunately IIS Crypto has no way to configure them. If you or your network administrator cannot or do not want to bypass those systems, there is not much else you can do other than making sure they are setup securely.

When IIS Crypto is first run on a server that has not be setup, the checkboxes will be grey. This means that no settings has been specified and the defaults for the operating system will be used. When a checkbox is checked or unchecked, it means that the setting has explicitly been set and will be saved to the operating system when the Apply button is clicked.

Yes. Most of the settings that IIS Crypto updates are system wide and unfortunately that requires a reboot.

Click the templates button and select the Server Defaults template from the drop down box. Click the Apply button and reboot your server.

IIS Crypto 2.0 now includes two templates. The original PCI template and an updated PCI 3.1 template. The original template does not disable TLS 1.0 nor does it reorder any of the cipher suites. The new template disables TLS 1.0 and reorders the cipher suites. If you use the PCI 3.1 template there is a chance that you will break Remote Desktop connections if you are using Windows Server 2008 R2. Please make sure that you have installed TLS 1.1 and 1.2 support for your system.

The PCI counsel has pushed back the date for PCI 3.1 compliance to June 2018.

If you disable TLS 1.0 you will break a lot of user's connections. All versions of Internet Explorer on Windows Vista and older as well as Android versions 4.3 and lower will not be able to connect. For a full list of web browser compatibility click here.

Yes. The default security layer in RDP is set to Negotiate which supports both SSL (TLS 1.0) and the RDP Security Layer. However, if you set the security layer to SSL (TLS 1.0) and disable TLS 1.0 in IIS Crypto you may be unable to connect to RDP if you are using Windows Server 2008 R2. To check your settings, open Remote Desktop Session Host Configuration in Administrative Tools and double click RDP-Tcp under the Connections group. If it is set to SSL (TLS 1.0) and you are running Windows Server 2008 R2 make sure that you have installed TLS 1.1 and 1.2 support.

Network Level Authentication only supports the SSL (TLS 1.0 and above) security layer.

Yes. IIS Crypto 2.0 has a checkbox to set the client registry keys.

Microsoft has renamed most of cipher suites for Windows Server 2016. We list both below.

Windows Server 2016:


Windows Server 2012 R2 and lower:


We follow best practices and prefer ECHDE for the key exchange to enable forward secrecy. We then chose the highest key length followed by the highest hash length.

Currently many clients do not support DSA certificates. As more clients support DSA certificates, we will update the cipher suite order.

While TLS_RSA_WITH_AES_256_GCM_SHA384 and TLS_RSA_WITH_AES_128_GCM_SHA256 were included, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 were not. The latter were not included because Microsoft chose to use weak (1024 bit) Diffie-Hellman parameters. They did this in order to support older Java clients.

Every version of Windows has a different cipher suite order. Depending on what Windows Updates the server has applied, the order can be different even with the same version of Windows. We have documented a full list of cipher suites here.

TLS 1.1 and 1.2 were not introduced until Windows Server 2008 R2. A full list can be found here.

Google Chrome version 41 added a warning stating that your website is using obsolete cryptography if the cipher suite does not support forward secrecy and authenticated encryption (AEAD). The only two cipher suites that support this on Windows using RSA certificates are TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Unfortunately those cipher suites use 1024 bits for their Diffie-Hellman parameters which has long been considered weak. The only way to get rid of this warning is to use DSA certificates or wait until Windows Server 2016 is released. The issue with DSA certificates is that many older clients do not support them. Windows Server 2016 is not going to be released until 2016. At the moment there is nothing we can do about it.

This message has been removed from the latest versions of Chrome.

The logjam exploit is a man-in-the-middle attack that tries to downgrade TLS connections using the Diffie-Hellman key exchange to 512 bits. Using the Best Practices template in IIS Crypto disables all Diffie-Hellman ciphers.

The FREAK attack is a vulnerability that allows HTTPS traffic to be intercepted. It does this but trying to force the server to use old cipher suites that have long been insecure. If you are running Windows Server 2008 and above you will not be vulnerable in the default OS configuration. However, Windows Server 2003 is vulnerable with the default configuration. The Best Practices template in IIS Crypto solves this by removing the affected cipher suites. You do not need to download a new version as these ciphers have been disabled by IIS Crypto since the first version.

Microsoft has issued the security bulletin MS15-031. Additional information can be found here.

Microsoft released a patch on November 11, 2014 to address a vulnerability in SChannel that could allow remote code execution. This patch included 4 new cipher suites for Windows Server versions 2008 through 2012 R2. Previously only Windows Server 2012 R2 had these cipher suites. On November 16, Microsoft updated the advisory stating that they found an issue with the new cipher suites they introduced. If you have applied this patch and are running into connection issues with clients, the work around is to disable the following cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384 and TLS_RSA_WITH_AES_128_GCM_SHA256. You can do this in the latest version of IIS Crypto by unchecking those cipher suites, clicking Apply and rebooting your server. More information can be found here.

On November 18, 2014 Microsoft updated MS14-066 to remove the cipher suites from the default cipher suite list for Windows Server 2008 R2 and Windows Server 2012. Windows Server 2012 R2 does not get the update. If you run into any connection issues, uncheck the listed cipher suites in IIS Crypto.

To enable/disable protocols, ciphers and hashes, IIS Crypto modifies the registry key and child nodes here:


To reorder the cipher suites, it modifies the registry key here:


A more detailed description can be found here.

The BEAST template was removed as RC4 is now considered much weaker than previously was known. Most modern browsers have now fixed the BEAST attack. A good explanation can be found here.