The error code returned from the cryptographic module is 0x8009030d

A fatal error occurred while accessing the private key of the TLS server credential. Error code returned by encryption module: error 0x8009030D. Internal error state

Обновлено 08.12.2022

0x8009030D

Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами устраняли ошибку подключения «Код ошибки 0x907. Расширенный код ошибки 0x0». В сегодняшней статье мы рассмотрим еще одну ошибку RDP, которая не дает людям любые подключения «Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки«. Данную проблему я стал получать массово в декабре 2022. Давайте покажу куда нужно смотреть.

Описание ошибки 0x8009030D

У меня есть RDS ферма состоящая из 50 RDSH хостов, в какой-то момент люди начали массово на двух хостах получать ошибку «An internal error has occurred». Я долго искал проблему, и таки отыскал ее.

внутренняя ошибка rdp error 0x4

Ей оказалась ошибка появляющаяся каждый раз при попытке подключения ID Schannel 36870:

Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки (A fatal error occurred while accessing the private key of the TLS server credential. Error code returned by encryption module: error 0x8009030D. Internal error state)

A fatal error occurred while accessing the private key of the TLS server credential. Error code returned by encryption module: error 0x8009030D. Internal error state

Вот так это массово выглядит.

Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки

В 99% случаев у вас просто не хватает прав на доступ к нужному SSL сертификату, который используется при RDP сессии.

Устранение ошибки ID 36870

Как я и писал ранее, чтобы убрать ошибку 0x907, я на всех участниках RDS ферму, установил нормальный Wildcard сертификат. Все стало нормально. Но, то что теперь я стал получать ошибку с кодом 0x8009030D, стало означать, с проблемой прав доступа к файлу. То есть у учетной записи NETWORK SERVICE отсутствуют разрешения на файл в C:ProgramDataMicrosoftCryptoRSAMachineKey.

Каталог MachineKeys хранит пары ключей сертификатов для пользователей и компьютеров. Эта папка используется службами сертификации и Internet Explorer, другими браузерами. В этой директории и в ее поддиректориях размещаются файлы, связанные с сертификатами и ключами контейнерами.

Папка MachineKey

Для того чтобы понять, что происходит я вам советую скачать утилиту из пакета Sysinernals под названием Process Monitor.

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

  • ✅Далее делаем себе фильтр по событию 36870, чтобы мониторить его появление

Фильтрация события 356870

  • ✅И запускаем Procmon.exe или Procmon64.exe, чтобы спарсить текущие события. Как только событие появилось, вам нужно остановить захват (CTRL+E) и сохранить этот лог в CSV файл.

Запуск Procmon64 для устранения 0x8009030D

Обратите внимание, что если у вас Procmon запущен давно, то лог файл может быть весьма внушительного размера.

Procmon64 сохранение CSV файла

Далее вам нужно поискать события подобные этому:

«17:07:32,2856463″,»lsass.exe«,»912″,»CreateFile»,» C:ProgramDataMicrosoftCryptoKeys eed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564«,»ACCESS DENIED«,»Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, Impersonating: NT AUTHORITYNETWORK SERVICE«

Как видно, учетная запись NETWORK SERVICE не смогла прочитать ключ  eed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564.

"17:07:32,2856463","lsass.exe","912","CreateFile","C:ProgramDataMicrosoftCryptoKeyseed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564","ACCESS DENIED","Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, Impersonating: NT AUTHORITYNETWORK SERVICE"

Как предоставить права на сертификат

  • ✅Нажмите сочетание клавиш Win+R и вызовите оснастку mmc.

Вызов mmc оснастки

Далее Вам нужно нажать CTR:+M. Найдите оснастку «Сертификаты» и переместите ее вправо. Там выберите пункт «Учетной записи компьютера«.

Добавление оснастки сертификаты, учетной записи компьютера

Кажем, что это будет локальный компьютер, но можно сделать и удаленного, если нет доступа по RDP.

Добавление сертификата локального компьютера

Найдите в личном контейнере компьютера, нужный сертификат, который используется при подключении. В контекстном меню выберите пункт «Управление закрытыми ключами«.

Управление закрытыми ключами

Далее в открывшемся ACL вам нужно дать права чтения для NETWORK SERVICE.

Предоставление прав на сертификат

Права для NETWORK SERVICE

  • ✅Второй метод, это использовать утилиту командной строки:

icacls «C:ProgramDataMicrosoftCryptoRSAMachineKeyseed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564» /grant *S-1-5-20:RX

Примечание: вам может потребоваться стать владельцем файла, если вы не можете изменить его разрешения.

takeown /F «C:ProgramDataMicrosoftCryptoRSAMachineKeysfilename»

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

Сброс разрешения для папки MachineKeys

Для сброса разрешений на данную папку, выполните в консоли в режиме администратора.

Md C:temp

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempBeforeScript_permissions.txt

takeown /f «C:ProgramDataMicrosoftCryptoRSAMachineKeys» /a /r

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYSystem:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYNETWORK SERVICE:(R)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «BUILTINAdministrators:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempAfterScript_permissions.txt

Где хранится самоподписный сертификат в реестре

Это больше для себя, где лежит отпечаток сертификата:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlTerminal ServerWinStations

Самоподписный сертификат в реестре

Дополнительные ссылки

  • https://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers/8259#8259
  • https://learn.microsoft.com/en-US/troubleshoot/windows-server/remote/custom-server-authentication-certificate-for-tls
  • https://serverfault.com/questions/541364/how-to-fix-rdp-on-windows-server-2012
  • https://learn.microsoft.com/ru-ru/troubleshoot/azure/virtual-machines/troubleshoot-rdp-internal-error

Содержание

  1. Error 0x8009030d returned by acceptsecuritycontext
  2. Описание ошибки 0x8009030D
  3. Устранение ошибки ID 36870
  4. Как предоставить права на сертификат
  5. Сброс разрешения для папки MachineKeys
  6. Где хранится самоподписный сертификат в реестре
  7. Error 0x8009030d returned by acceptsecuritycontext
  8. Asked by:
  9. Question
  10. Error 0x8009030d returned by acceptsecuritycontext
  11. Question
  12. Answers
  13. Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)
  14. Причины ошибок 0x8009030E и 0x8009030D
  15. Решения:
  16. Если у вас SCVMM
  17. Мигрируем через Powershell
  18. What might cause System.Net Error:AcquireCredentialsHandle() failed with error 0X8009030D?

Error 0x8009030d returned by acceptsecuritycontext

Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами устраняли ошибку подключения «Код ошибки 0x907. Расширенный код ошибки 0x0». В сегодняшней статье мы рассмотрим еще одну ошибку RDP, которая не дает людям любые подключения «Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки«. Данную проблему я стал получать массово в декабре 2022. Давайте покажу куда нужно смотреть.

Описание ошибки 0x8009030D

У меня есть RDS ферма состоящая из 50 RDSH хостов, в какой-то момент люди начали массово на двух хостах получать ошибку «An internal error has occurred». Я долго искал проблему, и таки отыскал ее.

Ей оказалась ошибка появляющаяся каждый раз при попытке подключения ID Schannel 36870:

Вот так это массово выглядит.

В 99% случаев у вас просто не хватает прав на доступ к нужному SSL сертификату, который используется при RDP сессии.

Устранение ошибки ID 36870

Как я и писал ранее, чтобы убрать ошибку 0x907, я на всех участниках RDS ферму, установил нормальный Wildcard сертификат. Все стало нормально. Но, то что теперь я стал получать ошибку с кодом 0x8009030D, стало означать, с проблемой прав доступа к файлу. То есть у учетной записи NETWORK SERVICE отсутствуют разрешения на файл в C:ProgramDataMicrosoftCryptoRSAMachineKey.

Каталог MachineKeys хранит пары ключей сертификатов для пользователей и компьютеров. Эта папка используется службами сертификации и Internet Explorer, другими браузерами. В этой директории и в ее поддиректориях размещаются файлы, связанные с сертификатами и ключами контейнерами.

Для того чтобы понять, что происходит я вам советую скачать утилиту из пакета Sysinernals под названием Process Monitor.

  • ✅Далее делаем себе фильтр по событию 36870, чтобы мониторить его появление

  • ✅И запускаем Procmon.exe или Procmon64.exe, чтобы спарсить текущие события. Как только событие появилось, вам нужно остановить захват (CTRL+E) и сохранить этот лог в CSV файл.

Далее вам нужно поискать события подобные этому:

Как видно, учетная запись NETWORK SERVICE не смогла прочитать ключ eed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564.

Как предоставить права на сертификат

  • ✅Нажмите сочетание клавиш Win+R и вызовите оснастку mmc.

Далее Вам нужно нажать CTR:+M. Найдите оснастку «Сертификаты» и переместите ее вправо. Там выберите пункт «Учетной записи компьютера«.

Кажем, что это будет локальный компьютер, но можно сделать и удаленного, если нет доступа по RDP.

Найдите в личном контейнере компьютера, нужный сертификат, который используется при подключении. В контекстном меню выберите пункт «Управление закрытыми ключами«.

Далее в открывшемся ACL вам нужно дать права чтения для NETWORK SERVICE.

  • ✅Второй метод, это использовать утилиту командной строки:

Примечание: вам может потребоваться стать владельцем файла, если вы не можете изменить его разрешения.

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

Сброс разрешения для папки MachineKeys

Для сброса разрешений на данную папку, выполните в консоли в режиме администратора.

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempBeforeScript_permissions.txt

takeown /f «C:ProgramDataMicrosoftCryptoRSAMachineKeys» /a /r

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYSystem:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYNETWORK SERVICE:(R)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «BUILTINAdministrators:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempAfterScript_permissions.txt

Где хранится самоподписный сертификат в реестре

Это больше для себя, где лежит отпечаток сертификата:

Источник

Error 0x8009030d returned by acceptsecuritycontext

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

I am configuring Logshipping , During the same after establishing the logshipping , i waited till the backup job in the source gets triggered in the interval.

But the job failed with the below error :

Message
2016-08-22 16:45:09.60 *** Error: Failed to connect to server WIN-VQ6QHC236G6.(Microsoft.SqlServer.ConnectionInfo) ***
2016-08-22 16:45:09.60 *** Error: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.(.Net SqlClient Data Provider) ***
2016-08-22 16:45:09.60 —— END OF TRANSACTION LOG BACKUP ——

the server is not in domain , but in the same office. where it is rechable to each machine.

both the instances run with same user account in differnt machine with admin rights(groups) included in it.

Can you please tell me how to resolve the above problem ,

furthur logs to give you better picture on the error .

2016-08-22 16:10:26.75 spid52 Attempting to load library ‘xplog70.dll’ into memory. This is an informational message only. No user action is required.
2016-08-22 16:10:26.76 spid52 Using ‘xplog70.dll’ version ‘2011.110.2100’ to execute extended stored procedure ‘xp_msver’. This is an informational message only; no user action is required.
2016-08-22 16:10:53.74 Logon Error: 17806, Severity: 20, State: 14.
2016-08-22 16:10:53.74 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: 10.30.14.70]
2016-08-22 16:10:53.74 Logon Error: 18452, Severity: 14, State: 1.
2016-08-22 16:10:53.74 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 10.30.14.70]

Источник

Error 0x8009030d returned by acceptsecuritycontext

Question

I can login into the rdweb site, but when I try and launch any app it fails then when I look on the server I receive the following error.

A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

Answers

The error indicates that SSL server does not have a private Key on it.You may confer with your cert publisher,and check whether cert has been issued correctly.

TechNet Subscriber Support

If you are TechNet Subscription user and have any feedback on our support quality, please send your feedbackhere.

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Источник

Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)

Всем привет сегодня разберем, как решается ошибка 0x8009030E или 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.

Сбой операции миграции виртуальной машины в исходном расположении миграции

Причины ошибок 0x8009030E и 0x8009030D

И та и другая ошибка связаны с тем что нужно входить на каждый сервер для выполнения определенной задачи (через локальный сеанс консоли, сеанс удаленного рабочего стола или удаленный сеанс Windows PowerShell) с сервера с которого осуществляется миграция либо настроить ограниченное делегирование для хостов.

Поскольку каждый раз входить с сервера на сервер неудобно, я опишу как настроить ограниченное делегирование.

Решения:

На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.

Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.

Так же если вы пытаетесь делать миграцию работающей виртуальной машины, может возникнуть ошибка VMM:

virtual machine … is using processor-specific features not supported on host…

Для решения, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.

Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E или 0x8009030D, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни

Для того чтобы kerberos отработал и вы не получили ни 0x8009030E, ни 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Переходим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service

Все можно теперь мигрировать спокойно.

Если у вас SCVMM

Если у вас есть scvmm, то проверьте, что в свойствах хоста

Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.

Мигрируем через Powershell

  • VMName — Имя виртуальной машины
  • Hyper-V-ServerName — Имя сервера, куда вы мигрируете
  • VMNameFolder — Имя папки, в которую размещается VM

Думаю было не сложно и вы победили свою ошибку 0x8009030E.

Источник

What might cause System.Net Error:AcquireCredentialsHandle() failed with error 0X8009030D?

I have a simple piece of https connection code that works well with one ssl host, connecting even though the root certificate authority is untrusted (this is a sandbox environment, so we’re not worried about the security hole this creates, for now), and loading the certificate and key from text files, using the Nuget package OpenSSL.X509Certificate2Provider :

When I point this code to another host, that should be secured in precisely the same manner, I get the following error: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

And digging into the logs, I discover: System.Net Information: 0 : [35036] AcquireCredentialsHandle(package = Microsoft Unified Security Protocol Provider, intent = Outbound, scc = System.Net.SecureCredential) System.Net Error: 0 : [35036] AcquireCredentialsHandle() failed with error 0X8009030D.

Searching stack for this, I find many errors related to certificate store permissions, but the client certificate in this case isn’t loaded from the store.

I also find many issues relating to SecurityProtocolType. I have verified that the server is using Tls1.2 (only).

I’m calling the code from a unit test within VS 2017 Enterprise running with Administrative privileges on Win10 x64. The code is contained in a .Net 4.7 Class Library, not hosted in IIS.

What could be causing this issue?

UPDATE Following @Jeroen Mostert’s useful comments below, I tried a basic connection test with OpenSSL. Slightly anonymised results:

Is there anything amiss there?

I’ve also looked in the CAPI2 log (as suggested in the comments). This shows errors relating to the root certificate not being trusted, like this:

Does this mean my validation callbacks aren’t working — and if so, any idea why that would be?

Further Update:

If I remove the line of code which attaches the certificate, then the error goes away — I get through to the MTLS test endpoint (but, of course, fail the MTLS test that is conducted there).

What does this suggest? A problem with the certificate itself?

Источник

Here is a snapshot of the RDP status. Looks good:
enter image description here

When I go to connect from a remote machine I get an error:

"This computer can't connect to the remote computer. 
Try connecting again. If the problem continues..."

I’ve tested the port 3389 remotely, it is open. I’ve tested it with netstat.

TCP    0.0.0.0:3389           hostname:0                LISTENING
  • No Windows firewall
  • No Network Firewall
  • Brand-new self-signed certificate
  • Machine was recently rebooted, worked before that
  • Terminal Services is running
  • When I inspect the SSL cert, it shows all the details, looks good, expires in 2014
  • hklm:SystemCurrentControlSetControlTerminal ServerfDenyTSConnections is 0
  • C:ProgramDataMicrosoftCryptoRSAMachineKeys administrator has all privleges

Update:

Now I’m finding this in the event log under Administrative Events:

"A fatal error occurred when attempting to access the SSL server credential 
private key. The error code returned from the cryptographic module is 0x8009030D. 
The internal error state is 10001." 

I’m not sure how to resolve the above error. I’m not certain it’s my imported RD cert, either, though I do know it happens when I try to RDP from my machine.

Update II:

I’ve tried using powershell to generate certs with private keys. No luck.
Used techniques here and here with no luck. Each time I have added the cert to trusted roots and personal for the system user in MMC Certificate snap-in.

Update III:

So Annoying

This Forum indicates that windows may have updated during the reboot, causing an unrecoverable error in installing the Remote Desktop Connection Broker role (needed, apparently, to generate a private key pfx file to import into MMC). The bug is with hotfix June 2013 KB2821895. This might be remidied with this? http://support.microsoft.com/kb/2871777

So I ran the latest windows update and tried to install the Remote Desktop Connection Broker so that I can generate the pfx file. No luck. It says one or more parent features are not installed— even though Hyper-V etc. Are. And it does not say what other roles to add…

Update Summary Question!

So, all said and done, theoretically, would getting the RD Connection Broker to install (in order to generate a private key) likely solve my encryption error?

Многие начинающие администраторы сталкиваются с проблемой при настройке IIS для работы с HTTPS протоколом. Непосредственно после «успешной» настройки в IIS веб-сайта на работу с протоколом HTTPS (т.е. установлен сертификат в локальное хранилище компьютера и в Bindings  на 443 порту привязан сертификат)  вы обнаруживаете, что после перезагрузки сервера (например, при автоматической установке системных обновлений) сайт перестает открываться (например, IE выдает абсолютно безымянную ошибку «Internet Explorer cannot display the webpage / Internet Explorer не может отобразить эту веб-страницу«).

Вы заходите в системные логи и видите следующую ошибку:

«Event ID 36870 — A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.»

Чаще всего это означает не верную установку Вашего сертификата:

1) либо он без приватного ключа,

2) либо установлен не туда,

3) либо установлен не так, как надо :-)

Чтобы быстро поднять Ваш сайт в работу, можно первоначально сделать такое временное решение (сработает до следующей перезагрузки): в IIS7 в «Bindings» Вашего сайта открыть на редактирование строку с привязкой протокола 443 и, ничего не меняя, пересохранить. Теперь можно подумать о глобальном решении проблемы.

Нам нужно, чтобы сертификат поместился в правильное хранилище компьютера (а не пользователя).
Если у Вас сертификат уже установлен у пользователя, не копируйте его в хранилище компьютера при помощи drag’and’drop, т .к. в процессе копия не доступна процессу IIS после перезагрузки сервера. Загружайте сертификат только через импортирование из файла сертификата.

Мне помогла всего одна команда с использованием утилиты Certutil.exe (http://technet.microsoft.com/ru-ru/library/ee624045(v=WS.10).aspx).

Сначала удаляем предыдущий сертификат (если он был ранее загружен в хранилище ПК). Затем, открываем командную строку под администратором и запускаем команду со следующими параметрами:

certutil.exe -importpfx -p password C:TempSSLcert.pfx

Где,
password — пароль на приватный ключ внутри сертификата
C:TempSSLcert.pfx — путь к файлу сертификата

Эта команда импортирует сертификат в нужные хранилища локальной машины.

После этого снова привяжите сертификат в «Bindings» сайта, запустите сайт, убедитесь, что он работает. Перезагрузите ПК, проверьте, что сайт теперь запускается после перезагрузки.

Для справки приведу еще пару полезных команд:

1) certmgr.exe -add -c RootCA.cer -s -r localMachine Root

Импортирование сертификата корневого центра сертификации

2) certmgr.exe -add -c CA.cer -s -r localMachine CA

Импортирование сертификата выдающего центра сертификации

Список названий хранилищ сертификатов:

  • My — Личные
  • Root — Доверенные корневые центры сертификации
  • Trust — Доверительные отношения в предприятии
  • CA — Промежуточные центры сертификации
  • AuthRoot — Сторонние корневые центры сертификации
  • TrustedPublisher — Довереннные издатели
  • TrustedPeople — Доверенные лица
  • AddressBook — Другие пользователи

См. также —  Настройка сертификата для использования протоколом SSL с помощью команд httpcfg и netsh 

© Сушков С.А. (Соавтор: Ella Sea)

When we spend two weeks trying to resolve an issue that affects multiple servers it is worth documenting its solution. But not only to jot down a 2 liner, but to clearly lay out a detailed process. This saves our successors time and headaches down the road. Here we discuss Event 36870 Schannel 10001 – A fatal error occurred and how to resolve it. So without further ado, let’s begin…

The Problem

“A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from cryptographic module is 0x8009030D. The internal error state is 10001.”

Event 36870 Schannel 10001 - A fatal error occurred

This error message has been filling up the logs for months, occurring anywhere between 25-minute intervals on one server and 5 minutes on another.

The Cause

The cause of  event 36870 A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from cryptographic module is 0x8009030D. The internal error state is 10001.  in our case has to do with with a file permission issue. That is, the NETWORK SERVICE account is missing permissions on a file in C:ProgramDataMicrosoftCryptoRSAMachineKeys.

The Solution

To resolve Event 36870 Schannel 10001 – A fatal error occurred we need to grant the NETWORK SERVICE account proper permissions on the file in question. In order to find which file has the wrong permissions we use a tool named Process Monitor.

1. Download procmon at https://docs.microsoft.com/en-us/sysinternals/downloads/procmon. Copy it to the server in question, unzip and launch it.

Event 36870 Schannel 10001 - A fatal error occurred - Process Monitor

2. Let procmon actively monitor until the next error occurs in the System event log. Then pause the monitoring and save the log to CSV file. Find the offending MachienKeys file.

Event 36870 Schannel 10001 - A fatal error occurred - Monitor

3. Grant NETWORK SERVICE permissions on the file using PowerShell Administrator console.

icacls "C:ProgramDataMicrosoftCryptoRSAMachineKeysfilename" /grant *S-1-5-20:RX

Note: you may need to take ownership of the file if you are unable to change its permissions.

takeown /F "C:ProgramDataMicrosoftCryptoRSAMachineKeysfilename"

If this actually helped resolve your issue, please leave a comment below…

Понравилась статья? Поделить с друзьями:
  • The error code is 2911
  • The error code is 2908
  • The error code is 2738
  • The error code is 26702
  • The error code is 2605