Получено следующее предупреждение о неустранимой ошибке 80 schannel

Обновлено 20.06.2019

Добрый день! Уважаемые читатели и гости крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами научились ремонтировать ваше оборудование в операционных системах Windows, у которых был статус ошибки «Запуск этого устройства невозможен. (код 10)». Двигаемся дальше и мы рассмотрим ситуацию, когда у вас на компьютере или сервере в журналах событий, фиксируется ошибка «Schannel ID 36887: С удаленной конечной точки получено оповещение о неустранимой ошибке. Определенный в протоколе TLS код оповещения о неустранимой ошибке: 40«. Мы рассмотрим на сколько критичны данные события и стоит ли на них обращать внимание.

Описание ошибки Schannel 3688

И так я проводил оптимизацию своей RDS фермы, кто не помнит, то в последнем посте я производил удаление неактивных портов TS. После после выполненной оптимизации я перезагрузил RDSH сервер и стал мониторить наличие новых и старых ошибок. Мое внимание привлекла ошибка из системного журнала логов Windows.

Что такое Secure Channel

Schannel означает Secure Channel — библиотека, криптографический провайдер (Security Support Provider — SSP) — Защищенный канал, который содержит набор протоколов безопасности, которые обеспечивают зашифрованную идентификацию и безопасную связь. Пакет используется программным обеспечением, использующим встроенные SSL и TLS, в том числе IIS, Active Directory, OWA, Exchange, Internet Explorer и Центр обновления Windows.

Как избавиться от ошибки Schannel 36887

Для начала вам необходимо понять, что за процесс или приложение вызывает данную ошибку. Что мы делаем, открываем самое свежее оповещение и переходим на вкладку подробности, режим XML. Находим тут строку «<Execution ProcessID=»696« ThreadID=»26540« />«, как видим ошибку вызывает процесс с ID 696

Далее нам необходимо понять, что это за процесс, для этого откройте командную строку или окно PowerShell и введите команду:

В результате мы видим отфильтрованный вывод всех процессов у которых в ID встречается 696. Оказывается, что 696 ID имеет процесс lsass.exe, системный процесс Windows, но тут может быть и другой процесс, например, geforce experience, удалив который или обновив, вы избавитесь от ошибки 36887. Но в моем случае, это lsass.exe.

Я стал искать закономерности в работе данного сервера и мне удалось ее обнаружить. Теперь я точно определил, когда происходят эти события в Schannel.  Они возникают только тогда, когда я пытаюсь получить безопасное подключение к интернет-банкингу службы одного конкретного банка.  Они не возникают, когда я пытаюсь получить безопасное соединение с любым другим онлайн-сервисом.  Похоже, что-то пошло не так во время обмена рукопожатиями SSL/TLS. В таком случае вы можете поступить двумя путями:

• Позвонить в банк и разобраться почему они не используют TLS 1.2
• Отключить в Internet Explorer использование TLS 1.2 и запретить в журналах Windows регистрацию событий «Schannel ID 3688: С удаленной конечной точки получено оповещение о неустранимой ошибке. Определенный в протоколе TLS код оповещения о неустранимой ошибке: 40«

Правильный метод

На время пока у вас идет общение с представителями клиент-банка, вы можете в реестре Windows запретить журналирование для данного события. Для этого откройте ветку:

Найдите ключ EventLogging и выставите ему значение 0.

• 0 — не записывать в журнал
• 1 — записывать в журнал ошибок
• 2 — записывать в журнал предупреждений
• 3 — Журнал информационные и успешные события

После внесения ключа реестра, может потребоваться перезагрузка компьютера или сервера.

Более грубый метод

Чтобы отключить в системе появление событий Schannel ID 3688 вам необходимо открыть ваш браузер Internet Explorer 11 и перейти в раздел  «Свойства браузера»

Далее идем на вкладку «Дополнительно», где выключаем пункт «Использовать TLS 1.2», что не совсем правильно с точки зрения безопасности. Перезапускаем браузер и пользуемся своим клиент-банком.

На этом у меня все, мы с вами рассмотрели причины и решения ошибки с кодом ID 3688. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

A lot of Windows users are reporting that they’re suddenly encountering a lot of different Schannel Error entries inside Event Viewer with the 36887 ID. The error message accompanied by the error code is ‘A fatal alert was received from a remote endpoint. Fatal Alert 42’.

Schannel Error Code 36887

SChannel is essentially a set of security protocols that facilitate the implementation of encrypted identity authentication and secure communications between the involved parties.

As it turns out, several different causes might end up triggering the SChannel Error 36887:

Creating the EventLogging Registry key

As it turns out, the SChannel Error 36887 (Fatal Alert 42) can occur because your system doesn’t have a dedicated registry key where it can dump events of this kind.

If this scenario is applicable, you should be able to fix this issue by using Registry Editor to create the EventLogging key inside SecurityProviders/Schannel. This operation was confirmed to be successful by a lot of affected users that were encountering this issue on Windows Server versions.

Here’s a quick step by step guide on applying this fix on every recent Windows server version:

In case you’re still encountering constant SChannel Error 36887 Event Viewer entries with the same error or this scenario was not applicable, move down to the next potential fix below.

Uninstall Microsoft Windows Patch (KB3161606)

As it turns out, one of the most common causes that will end up causing the Schannel 36887 error is a Microsoft Windows update patch KB3161606 that ends up disabling TLS 1.0. This technology is a now-deprecated predecessor to Secure Sockets Layer (SSL), but some applications might still use it.

Depending on the applications that you use, there are a lot of applications that might be affected by this – basically, any product that requires TLS 1.0 to maintain the full functionality of the product.

If you find yourself in this scenario and you’re looking for a way to revert to the old behavior and re-enable TLS 1.0, you will need to revert the update that made this machine change.

To do this, you will need to revert the KB3161606 Windows Update and prevent it from ever being installed on your machine again. Here’s a quick step by step guide on doing so:

Note: These steps will assume that the problematic update only got installed recently, and you have a viable System Restore point to work with.

In case this method is not applicable or you followed the instructions and you still get the same constant SChannel Error 36887 in Event viewer, move down to the next potential fix below.

Uninstalling ESET Antivirus

As it turns out, ESET Antivirus Endpoint protection is not a big fan of the now deprecated TLS 1.0 Encryption. If you have any programs that still use this old technology, you will need to uninstall ESET to fix the issue (disabling the real-time protection will not work since this block is enforced at a firewall level.

Some users that were also dealing with persistent Event viewers related to Shannel have confirmed that no new errors of this kind were ever reported once they’ve removed the AV from their system.

This is not the most elegant solution, but it’s a quick fix in case you can afford to switch over to Windows Defender or another 3rd party equivalent. Here’s a quick guide on uninstalling Eset Antivirus:

In case you’re still seeing frequent SChannel Error 36887 entries in Event viewer, move down to the next potential fix below.

Running SFC and DISM scans

Under certain circumstances, you can expect to see this error due to some type of system file corruption that ends up affecting your machine ability to handle TSL encryption. In this case, you will need to run a couple of utilities equipped to find and fix instances of corrupted system files.

Fortunately, every recent Windows version is equipped with two built-in tools capable of helping you do this: System File Checker (SFC) and Deployment and Image Servicing and Deployment (DISM).

Both utilities will ultimately help you clean your system for system file corruption, but they operate differently – DISM relies on a Windows Update subcomponent to download healthy copies for the files that need to be replaced while SFC retrieves healthy files from an archive that is stored locally.

Our recommendation is to run both utilities in quick succession to improve your chances of fixing the issue. Start with a simple SFC scan and once the operation is complete, restart your computer and start a DISM scan.

Note: Keep in mind that before running DISM, you will need to ensure that your Internet connection is stable.

After both scans have been successfully performed, reboot your computer and see if you’re still seeing the same constant SChannel Error 36887 (Fatal Alert 42) errors in Event viewer.

In case the same problem is still occurring, move down to the next method below.

Disabling the use of TLS Options

In case you notice that these Schannel errors are somehow triggered by your web surfing (whenever you visit certain websites), it’s very likely that the error gets triggered when you visit sites that don’t use TLS encryption.

In this case, you can ensure that the same errors aren’t thrown ever again by this scenario by disabling the Use TLS option inside your Internet Options menu. This is not ideal since it might leave your system vulnerable to certain browser hijackers, but it serves as a reliable temporary fix.

Here’s a quick guide on disabling the use of TLS Options via the Internet Options menu:

In case you’re still stuck with the same SChannel Error 36887 (Fatal Alert 42) error, move down to the next potential fix below.

Installing the Latest version of CCleaner (if applicable)

As it turns out, this problem can also be caused by an older version of a 3rd party cleaning app called CCleaner from Piriform. This particular problem is only reported to occur with version 5.06.

If this scenario is applicable and you have CCleaner installed on your computer, you should be able to fix the issue by uninstalling the current CCleaner version and then reinstalling the latest. This operation was confirmed to work by several affected users that we’re encountering the SChannel Error 36887 (Fatal Alert 42) error.

If this applies to you too, follow the instructions below to uninstall current CCleaner and reinstall the latest version:

SChannel 36887 Errors in Windows Server

The Problem: You open up the Windows event viewer and see loads of Red SChannel 36887 errors. If you’re like most admins, you want to fix this problem, but can’t really figure out how. These errors are notoriously hard to resolve because they don’t often happen regularly. Most of the time, you don’t know the exact configuration that caused the error, so it’s impossible to replicate the errors in a way that allows you to run wireshark to figure things out directly, so you just have to go off the error message and what it includes. In this post, I’ll go over the schannel 36887 errors, what it means, and what you should do about it.

What is SChannel?

SChannel is a shortened term for the Secure Channel system, which is what Windows uses to authenticate access and encrypt data. All of the protocols and authentication techniques are included in the SChannel system and any errors in this system are going to represent problems with processing. One thing to remember when addressing these errors; they only apply to HTTPS or other SSL/TLS encrypted sessions, unless they are tied to Active Directory domain replication or authentication errors. My focus in this article, though, is HTTPS, so we’ll ignore the other systems.

What is the 36887 Error?

SChannel 36887 errors occur when something happens with SSL/TLS sessions on the server. The error itself can mean a number of things, and you have to read the error message to find out what is causing the error. In almost every situation, these error happen because of issues with the client computer and not the server itself. There are some situations where there’s a problem with the server, but these are not as common. The frequency of the events can help you determine if there’s some problem with the server’s ability to encrypt data. If you get these events constantly, there is likely some issue with the certificate installed on the server that is encrypting HTTPS sessions, and you’ll want to investigate further. Later on, I’ll go over some of the error codes tied to the 36887 error and what you can do about them.

Figuring out the Cause

When viewing the 36887 errors, you will want to open up the error itself and look at what shows up the the general tab’s error information. You’ll want to look for a 2 or 3 digit error code as shown below:

Note the circled error number. You’ll need this information to determine the root cause of the error. In the next session, I’ll go over some of the codes in the next section.

Schannel 36887 Errors and What They Mean

There are quite a few of these error codes, and some of them are pretty confusing or not helpful. I won’t go over all of them, but I will highlight some of the more important ones. You can find a full list of the error codes and what the errors are at Microsoft’s document on the subject. If you are getting an error message that is listed there as “SSL3-” and whatever, disable SSL3.0. I won’t cover any of the SSL3 error codes here because they are old and I don’t want to encourage people to use SSL3.0.

Error 20 – This is an error you really want to look out for, because it’s an indicator that there is a man-in-the-middle attack going on. This error really only happens when the MAC address on the message is changed or corrupted. It’s very rare, and can happen with network corruption errors, but is also an indicator that someone is attempting to spoof MAC addresses or the MAC address on the message was changed. Investigate this heavily.

Error 21 – An error occurred when the server attempted to decrypt a message from the client. This one is weird and difficult to figure out. Most likely caused by network errors that corrupt the message in transit. If these are happening regularly, check your network for communication errors. If the network is fine, look for corruption on the server. I’ve never actually seen this error in the wild, so hopefully you don’t either.

Error 42 – The certificate is bad. Nobody knows *why* the certificate is bad, but it’s bad. Best solution here is to replace the certificate used for encryption. In the words of Pepe the King Prawn, you must “smack [it] like a bad, bad donkey, okay?”

Error 43 – The certificate isn’t supported. Usually this means that the client doesn’t support any of the encryption protocols defined by the certificate. If you can figure out which client is tripping this error, you can set it up to accept those authentication errors. In general, though, this only happens if the certificate is Really really old.

Error 44 – The certificate has been revoked. You won’t see this error often, but just means that the certificate in use is not longer usable because it is insecure in some way. Just generate a new certificate and replace this one, because the one that is installed will never work again. Note that client machines Cannot Connect if this error is happening.

Error 45 – The certificate has expired and needs to be replace. All Digital Certificates have an expiration date and should not be used once they expire. Again, replace the certificate to fix this error. Clients can usually still connect when a certificate expires, but some web clients will not allow users to connect to systems with expired certificates.

Error 46 – This one is weird. The error means there has been an error with the certificate, but the system doesn’t recognize the error or doesn’t really know what happened. Often, you’ll see this error when users connect with out of date devices or browsers. However, it can also represent an attempt (usually a failed attempt) to break TLS encryption by a bad actor (A hacker. Not Paris Hilton). Most of the time you can ignore this error, but if the server is available from the Internet in any way, look into implementing a reverse proxy to protect against hacks that try to take advantage of flaws in encryption protocols.

Error 48 – The client doesn’t trust the Certificate Authority that created the certificate. This is usually easy to fix, and involves exporting a copy of the root CA certificate and importing it to the client’s computer in the Third Party Root Certificate Authorities store or the Trusted Root Certificate Authorities store. Specific instructions are available from Microsoft.

Error 49 – Access denied. This is an odd one. It doesn’t mean that access to the webpage was denied, it means that the client or server doesn’t have permission to use the certificate. Most often this will happen because the System or Machine account doesn’t have permission to read the Private Key on the certificate. Instructions to fix this are available from Watchguard. Just include the SYSTEM account in the ACL and grant it full permission. You may also need to grant this permission to NETWORK SERVICE, but don’t grant it to all users.

Error 51 – The message failed to decrypt. Usually caused by network corruption issues, but can be caused by an attempt to tamper with the message or because something was wrong with the encryption protocol that was used. If you see this regularly, dig into your network. This may also be caused by improper implementation of SSL/TLS, and needs to be fixed in the application itself.

Error 60 – The certificate in use was exported when export wasn’t authorized or an attempt to export an un-exportable certificate failed. Can signify at attempt to obtain the private key of the certificate for use in a hack, but mostly happens if you attempt to copy a cert that doesn’t support export.

Error 70 – The encryption protocol that the client or server attempted to use is not supported by the other system. This can occur if you have a Windows XP client that attempts to access a server that only support TLS1.2 or later, or a specific crypto-suite isn’t available to the client machine. If this happens, you need to allow older TLS protocols on the server (not recommended), Allow newer protocols on the server (if the server doesn’t support newer protocols, make sure it does), or upgrade whichever system doesn’t support newer protocols.

Error 71 – Pretty similar to error 70, this occurs when one system doesn’t support an encryption algorithm defined in the certificate. The fix is the same as error 70.

Error 80 – Service engine soon. In other words, something broke on the server, but it won’t tell you what. This error should be surrounded by some other errors that you can use to troubleshoot the problem, or you can just ignore it. Up to you.

Error 90 – This happens if a session is cancelled before completion. With the speed things happen these days, you aren’t likely to see this error. It can, however, be an indicator of attempted hack.

Error 110 and 111 – These are similar to 80, in that they represent unknown or totally arcane issues that are difficult to fix. Look around the error for clues.

Results

Hopefully the list of errors and solutions to them above will help you when you are dealing with these error messages. A lot of times, the 36887 error can be ignored, but sometimes there is a problem that needs to be fixed. Use this guide if you run into these errors so you can fix them and clean up your error logs.

После вчерашних обновлений опять выявилось одно конфликтующее с VipNet — KB2992611

На двух серверах с Windows Server 2008 R2 перестал работать SQL Server. При попытках подключения к нему в журнале Windows:

«Ошибка Schannel 36888 Возникло следующее неустранимое предупреждение: 80. Внутреннее состояние ошибки: 603 (потом 1050, 1250)».

После удаления обновления все заработало. VipNet клиент версии 3.2(11.21139)

Подтверждаю эту проблему. Главный сегодня обновил сервер 2008 R2 с VipNet’ом, и все тотчас же вылетели из программного пакета, использующего Microsoft SQL Server. Сообщение об ошибке аналогично указанному Evgel’ем. Прикол в том, что резервные (и потому не защищенные VipNet’ом) компьютеры свободно подключались и работали как ни в чем не бывало (для них в настройках VipNet’а выделен диапазон адресов для спец. ситуаций). Короче, все машины без VipNet’а свободно работали с SQL Server’ом, а с VipNet’ом — нет. Срочно снесли обновления, — проблема исчезла.

Помимо того уже более половины компьютеров с W7 x 32 потеряли способность обновляться. Это при том, что ставились все системы с одного и того же дистрибутива, а активировались потом через Инет каждый по своему коду. Одинаковая система, одинаковое железо, но — половина еще обновляется, а половина уже не может. Просто бред какой-то.

Скажу по чести, мы VipNet не выбирали. Мы бы предпочли для тех же целей применить совсем другие продукты, НО… нас никто даже не спрашивал. Над нами много инстанций… Сказали: «Только сертифицированное, а из сертифицированного — только вот это! И чтоб не тявкать!..» В свете этого некоторые посты читать даже довольно обидно. Но оставим лирику и чувства. Я так понял, что беспроблемная версия будет сертифицироваться месяца 3-4, через интанции-«прокладки» с Вашего «Олимпа» до наших «трущеб» она спустится тоже не сразу. То есть, нам полгода «крутиться на собственном пупе» как сможем? На необновляемых машинах, или скрупулезно отлавливая «некошерные» KB-шки? Ладно, спасибо и на этом. По ходу, в этой ветке у меня уже вопросов не предвидится.