Tls клиент ошибка 10013

Работаю в организации где несколько десятков компьютеров. Только на считанных компьютерах установлен КриптоПро CSP для соответствующих целей. Чтобы не плодить ассортимент браузеров, да и самому так легче, всем устанавливаю Chromium-Gost, так как считаю его таким же как и Chromium, но с дополнительным функционалом по ГОСТ. Все в организации пользуются, всё устраивает.
Недавно решил сначала сам опробовать более новую версию. Начинал с какой то 105.0.5195…. Увидел ошибки в Просмотре событий. Решил не торопиться. Перечитал все сообщения на форуме по Chromium-Gost. Ни у кого похожего не обнаружил. Терпеливо пробовал все последующие версии по 106.0.5249.103. В своей работе КриптоПро CSP регулярно не использую, хотя основная ОС у меня Win7x32 Pro с установленным КриптоПро CSP 5.0.11455.
Да, последний Chromium-Gos работает в обычном применении, не смотря на ошибки в системном журнале. В связке с КриптоПро CSP на соответствующих сайтах не пробовал.
Ладно. Не горит. Спасибо.

Источник

Remove From My Forums

Общие обсуждения
Добрый день!

Ошибка появляется после неудачной попытки подключения по rdp к виртуальной машине с системой win7

стала появляется несколько дней назад.

скрин во вложенииИзображение

Имя журнала:   System
Источник:      Schannel
Дата:          01.03.2017 9:26:57
Код события:   36871
Категория задачи:Отсутствует
Уровень:       Ошибка
Ключевые слова:
Пользователь: СИСТЕМА
Компьютер:     pc
Описание:
Произошла неустранимая ошибка при создании учетных данных TLS client. Внутреннее состояние ошибки: 10013.
Xml события:
<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>
   <System>
     <Provider Name=»Schannel» Guid=»{1F678132-5938-4686-9FDC-C8FF68F15C85}» />
     <EventID>36871</EventID>
     <Version>0</Version>
     <Level>2</Level>
     <Task>0</Task>
     <Opcode>0</Opcode>
     <Keywords>0x8000000000000000</Keywords>
     <TimeCreated SystemTime=»2017-03-01T02:26:57.367568400Z» />
     <EventRecordID>7155</EventRecordID>
     <Correlation ActivityID=»{FDFB1665-922F-0003-6A16-FBFD2F92D201}» />
     <Execution ProcessID=»976″ ThreadID=»1172″ />
     <Channel>System</Channel>
     <Computer>pc</Computer>
     <Security UserID=»S-1-5-18″ />
   </System>
   <EventData>
     <Data Name=»Type»>client</Data>
     <Data Name=»ErrorState»>10013</Data>
   </EventData>
</Event>
- Изменено
  
  1 марта 2017 г. 9:36
- Изменен тип
  Anton Sashev Ivanov
  10 марта 2017 г. 10:47
  Обсуждение

Источник

You may run into “Schannel – The internal error state is 10013” message if your website fails establishing TLS connection. That is to say, here is the error message you will see in Event Viewer:

Info – Schannel – Creating an SSL server credential.

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

Looking for a way to fix “SChannel error state is 960”? Check this post out.

How to solve “The internal error state is 10013” issue

Follow the steps below to solve this issue. If no more 10013 errors logged after performing these instructions, please make sure that all other applications and services you use in the server are working as expected.

Correct file permissions

Correct the permissions on the c:ProgramDataMicrosoftCryptoRSAMachineKeys folder:

Everyone Access: Special Applies to: This folder only
Network Service Access: Read & Execute Applies to: This folder, subfolders and files
Administrators Access: Full Control Applies to: This folder, subfolder and files
System Access: Full control Applies to: This folder, subfolder and Files
IUSR Access: Full Control Applies to: This folder, subfolder and files

The internal error state is 10013

After these changes, restart the server. The 10013 errors should dissappear. However, If you still see “Schannel 10013” errors in EventViewer, try the next solution (keep the changes you made in Step 1).

Enable “FIPS compliant algorithms for encryption”

Important!!! Even if this setting solves the problem for your application, it may break other applications in the same server! Please test all applications after performing these steps. Enabling “FIPS compliant algorithms” means disabling SSL 2.0/3.0 and forcing TLS 1.0+. A good reading about this setting: Why You Shouldn’t Enable “FIPS-compliant” Encryption on Windows

Go to “Control Panel“.
Click “Administrative Tools“
Double click “Local Security Policy“
In “Local Security Settings“, expand “Local Policies“. Then click “Security Options“
Double click “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”
Select “Enabled“
Click “OK“
Run gpupdate /force

The internal error state is 10013

In conclusion, the two methods above should solve the issue. As mentioned above, please make sure all services work expected after these changes.

Source

Источник

If you have disabled the deprecated server and client protocols TLS 1.0 and TLS 1.1 on your Windows Server as further down for security reasons.

And after that you will see a bunch of error messages as in the title of this post like this.

You have to add the following registry DWORD value like follows.

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions
HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319
“SystemDefaultTlsVersions”=dword:00000001

This registry key has a value of type DWORD. A value of 1 causes your app to allow the operating system to choose the protocol. A value of 0 causes your app to use protocols picked by the .NET Framework.

If your app targets .NET Framework 4.7 or later versions, this key defaults to a value of 1. That’s a secure default that we recommend. If your app targets .NET Framework 4.6.1 or earlier versions, the key defaults to 0. In that case, you should explicitly set its value to 1.

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded. .NET Framework applications should use the TLS version the operating system (OS) supports.

So in case of our error messages, .NET Framework was trying to use one of the disabled TLS 1.0 or TLS 1.1 client protocols. Now after setting SystemDefaultTlsVersions to 1, the operating system is now choosing the right and available protocol instead the .NET Framework itself.

This change is for any version of .NET 4 and 64 Bit Applications.

For versions before .NET 4 you need to add the value in HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727

After a reboot the error messages should stay out and disappear.

For 32 Bit Applications and .Net 4 and above you need to add the value in HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319 resp. v2.0.50727 for versions before .Net 4.

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions
The following .REG file sets the registry keys and their variants to their most safe values:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Links

Источник

Remove From My Forums

Question
- Edited by
  
  Wednesday, November 28, 2018 12:10 PM
  enable hyperlinks

Answers

Hi,

To enable TLS 1.2 on Exchange server, first we need to ensure that your Exchange server is ready for this:

Exchange Server 2016
Install Cumulative Update (CU) 8 in production for TLS 1.2 support and be ready to upgrade to CU9 after its release if you need to disable TLS 1.0 and TLS 1.1.
Install the newest version of .NET and associated patches supported by your CU (currently 4.7.1).

Windows Server 2016
TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP.
Ensure you have installed the most recent Monthly Quality Update along with any other offered Windows updates.

Then make sure you have enabled TLS 1.2 for Schannel and for .NET, disable TLS 1.0 and 1.1 in Schannel, follow the steps described in the articles below:

Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1

Hope it helps.

Regards,

Manu Meng

Please remember to
mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact
tnsf@microsoft.com.

Click
here to learn more. Visit the dedicated

forum to share, explore and
talk to experts about Microsoft Teams.
- Edited by
  Manu Meng
  Thursday, November 29, 2018 8:58 AM
- Proposed as answer by
  Manu Meng
  Friday, November 30, 2018 3:14 PM
- Marked as answer by
  TomTan
  Wednesday, December 5, 2018 12:07 AM