To totally unlock this section you need to Log-in
You may run into Schannel – The internal error state is 10013 message if your website fails establishing TLS connection and usually this could occur using Internet Explorer 11 to connect to modern websites or portals that are using TLS 1.2 or better protocols for encryption.
That is to say, here is the error message you will see in Event Viewer:
|Error – Schannel – A fatal error occurred while creating an SSL client credential. The internal error state is 10013|
This error is logged when there are Schannel Security Service Provider (SSP) related issues. For example, web server might be trying to use an encryption algorithm or protocol (or cipher suite, like the old RC4) that were actually disabled.
Similarly, incompatible machine keys or machine keys with insufficient file permissions may be other possible reasons of "The internal error state is 10013" error message and this could lead to multiple error entries of this kind into the Event Viewer on the machine from which we are trying to connect, for each try to connect to the website.
To solve "The internal error state is 10013" issue we will have to follow some simple steps: if after this modifications there will be no more 10013 errors logged, then you will have to make sure that all other applications and services (especially web services) you have configured, installed and enabled on your server are working as expected.
The first Method: Correct file permissions
Correct the permissions on the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder:
- Everyone: Special and Applies to: This folder only.
- Network Service: Read & Execute and Applies to: This folder, subfolders and files.
- Administrators: Full Control and Applies to: This folder, subfolder and files.
- SYSTEM: Full control and Applies to: This folder, subfolder and Files.
- IUSR (For IIS Anonymous User): Full Control and Applies to: This folder, subfolder and files.
For the Everyone Special permissions the following is the detail of the specific configuration:
The following screenshot will show the complete Security tab specification for the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder:
Once you have completed the above permission changes or integration you will have to restart the server. At this point, if the issue was generated by permission changes to the MachineKeys folder then the 10013 eventserrors should dissappear. However, If you still see Schannel 10013 errors in the Event Viewer, then it means that there was no permission issues on the core MachineKeys folder, so we will go forward by enabling a local system policy that will force modern security protocols for encryption for several services (however, keep the changes you made until now).
The second Method: Enable FIPS compliant algorithms
Enabling the FIPS compliant algorithms on a server could have several implications on some system implementations; however, in some cases, like this one, this policy should be enabled to let Internet Explorer 11 to properly reach and display TLS 1.2 websites and portals (this policy will not impact on other common browsers, like Google Chrome or Opera).
Actually, with this method we are going to enable on the system the Federal Information Processing Standard (FIPS) 140, that is a security implementation that is designed for certifying cryptographic software. Windows implements these certified algorithms to meet the requirements and standards for cryptographic modules for use by departments and agencies of the United States federal government.
Now we can see which changes are done to the system by applying this policy (Group Policy):
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
Encrypting File System (EFS)
For the EFS service, this policy setting supports the 3DES and Advanced Encryption Standard (AES) encryption algorithms for encrypting file data supported by the NTFS file system. To encrypt file data, by default EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003, Windows Vista, and later, and it uses a DESX algorithm in Windows XP.
Remote Desktop Services (RDS)
If you're using Remote Desktop Services, this policy setting should only be enabled if the 3DES encryption algorithm is supported.
For BitLocker, this policy setting needs to be enabled before any encryption key is generated. Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the creation or use of recovery passwords on these systems, so recovery keys should be used instead. Additionally, if a data drive is password-protected, it can be accessed by a FIPS-compliant computer after the password is supplied, but the drive will be read-only.
Turning back to the specific issue, we will have to follow these steps:
- Go to Control Panel.
- Click Administrative Tools.
- Double click Local Security Policy (or just open gpedit.msc from Run).
- Once opened Local Security Settings, expand the Local Policies branch and finally click Security Options.
- Double click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing to set the value of this property.
- Select Enabled.
- Click OK.
- Run gpupdate /force in a Command Prompt, with administrative privilege.
Take note that the change to this policy become effective without a device restart when they are saved locally or distributed through Group Policy, so after you have issued the gpupdate /force command you will be good to go and ready to reload Internet Explorer 11 to see if the issue has been solved. Even in Event Viewer you should not see anymore SChannel 10013 errors related to TLS.
NOTE: we strongly recommend that you implement this change on a beta or staging server to make sure your application is not malfunctioning due to this change. Once you are confident that your application is working fine after this change then you can implement it on your production server.
Checking IE11 Cryptographic Protocols
Finally, in Internet Explorer 11, make sure you have enabled only TLS protocols (no SSL2 and SSL3, they are insecure and deprecated).
So, if after the enable of the FIPS algorithms you are getting the following error using Internet Explorer 11...
|This page can’t be displayed – Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://www.google.com again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.|
...you will have to check (and enable if disabled) the ciphers in Tools > Internet Options > Advanced, in the Settings scrollbox, looking under Security, you will see cipher suites TLS 1.0, 1.1, and 1.2 (you will have to enable at least TLS 1.1 and TLS 1.2) that should be selected by default in Internet Explorer 11.
In alternative, you could just reset IE11 to default settings by going back to Tools > Internet Options > Advanced, under Reset Internet Explorer settings, and clicking on Reset. In the Reset Internet Explorer settings window, check the box Delete personal settings, and click on Reset.
Once done, simply restart IE11 and try browsing again.
Checking TLS 1.2 if Enabled
On older Windows Server platforms, like Server 2008 and Server 2008 R2, we recommends checking and enabling and using the TLS 1.2 protocol on your server.
By default, Windows Server 2008 and 2008 R2 does not have this feature enabled.
IMPORTANT NOTE: the internal error state of SChannel 10013 can be seen also if the system, even with FIPS 140 enabled by local policy (as in the second method shown above), is trying to reach a remote website that is still using a TLS 1.0 certificate but the TLS 1.0 on the local system, in the Windows Registry, has, for the TLS 1.0 protocol, the key DisabledByDefault has value 1 and Enabled has value 0 (so it is basically disabled system-wide, even if in Internet Explorer, in Internet Options, the TLS 1.0 is actually enabled).
Now, to check the TLS 1.2 protocol is correctly enabled (the same procedure can be followed also for TLS 1.0 and TLS 1.1) you will have to follow the steps below:
- Start the registry editor by clicking on Start and Run. Type in "regedit" into the Run field (without quotations).
- Highlight Computer at the top of the registry tree. Backup the registry first by clicking on File and then on Export.
- Select a file location to save the registry file.
NOTE: You will be editing the registry. This could have detrimental effects on your computer if done incorrectly, so it is strongly advised to make a backup.
Browse to the following registry key:
Right click on the Protocols folder and select New and then Key from the drop-down menu. This will create new folder. Rename this folder to TLS 1.2.
IMPORTANT NOTE: do this only if the TLS 1.2 is not already present/created.
Right click on the TLS 1.2 key and add two new keys underneath it.
Rename the two new keys as:
- Right click on the Client key and select New and then DWORD (32-bit) Value from the drop-down list.
- Rename the DWORD to DisabledByDefault.
- Right-click the name DisabledByDefault and select Modify... from the drop-down menu.
- Ensure that the Value data field is set to 0 and the Base is Hexadecimal. Click on OK.
- Create another DWORD for the Client key as you did in the previous step.
- Rename this second DWORD to Enabled.
- Right-click the name Enabled and select Modify... from the drop-down menu.
- Ensure that the Value data field is set to 1 and the Base is Hexadecimal. Click on OK.
Repeat necessary steps for the Server key, by creating two DWORDs, DisabledByDefault and Enabled, and their values underneath the Server key.
Reboot the server. Your server should now support TLS 1.2 (remember to update Server 2008 and 2008 R2 to latest updates before creating or checking these registry keys).
NOTE: This article cannot be used on a Windows Server 2003 (IIS 6). Windows Server 2003 does not support the TLS 1.2 protocol.
If you make a mistake or something just isn't right, you can revert back to your previous registry settings by opening the Registry Editor and importing the backup you made in previous step.