First published on MSDN on Apr 28, 2017
Recently, I have assisted a Premier customer who installed a new certificate on Windows Server 2008 R2 but was unable to bind the certificate to the Website hosted on IIS. 7.5. This is the error we were getting:
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
Log Name: System
Source: Schannel
Date: 7/2/2016 9:52:25 AM
Event ID: 36870
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: MyComp.Mydomain.com
Description:
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.
The error indicates that IIS is not able to access the certificate’s private key.
Steps we took to fix the issue:
-
Resolution:
- Contact your certificate vendor for a certificate with private key. Import the cert and do the binding in IIS.
-
Temporary Workaround:
- Assuming this is a valid certificate, verify that the certificate includes a private key. Double clicking the certificate in certificate manager (Certificate store) should say «You have a private key that corresponds to this certificate»:
-
Export certificate
with its private key
-
Now
re-imported
using the «Mark the private key exportable».
- Now do the binding in IIS.
title | author | description | ms.date | ms.assetid | msc.legacyurl | msc.type |
---|---|---|---|---|---|---|
Troubleshooting SSL related issues (Server Certificate) |
kaushalp |
Tools Used in this Troubleshooter: SSLDiag Network Monitor 3.4/Wireshark This material is provided for informational purposes only. Microsoft makes no warran… |
04/09/2012 |
7626d39d-7923-4776-a342-4e49ed2983c3 |
/learn/troubleshoot/security-issues/troubleshooting-ssl-related-issues-server-certificate |
authoredcontent |
Troubleshooting SSL related issues (Server Certificate)
by Kaushal Kumar Panday
Tools Used in this Troubleshooter:
- SSLDiag
- Network Monitor 3.4/Wireshark
This material is provided for informational purposes only. Microsoft makes no warranties, express or implied.
Overview
This document will help you in troubleshooting SSL issues related to IIS only. Client Certificates troubleshooting will not be covered in this document. Server Certificates are meant for Server Authentication and we will be dealing only with Server Certificates in this document.
If the Client certificates section is set to «Require» and then you run into issues, then please don’t refer this document. This is meant for troubleshooting SSL Server certificates issue only.
It is important to know that every certificate comprises of a public key (used for encryption) and a private key (used for decryption). The private key is known only to the server.
The default port for https is 443.
I am under the assumption the reader is well-versed in SSL Handshake and the Server Authentication process during the SSL handshake.
Description of the Secure Sockets Layer (SSL) Handshake:
<https://support.microsoft.com/kb/257591
>
Description of the Server Authentication Process during the SSL Handshake:
<https://support.microsoft.com/kb/257587
>
Scenarios
The following error message is seen while browsing the website over https:
The first thing that has to be checked is whether the website is accessible over http. If it is not, there likely is a separate issue not covered here. You will need to have the website working on http first before continuing with this troubleshooter.
Now let’s assume the website is accessible over http and we get the above error when trying to browse over https. The problem is seen because the SSL handshake failed and hence the error message was seen. There could be many reasons. We will follow a step-by-step approach to solve this problem.
Scenario 1
Check if the server certificate has the private key corresponding to it. Refer the below picture:
If private key is missing, then you need to get a certificate containing the private key, which is essentially a .PFX file. There is a command that we could try to run in order to associate the private key with the certificate:
[!code-consoleMain]
If the association is successful, then you would see the following window:
Note: 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33 is the thumbprint of the certificate. Open the certificate and click on the details tab. Scroll down to find the thumbprint section. Select the thumbprint section and click on the text below. Do a «Ctrl+A» and then «Ctrl+C» to select and copy it. Below is a snapshot for your reference:
Note: This command doesn’t succeed always. If this fails, then you need to get a certificate containing the private key from the CA. The file extension for a certificate containing private key is .pfx.
Scenario 2
We went pass the first hurdle and now we have a server certificate containing the private key installed on the website. However, we still get the same error as above. The website is still not accessible over https.
The SSLDiag tool comes in handy here.
Windows Server 2003:
Download X64 (https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5329
)
Download X86 (https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=674
)
For IIS 7 and IIS 7.5, use vijaysk’s SSL Diagnostics tool. Below is the link:
https://blogs.msdn.com/b/vijaysk/archive/2009/09/20/ssl-diagnostics-tool-for-iis-7.aspx
Install the tool and run it on the server. If you have a certificate containing private key and still not able to access the website, then you may want to run this tool or check the system event logs for SChannel related warnings/errors.
While running the SSLDiag tool you may get the following error:
You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed
There will also be a SChannel warning in the system event logs as shown below:
Event Type: Error |
---|
Event Source: Schannel |
Event Category: None |
Event ID: 36870 |
Date: 2/11/2012 |
Time: 12:44:55 AM |
User: N/A |
Computer: |
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016. |
This event/error indicates that there was a problem acquiring certificate’s private key. So let’s try the below steps one by one:
-
Firstly, verify the permissions on the machinekeys folder as per the KB Article: https://support.microsoft.com/kb/278381. All the private keys are stored within the machinekeys folder, so we need to ensure that we have necessary permissions.
-
If the permissions are in place and if the issue is still not fixed. Then it must be a problem with the certificate. It may have been corrupted (You may see an error code of 0x8009001a in the SChannel event log).
Event Type: Error Event Source: Schannel Event Category: None Event ID: 36870 Date: 2/11/2012 Time: 12:44:55 AM User: N/A Computer: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a. -
We will test if the website works with a test certificate. Take a back-up of the existing certificate and then replace it with a self-signed certificate. Try accessing the website via https. If it works then the certificate used earlier was corrupted and it has to be replaced with a new working certificate.
-
Sometimes the problem may not be with the certificate but with the issuer. You may see the following error in SSLDiag:
CertVerifyCertificateChainPolicy will fail with CERT_E_UNTRUSTEDROOT (0x800b0109), if the root CA certificate is not trusted root.
To fix this add the CA’s certificate to the «Trusted Root CA» store under My computer account on the server.
-
You may also get the following error:
CertVerifyCertificateChainPolicy returned error -2146762480(0x800b0110).
If the above error is received then we need to check the usage type of the certificate. Open the certificate, click on the «Details» tab and then click on «Edit Properties…» button. Under General tab make sure «Enable all purposes for this certificate» is selected and most importantly «Server Authentication» should be present in the list.
Scenario 3
The first 2 steps check the integrity of the certificate. Once we have confirmed that there are no issues with the certificate, a big problem is solved. But, what if the website is still not accessible over https. Check the HTTPS bindings of the website and determine what port and IP it is listening on. You could run the following command to ensure no other process is listening on the SSL port used by the website.
[!code-consoleMain]
If there is another process listening on that port then check why that process is consuming that port. Try changing the IP-Port combination to check if the website is accessible or not.
Scenario 4
By now we are sure that we have a proper working certificate installed on the website and there is no other process using the SSL port for this website. However, I still get «Page cannot be displayed» error while accessing over https. When a client connects and initiates an SSL negotiation, HTTP.sys looks in its SSL configuration for the «IP:Port» pair to which the client connected. The HTTP.sys SSL configuration must include a certificate hash and the name of the certificate store before the SSL negotiation will succeed. The problem may be with the HTTP.SYS SSL Listener.
-
The Certificate hash registered with HTTP.SYS may be NULL or it may contain invalid GUID. Execute the following from a command prompt:
[!code-consoleMain]
[!NOTE]
httpcfg is part of Windows Support tools and is present on the installation disk. You could download it from here as well:https://www.microsoft.com/download/en/details.aspx?id=7911
Below is a sample of a working and non-working scenario:
Working scenario:
Configuration Setting IP 0.0.0.0:443 Hash Guid {00000000-0000-0000-0000-000000000000} CertStoreName MY CertCheckMode 0 RevocationFreshnessTime 0 UrlRetrievalTimeout 0 SslCtlIdentifier 0 SslCtlStoreName 0 Flags 0 Non-working scenario:
Configuration Setting IP 0.0.0.0:443 Hash c09b416d6b 8d615db22 64079d15638e96823d Guid {4dc3e181-e14b-4a21-b022-59fc669b0914} CertStoreName MY CertCheckMode 0 RevocationFreshnessTime 0 UrlRetrievalTimeout 0 SslCtlIdentifier 0 SslCtlStoreName 0 Flags 0 The Hash value seen above is the Thumbprint of your SSL certificate. Notice, that the Guid is all zero in a non-working scenario. You may see the Hash either having some value or blank. Even if we remove the certificate from the web site, and then run «httpcfg query ssl», the website will still list Guid as all 0’s. If you see the GUID as «{0000……………000}, then there is a problem.
We need to remove this entry by running the command:
[!code-consoleMain]
For example:
[!code-consoleMain]
-
Delete any entries in the IP Listen list.
To determine whether any IP addresses are listed, open a command prompt, and then run the following command:
[!code-consoleMain]
[!code-consoleMain]
If the IP Listen list is empty, the command returns the following string:
[!code-consoleMain]
If the command returns a list of IP addresses, remove each IP address in the list by using the following command:
[!code-consoleMain]
[!NOTE]
restart IIS after this via command «net stop http /y»
Scenario 5
After all this if you are still unable to browse the website on https, then capture a network trace either from the client or server. Filter the trace by «SSL or TLS» to look at SSL traffic.
Below is a network trace snapshot of a non-working scenario:
Working scenario:
Well, this is definitely now how you look at a network trace. You need to expand the frame details and see what protocol and cipher was chosen by the server. Select «Server Hello» from the description to get those details.
In the non-working scenario, the client was configured to use TLS 1.1 and TLS 1.2 only. However, the web server was IIS 6, which can support until TLS 1.0 and hence the handshake failed.
Do check the registry keys to determine what protocols are enabled or disabled. Here’s the path:
[!code-consoleMain]
The «Enabled» DWORD should be set to «1». If «0» then the protocol is disabled.
For example, SSL 2.0 is disabled by default.
Scenario 6
If everything has been verified and if you are still running into issues accessing the website over https, then it most likely is some update which is causing the SSL handshake to fail.
Microsoft has released an update to the implementation of SSL in Windows:
[!code-consoleMain]
There is potential for this update to impact customers using Internet Explorer, or using an application that uses Internet Explorer to perform HTTPS requests.
There were actually two changes made to address information disclosure vulnerability in SSL 3.0 / TLS 1.0. The MS12-006 update implements a new behavior in schannel.dll, which sends an extra record while using a common SSL chained-block cipher, when clients request that behavior. The other change was in Wininet.dll, part of the December Cumulative Update for Internet Explorer (MS11-099), so that IE will request the new behavior.
If a problem exists, it may manifest as a failure to connect to a server, or an incomplete request. Internet Explorer 9 is able to display an «Internet Explorer cannot display the webpage» error. Prior versions of IE may simply display a blank page.
Fiddler does not use the extra record when it captures and forwards HTTPS requests to the server. Therefore, if Fiddler is used to capture HTTPS traffic, the requests will succeed.
Registry keys
As documented in https://support.microsoft.com/kb/2643584, there is a SendExtraRecord registry value, which can:
- Globally disable the new SSL behavior
- Globally enable it, or
- (Default) enable it for SChannel clients that opt in to the new behavior.
For Internet Explorer and for clients that consume IE components, there is a registry key in the FeatureControl section, FEATURE_SCH_SEND_AUX_RECORD_KB_2618444, which determines whether iexplore.exe or any other named application opts in to the new behavior. By default this is enabled for Internet Explorer, and disabled for other applications.
Other Resources
- Description of the Secure Sockets Layer (SSL) Handshake (
https://support.microsoft.com/kb/257591
) - Description of the Server Authentication Process During the SSL Handshake (
https://support.microsoft.com/kb/257587
) - Fixing the Beast
- Taming the Beast (Browser Exploit Against SSL/TLS)
- SSL CERTIFICATE FILE EXTENSIONS
- Support for SSL/TLS protocols on Windows
- Troubleshooting SSL related issues with IIS
- PRB: Cannot visit SSL sites after you enable FIPS compliant cryptography
- HTTP 1.1 host headers are not supported when you use SSL (
https://support.microsoft.com/kb/187504
) - Configuring SSL Host Headers (IIS 6.0)
- Remove From My Forums
-
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.
Any ideas?
Answers
-
Hi,
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.
Regards,
Clarence
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.
-
Marked as answer by
Wednesday, July 31, 2013 3:07 AM
-
Marked as answer by
Here is a snapshot of the RDP status. Looks good:
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)
Hi,
We develop a server-side application which receives incoming https connections using self-signed certificate. It was all ok while we were using Windows 7 or Windows 2008 as OS, but when our clients started installing Windows 8 as server OS they encountered
big problem: application got unavailable in few hours after start.
In event logs we have following:
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.
After restart, application recreates certificate and all works normal few hours till next fatal error.
This article did
not help us. And I repeat that this error appears only on Windows 8 (we tested on Windows 8.1). Windows 2012 Server we did not test yet.
To create certificate we used code attached code from this article:
http://blogs.msdn.com/b/dcook/archive/2008/11/25/creating-a-self-signed-certificate-in-c.aspx
How we can solve this problem?
Best regards!
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.”
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.
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.
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…
Содержание
- Error 0x8009030d returned by acceptsecuritycontext
- Описание ошибки 0x8009030D
- Устранение ошибки ID 36870
- Как предоставить права на сертификат
- Сброс разрешения для папки MachineKeys
- Где хранится самоподписный сертификат в реестре
- Error 0x8009030d returned by acceptsecuritycontext
- Asked by:
- Question
- Error 0x8009030d returned by acceptsecuritycontext
- Question
- Answers
- Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)
- Причины ошибок 0x8009030E и 0x8009030D
- Решения:
- Если у вас SCVMM
- Мигрируем через Powershell
- 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?
Источник
I am trying to do something that feels like it should be straightforward. I have VS2013 on Win8 and I’m just experimenting with a vanilla MVC ASP.NET project to gain some web experience. This works fine in IE10 until I try to enable SSL.
To do this, I select the project, go to the Properties window, and change the «SSL Enabled» property to «True». Then I copy the value of «SSL URL» to the «Project Url» edit box under Project/Properties/Web.
After these steps, when I try to launch the website I get a «page can’t be displayed error».
Looking in the system log, I see two relevant events:
-
Source: Schannel, ID: 36870, Description: «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.»
-
Source: HttpEvent, ID: 15021, Description: «An error occurred while using SSL configuration for endpoint 0.0.0.0:44300. The error status code is contained within the returned data.»
What am I missing to be able to enable SSL? I am trying to follow the tutorial here: http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on#author-info
Thanks.