Запускаю Chromium-Gost 106.0.5249.103 и в Просмотре событий вижу 10 ошибок на таких ОС:
Win7x32: Произошла неустранимая ошибка при создании учетных данных SSL client. Внутреннее состояние ошибки: 10013
Win10x64 LTSB: Произошла неустранимая ошибка при создании учетных данных TLS client. Внутреннее состояние ошибки: 10013
Win10x64 LTSC: Произошла неустранимая ошибка при создании учетных данных TLS client. Внутреннее состояние ошибки: 10013
Пробовал запускать Chromium 106.0.5249.103 и Google Chrome 106.0.5249.103. Ошибки не появляются.
В итоге откатился на Chromium-Gost 89.0.4389.128. При его запуске и работе ошибки не появляются.
Вы не указали вашу версию КриптоПро CSP.
Если это воспроизводится на чистой системе, опишите полный порядок действий для достижения ошибки.
На Win7x32 версия КриптоПро CSP 5.0.11455. Остальные ОС без КриптоПро CSP и ошибка возникает сразу после загрузки ОС и запуска Chromium-Gost. Попробовал перебрать версии Chromium-Gost: последняя без ошибки 104.0.5112.102, а с 105.0.5195.102(пререлиз не пробовал) начинается ошибка. Похоже это началось при переходе на msspi 1.65
Остальные ОС без КриптоПро CSP и ошибка возникает сразу после загрузки ОС и запуска Chromium-Gost.
Звучит как троллинг. Без КриптоПро CSP ГОСТ работать не должен.
Или проблема только в том что в событиях Windows ошибки, но в целом все работает без ошибок?
Работаю в организации где несколько десятков компьютеров. Только на считанных компьютерах установлен КриптоПро CSP для соответствующих целей. Чтобы не плодить ассортимент браузеров, да и самому так легче, всем устанавливаю Chromium-Gost, так как считаю его таким же как и Chromium, но с дополнительным функционалом по ГОСТ. Все в организации пользуются, всё устраивает.
Недавно решил сначала сам опробовать более новую версию. Начинал с какой то 105.0.5195…. Увидел ошибки в Просмотре событий. Решил не торопиться. Перечитал все сообщения на форуме по Chromium-Gost. Ни у кого похожего не обнаружил. Терпеливо пробовал все последующие версии по 106.0.5249.103. В своей работе КриптоПро CSP регулярно не использую, хотя основная ОС у меня Win7x32 Pro с установленным КриптоПро CSP 5.0.11455.
Да, последний Chromium-Gos работает в обычном применении, не смотря на ошибки в системном журнале. В связке с КриптоПро CSP на соответствующих сайтах не пробовал.
Ладно. Не горит. Спасибо.
Ошибки связаны с текущей механикой определения поддерживаемых алгоритмов в системе, код был добавлен тут: a2433c8#diff-027517188b3f26e38bfb308623bc719c6c20bc2a1dae28736045aae168c2f60cR113-R132
Это ожидаемые ошибки «простукивания» системного TLS функционала при старте браузера, от чего далее зависит активация тех или иных функций внутри браузера.
Если найдется способ без оставления ошибок в событиях Windows, возьмем на вооружение. Пока так.
deemru
changed the title
Неустранимая ошибка 10013
Ошибки в событиях Windows (неустранимая ошибка 10013)
Oct 12, 2022
Это ожидаемые ошибки «простукивания» системного TLS функционала при старте браузера, от чего далее зависит активация тех или иных функций внутри браузера.
Так вы их «простукивайте» начиная с самых новых по направлению к старым. И если самый новый находится, то на нём и работайте…
Так вы их «простукивайте» начиная с самых новых по направлению к старым. И если самый новый находится, то на нём и работайте…
А если на сервере он не поддерживается?
А если на сервере он не поддерживается?
Ну, разумеется работать на том, который самый новый из поддерживаемых сервером. Имхо, слабая безопасность на сервере встречается реже, чем на клиенте.
Ну, разумеется работать на том, который самый новый из поддерживаемых сервером. Имхо, слабая безопасность на сервере встречается реже, чем на клиенте.
Вероятно вы не обратили внимание, хотя процитировали мой изначальный ответ, что простукивание осуществляется разово «при старте браузера».
Узнать при старте браузера по какими серверами будет ходить пользователь невозможно.
Вероятно вы не обратили внимание, хотя процитировали мой изначальный ответ, что простукивание осуществляется разово «при старте браузера».
Да, признаюсь, не обратил. Тогда, конечно, надо проверять возможность работы всех протоколов. Впрочем, во-первых, в процессе работы пользователь может «включить» или «отключить» возможность работы протоколов, а во-вторых, почему для определения включенных протоколов не используете ключ реестра КомпьютерHKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsSecureProtocols?
Вот тут вроде как описание возможных значений: https://admx.help/?Category=InternetExplorer&Policy=Microsoft.Policies.InternetExplorer::Advanced_SetWinInetProtocols&Language=ru-ru
во-первых, в процессе работы пользователь может «включить» или «отключить» возможность работы протоколов, а во-вторых, почему для определения включенных протоколов не используете ключ реестра
- Всё так. Может. Но жалоб не было.
- Абстракция msspi даёт больше гарантий работы для всех поддерживаемых систем. Разбираться в сочетаниях ключей реестра одной конкретной системы выглядит нецелесообразным.
Если найдется способ без оставления ошибок в событиях Windows, возьмем на вооружение. Пока так.
2. Разбираться в сочетаниях ключей реестра одной конкретной системы выглядит нецелесообразным.
Если найдется способ без оставления ошибок в событиях Windows, возьмем на вооружение. Пока так.
- Разбираться в сочетаниях ключей реестра одной конкретной системы выглядит нецелесообразным.
Да, спасибо за направление, но этот вариант не подходит.
Recently deployed a Windows 2016 Standard Server, with Active Directory and Exchange 2016.
We have disabled SSL 1.0, 2.0 and 3.0 for both Server and Client, and have disabled TLS 1.0 and TLS 1.1.
We are repeatedly getting the following entry in our system log. What is causing this, and how can I fix it.
asked Nov 2, 2018 at 15:52
4
Basically we had to enable TLS 1.2 for .NET 4.x. Making this registry changed worked for me, and stopped the event log filling up with the Schannel error.
More information on the answer can be found here
Linked Info Summary
Enable TLS 1.2 at the system (SCHANNEL) level:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
(equivalent keys are probably also available for other TLS versions)
Tell .NET Framework to use the system TLS versions:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
This may not be desirable for edge cases where .NET Framework 4.x applications need to have different protocols enabled and disabled than the OS does.
TylerH
20.7k65 gold badges73 silver badges98 bronze badges
answered Dec 5, 2018 at 15:36
neildtneildt
5,04210 gold badges55 silver badges103 bronze badges
6
After none of the methods I could find anywhere helped me:
I opened the Event Viewer and searched when this error started to show so often. I used filter set to Error from Schannel source. In my case, this error was happening every now and then but then, on certain date, it started to show every few seconds! I went to Settings -> Apps & features and searched if anything new was installed on this date – and bingo! It was PrivadoVPN. After uninstalling PrivadoVPN, the error stopped to show!
P.S. I’m not saying that specifically PrivadoVPN is problematic. Mybe it is something with my configuration… Just suggesting the method I used to find the root cause of the error in my case.
answered Mar 10, 2022 at 3:34
After making no changes to a production server we began receiving this error. After trying several different things and thinking that perhaps there were DNS issues, restarting IIS fixed the issue (restarting only the site did not fix the issue). It likely won’t work for everyone but if we tried that first it would have saved a lot of time.
answered Jan 20, 2021 at 18:04
Matt LMatt L
411 silver badge5 bronze badges
In my case, the Windows 2016 server where this was happening was hardened for security compliance. As a result, only specific cipher suites were allowed. This was causing an incompatibility when making HTTPS connections to highly secure endpoints (like Apple Push Notifications API aka APNS)
To fix the issue, I downloaded IIS Crypto and clicked on the Cipher Suites button on the left, to display the list of enabled/disabled cipher suites, and then clicked the «Best Practices» button and rebooted the server. Problem fixed.
answered Jul 21, 2021 at 12:10
blizzblizz
4,0826 gold badges36 silver badges58 bronze badges
I encountered this while rebuilding a server that was moving from Server 2012R2 to DataCenter 2019. It was making me crazy because I could debug it from Visual Studio just fine but IIS immediately returned a 500 error.
In my case, we have several .NET 3.5 and .NET 4.5 applications commingled on the same server and when I created the application for one of the 4.5 applications I had pointed it to the 2.0 App Pool.
Repointing it to the 4.0 App Pool resolved the issue.
answered Oct 7, 2022 at 20:51
I found this here: https://port135.com/schannel-the-internal-error-state-is-10013-solved/
«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 disappear.»
answered Nov 16, 2020 at 23:21
2
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
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
In conclusion, the two methods above should solve the issue. As mentioned above, please make sure all services work expected after these changes.
Source
- Remove From My Forums
-
Question
-
Recently deployed a Windows 2016 Standard Server, with Active Directory and Exchange 2016.
We have disabled SSL 1.0, 2.0 and 3.0 for both Server and Client, and have disabled TLS 1.0 and TLS 1.1.
We are repeatedly getting the following entry in our system log. What is causing this, and how can I fix it.
Answers
-
The issue and solution isn’t about exchange server, its a .Net Framework issue. Although the article is about Exchange Server its the part about configuring .Net that you need.
In short you need to make registry change:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
«SystemDefaultTlsVersions»=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]
«SystemDefaultTlsVersions»=dword:00000001This change is for any version of .Net 4
If you need to the same with earlier versions of .Net it is:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]
«SystemDefaultTlsVersions»=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv2.0.50727]
«SystemDefaultTlsVersions»=dword:00000001The registry change enables TLS 1.2 for .Net
-
Proposed as answer by
Friday, November 8, 2019 7:05 PM
-
Marked as answer by
Hamid Sadeghpour SalehMVP
Friday, January 31, 2020 12:19 PM
-
Proposed as answer by
Если вы получаете фатальную ошибку при создании ошибки учетных данных клиента TLS в средстве просмотра событий, вы можете устранить проблему с помощью этого руководства. Эта ошибка возникает как в Windows 11, так и в Windows 10. Однако решения одинаковы независимо от операционной системы.
Все сообщение об ошибке говорит:
Неустранимая ошибка при создании учетных данных клиента TLS. Состояние внутренней ошибки — 10013.
Эта ошибка появляется на вашем компьютере, если у вас не включены TLS 1.0 и TLS 1.1. Хотя некоторым программам может не потребоваться TLS 1.2 или TLS 1.3, некоторым старым программам они могут понадобиться для подключения к Интернету. Если это произойдет, вы можете избавиться от этой ошибки с помощью этих решений.
Исправить Неустранимая ошибка при создании учетных данных клиента TLS. Состояние внутренней ошибки — 10013. при создании ошибки учетных данных клиента TLS выполните следующие действия:
- Включите TLS 1.0/1.1 с помощью свойств Интернета.
- Изменить значения в реестре
Чтобы узнать больше об этих шагах, продолжайте читать.
1]Включите TLS 1.0/1.1, используя свойства Интернета.
Как было сказано ранее, вам необходимо включить или включить TLS 1.0 и TLS 1.1 на вашем компьютере, чтобы решить эту проблему. Поскольку они не включены по умолчанию в Windows 11 и Windows 10, вам необходимо сделать это вручную. Для этого вы можете воспользоваться помощью Интернет-свойства панель. Чтобы включить TLS 1.0/1.1 в Windows 11/10, сделайте следующее:
- Найдите интернет-свойства в поле поиска на панели задач.
- Нажмите на отдельный результат поиска.
- Перейдите на вкладку «Дополнительно».
- Найдите TLS 1.0 и TLS 1.1.
- Отметьте оба флажка.
- Нажмите кнопку ОК.
Возможно, вам придется перезагрузить компьютер, чтобы выполнить работу. После этого вы не найдете вышеупомянутое сообщение об ошибке. Чтобы убедиться в этом, вы можете открыть средство просмотра событий и проверить, решена ли проблема или нет.
2]Изменить значения в реестре
Если вы получаете вышеупомянутую ошибку, простое изменение в файле реестра может решить проблему. Однако вам может понадобиться создать некоторые ключи и значения REG_DWORD. Будь то Windows 11, Windows 10 или любая другая старая версия, вы можете сделать следующее:
Нажмите Win + R, чтобы открыть окно «Выполнить».
Введите regedit> нажмите кнопку «ОК»> выберите вариант «Да».
Перейдите по этому пути:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols
Щелкните правой кнопкой мыши Протоколы > Создать > Ключ и назовите его TLS 1.2.
Щелкните правой кнопкой мыши TLS 1.2 > Создать > Ключ и назовите его как Клиент.
Щелкните правой кнопкой мыши «Клиент»> «Создать»> «Значение DWORD (32-разрядное)».
Установите имя DisabledByDefault.
Щелкните правой кнопкой мыши «Клиент»> «Создать»> «Значение DWORD (32-разрядное)».
Установите имя как Включено.
Дважды щелкните по нему, чтобы установить значение данных равным 1.
Нажмите кнопку ОК.
Наконец, перезагрузите компьютер. После этого ваш компьютер больше не будет отображать такие сообщения об ошибках в средстве просмотра событий.
Как проверить, включен ли TLS 1.2?
Самый простой способ проверить, включен ли TLS 1.2 на ПК с Windows 11/10. Вы можете использовать Интернет-свойства панель. Для этого нажмите Win+R чтобы открыть приглашение «Выполнить», введите inetcpl.cpl, и ударил Войти кнопка. Затем переключитесь на Передовой вкладку и перейдите к Безопасность раздел. Теперь проверьте, Используйте TLS 1.2 флажок включен или нет. Если флажок установлен, TLS 1.2 включен.
Как проверить, включен ли TLS 1.0 на сервере?
Чтобы проверить, включен ли TLS 1.0 на сервере, вы можете выполнить те же действия, что и выше. Сказав это, вы можете искать интернет-свойства в поле поиска на панели задач и щелкните отдельное окно поиска. Перейти к Передовой вкладку и проверьте, Используйте TLS 1.0 флажок включен или нет.
Это все! Надеюсь, это руководство помогло.
Читайте . Как отключить TLS 1.0 в Windows 11/10.