Обновлено 19.06.2017
Всем привет сегодня разберем, как решается ошибка 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.
Давайте подробнее посмотрим как она выглядит, я про 0x8009030E .
Сбой операции миграции виртуальной машины в исходном расположении миграции
Причины ошибки 0x8009030E
Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.
На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.
Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.
Так же если вы пытаетесь делать миграцию работающей виртуальной машины, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.
Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни
Для того чтобы kerberos отработал и вы не получили 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Перехлдим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service
Все можно теперь мигрировать спокойно.
Если у вас SCVMM
Если у вас есть scvmm, то проверьте, что в свойствах хоста
Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.
Мигрируем через Powershell
Move-VM <VMName> <Hyper-V-Servername> -IncludeStorage -DestinationStoragePath D:Hyper-V<VMNameFolder>
- VMName — Имя виртуальной машины
- Hyper-V-ServerName — Имя сервера, куда вы мигрируете
- VMNameFolder — Имя папки, в которую размещается VM
Думаю было не сложно и вы победили свою ошибку 0x8009030E.
Содержание
- Common Windows Security Errors
- Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
- Errors
- 0x80090302
- Possible Solutions
- 0x8009030D
- Possible Solutions
- 0x8009030E
- Possible Solutions
- 0x80090304
- 0x80090308
- Possible Causes
- 0x80090325
- 0x80090326
- Possible Solutions
- 0x80090327
- 0x80090331
- 0x8009035D
- Possible Solutions
- 0x8009030F or 0x80090321
- Веб — сервис интеграции
- Stunnel error 0x8009035d returned by initializesecuritycontext 2
- Описание ошибки 0x8009030D
- Устранение ошибки ID 36870
- Как предоставить права на сертификат
- Сброс разрешения для папки MachineKeys
- Где хранится самоподписный сертификат в реестре
- Stunnel error 0x8009035d returned by initializesecuritycontext 2
Common Windows Security Errors
Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
Date Entered: 06/10/2015 Last Updated: 04/09/2018
Errors
0x80090302
Possible Solutions
This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this
Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.
0x8009030D
Possible Solutions
Using OpenSSL, the certificate can be converted with the command:
openssl pkcs12 -export -passout pass:»» -in cert_key_pem.txt -out cert_key_out.pfx -name «My Certificate»
Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.
0x8009030E
Possible Solutions
0x80090304
- This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200 .
After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.
0x80090308
Possible Causes
0x80090325
The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.
0x80090326
Possible Solutions
0x80090327
This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.
0x80090331
Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn’t support the newer ciphers required by the server. Here is a list of ciphers supported in XP.
0x8009035D
Possible Solutions
0x8009030F or 0x80090321
These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.
Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:
- Use our internal security API by passing the string «UseInternalSecurityAPI=True» to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
- Disable the two cipher suites mentioned above
- Disable support for TLS 1.2
- Upgrade your machine to a newer version of Windows
Источник
Веб — сервис интеграции
Уважаемый участник рынка ДМДК!
Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».
Доброго времени суток!
Установил обезличенный сертификат.
в SOAP пытаюсь установить соединение, но выдаёт ошибку сертификата:
2021.11.26 11:32:48 LOG5[5972:1472]: stunnel 4.18 on x86-pc-unknown
2021.11.26 11:32:48 LOG5[5972:1472]: Threading:WIN32 Sockets:SELECT,IPv6
2021.11.26 11:32:48 LOG5[5972:1472]: No limit detected for the number of clients
2021.11.26 11:32:48 LOG7[5972:1472]: FD 356 in non-blocking mode
2021.11.26 11:32:48 LOG7[5972:1472]: SO_REUSEADDR option set on accept socket
2021.11.26 11:32:48 LOG7[5972:1472]: https bound to 127.0.0.1:1500
2021.11.26 11:33:21 LOG7[5972:1472]: https accepted FD=360 from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:1472]: Creating a new thread
2021.11.26 11:33:21 LOG7[5972:1472]: New thread created
2021.11.26 11:33:21 LOG7[5972:8548]: client start
2021.11.26 11:33:21 LOG7[5972:8548]: https started
2021.11.26 11:33:21 LOG7[5972:8548]: FD 360 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on local socket
2021.11.26 11:33:21 LOG5[5972:8548]: https connected from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:8548]: FD 428 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: https connecting
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: waiting 10 seconds
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: connected
2021.11.26 11:33:21 LOG7[5972:8548]: Remote FD=428 initialized
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on remote socket
2021.11.26 11:33:21 LOG7[5972:8548]: start SSPI connect
2021.11.26 11:33:21 LOG5[5972:8548]: try to read the client certificate
2021.11.26 11:33:21 LOG7[5972:8548]: open file c:stunnelclicer.cer with certificate
2021.11.26 11:33:21 LOG5[5972:8548]: CertFindCertificateInStore not find client certificate in store CURRENT_USER. Looking at LOCAL_MACHINE
2021.11.26 11:33:21 LOG3[5972:8548]: Error 0x80092004 returned by CertFindCertificateInStore
кто-то сталкивался с таким?
буду благодарен за помощь!
Источник
Stunnel error 0x8009035d returned by initializesecuritycontext 2
Добрый день! Уважаемые читатели и гости 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
Где хранится самоподписный сертификат в реестре
Это больше для себя, где лежит отпечаток сертификата:
Источник
Stunnel error 0x8009035d returned by initializesecuritycontext 2
Важное замечание: Если ОС Windows используется в качестве клиента КриптоПро HSM 2.0 и ключ доступа к HSM записан на смарткарте или токене, то не рекомендуется подключение к этой ОС Windows по RDP, поскольку локально подключенные к компьютеру с ОС Windows считыватели смарткарт/токенов не будут доступны в RDP-сессии.
- Диагностика соединения с HSM 2.0
- проверка провайдера
windows : start /b csptest -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info для треевого провайдера, для сервисного необходимо в -provider указывать «Crypto-Pro GOST R 34.10-2012 HSM Svc CSP»
*nix : /opt/cprocsp/bin/АРХИТЕКТУРА/csptestf -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info
должно вернуться [ErrorCode: 0x00000000], иначе см п.2-3
- диагностика с помощью telnet или netcat
доступ к web-странице Администратора:
telnet 443
доступ к каналу К2:
telnet 1501
где это IP адрес HSM 2.0
Причина возможного сбоя: HSM в состоянии Inactive, сетевая проблема или не настроены правила FireWall на HSM 2.0
примечание: на ОС Astra Linux Smolensk 1.5 — 1.6 по умолчанию не установлены пакеты telnet и netcat (можно установить с диска разработчика Astra Linux)
Пример использования:
telnet 192.168.26.2 1501
nc -v 192.168.26.2 1501
- Сервер RPC не доступен
[ErrorCode: 0x000006ba]
Причина: не запущена служба Крипто Про HSM 2.0Указанный тип ресурса в файле образа отсутствует
[ErrorCode: 0x00000715]
Причина: нет доступа к закрытому ключу в реестре локального компьютера
для х64: HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCrypto ProSettingsKeys
для х32: HKEY_LOCAL_MACHINESOFTWARECrypto ProSettingsKeys[ErrorCode: 0x8010002e]
Причина: считыватель отключен или используется RDPТребуемый адрес для своего контекста неверен
[ErrorCode: 0x00002741]
Причина: не указан IP адрес HSM 2.0 в HSM Client[ErrorCode: 0x80090304]
Причина: на контейнер ключевой пары доступа установлен пин-код отличный от 11111111[ErrorCode: 0x800b0109]
Причина: корневой сертификат HSM 2.0 не установлен в хранилище «Доверенные корневые центры сертификации» локального компьютерапри попытке установить соединение из HSM клиента (в трее), после предложения ввести ПИН-код появляется сообщение
«CN-имя сертификата не совпадает с полученным значением»
Причина: не заменен TLS — сертификат Веб-сервера HSM после смены IP адреса HSM
Решение:
1)Необходимо перевыпустить веб-сертификат в режиме Active – update keys – tls server key – change TLS key
2)HSM необходимо переактивировать: Change HSM state – inactive – Full activeна *nix клиенте в логе stunnel имеется строка:
Error 0x80090304 returned by InitializeSecurityContext
Возможные причины: закончилась лицензия на Крипто Про CSP или недоступен закрытый ключ ключевой пары доступа - на *nix клиенте при тестировании ГОСТ TLS имеется строка:
Downgrade container security level?
Решение: необходимо понизить класс защиты контейнера ключевой пары доступа через тестирование контейнера
Пример: /opt/cprocsp/bin/amd64/csptest -keys -check -cont ‘\.Gemalto PC Twin Readercontname’
- на страничке не работают пункты меню и отображается строка вида:
-1 -1 0 0 0 0 0 0 false false false
Причина:
Используется браузер отличный от Internet Explorer или в IP адрес HSM 2.0 не добавлен в «Доверенные узлы» и в «Просмотр в режиме совместимости» браузера Internet ExplorerИсточник
Semen_Se |
|
Статус: Новичок Группы: Участники
|
Доброго времени суток! Настраиваю интеграцию с ГИИС ДМДК, сделал все как в инструкции. Служба запускается, но связи нет и в логах следующее: Пробовал и х64, и win32 — результата нет В один момент решил скачать и запустить stunnel_msspi.exe — первый раз вышло окно с логом [server down], Сейчас я уже совсем в растерянности и не могу понять при каких условиях вообще связь появляется. (пока писал пост, решил проверить и запустил stunnel_msspi.exe двойным кликом — запустился зеленым в трее, Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей? |
|
|
two_oceans |
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Добрый день. Цитата: E_NO_CREDENTIALS: 0x8009030e Цитата: Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей? Полагаю, проблема в отсутствии прав пользователя, под которым запускается служба, на контейнер или в отсутствии сертификата в хранилище компьютера. Вкратце, если служба запускается под локальной системой, то хранить контейнер в реестре не выйдет. Как самый простой вариант, можно изменить пользователя, под которым запускается служба, на текущего (из-под которого работает запуск двойным кликом). Однако использование текущего пользователя для служб не рекомендовано из-за риска повредить реестр при внезапной остановке службы. Еще может быть не установлен криптопровайдер уровня ядра, он нужен для доступа к ключам гост из служб. Попробуйте «изменить» установку Криптопро CSP и проверить, что этот компонент установлен. Рекомендовано такое: скопировать контейнер вместо Реестра на другой считыватель (флешка/токен/несистемный раздел диска/Директория); установить сертификат в хранилище компьютера со ссылкой на контейнер компьютера (это можно сделать, перезапустив панель управления КриптоПро в режиме администратора и выбрав переключатель «компьютера»). Далее дать права на него через остнастку сертификаты (локальный компьютер — хранилище Личное — правой кнопкой мыши по нужному сертификату — все задачи — управление закрытыми ключами — дать нужному пользователю (системе, например) полные права). После этого служба сможет найти ключ и использовать его. Двойным же кликом Вы запускаете от текущего пользователя для которого сертификат и контейнер установлены и доступны — значок зеленый. Если на компьютере не требуется работа тоннеля когда никто не залогинен, то можно убрать службу, а ярлык на stunnel_msspi.exe закинуть в автозагрузку. По поводу «не всегда запускается» дело возможно в том, что служба и приложение используют один конфиг и слушают один порт (ну 1С же настроен на конкретный порт). С этим есть ограничение сокетов в Windows — 2 процесса не смогут слушать один и тот же адрес:порт, один из них завершается с ошибкой, что порт уже занят. Следовательно, хороший шанс что порт займет служба (не имеющая доступа к ключу), а завершится приложение (если stunnel_msspi вообще автозапускается) (который имеет доступ к ключу) и ничего работать не будет. Нужно из разнести на разные порты или оставить что-то одно. Отредактировано пользователем 10 марта 2022 г. 1:54:58(UTC) |
|
|
Пользователи, просматривающие эту тему |
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
- Remove From My Forums
-
Question
-
Hi all,
I have a SCCM R2 Windows 2008 System that has been functioning great! I have setup AMT in the past successfully however I am having difficulty getting our vPro systems Provisioned on SCCM. At this point, none are provisioned. I have all the required
pre-req’s in place and i have installed our external GoDaddy cert successfully as well…The server is attempting to provision the systems, but fais with the following error:
Failed to create SSPI credential with error=0x8009030E by AcquireCredentialsHandle.
Very little information can be found for this specific error code but from what i could find it points to the SSL cert.
I created my CSR to GoDaddy using OpenSSL (openssl.exe) and i I rcvd two files from GoDaddy. My Provisioning «.cer» and their Root Chain. I needed the «.cer» to be in «.pfx» (12) format so I used openssl and created a pfx using
my private key that accompanied the initial request when i first generated and then sent the information to GoDaddy. and imported the pfx into SCCM successfullyI’m pretty sure my request was properly formatted (they require 2048 bit now) but i do have my private key so is there a way to attach/import that into the Local Computer Store (where the public key already is) and then export to .pfx to try that?
I have attached a screen shot of the «Start Task» to «End Task»
You can also
download the screen shot hereHas anybody expierenced this before? Any help is appreciated ! THanks!
Answers
-
*********RESOLVED**********
Short Answer — The Root CA Chain needs to be included in the PFX file you use for SCCM / WS Man Trans
Answer — This was the first time I used OpenSSL binaries to create the cert request to the 3rd party cert provider. Not a problem….It worked and i rcvd two files back…The .CER file and the Certificate Root Chain. Since I used OpenSSL to create the request,
i had to use OpenSSL to convert the CER into a PFX using the Private Key i initially created via OpenSLL. Once you convert the CER into a PFX, you need to import all 3 files (CER, Root Chain, and PFX) into the Local Computer Store. Once its imported, you need
to Right Click on the Provisiong Cert (PFX) and select export. There will be an option for «Export all certificates in the chain if possible» or something along the lines of that. Once the export is complete, the PFX file you now exported is the PFX file you
will use in SCCM and WSMan Trans.The problem i had was that I didnt include the cert root chain when converting my CER into PFX using OpenSSL….Once i imported / exported from the Windows Local Computer Store, the gates opened and within 15 min i see them all coming into the AD OU i created
and all is well!!!For anyone interested, the commands i used to request and subsquently convert the cer into a PFX are as follows:
REQUEST — openssl.exe req -config YOUROWN.cfg -new -keyout private.pem -out request.pem -days 365
CONVERT to PFX — openssl.exe pkcs12 -export -in PROVISIONCERT.pem -inkey private.pem -out FINALPROVCERT.pfx -name «Intel vPro» -password «pass:XXXXXXX»
-
Marked as answer by
Tuesday, May 18, 2010 4:33 PM
-
Marked as answer by
Comments
bagder
changed the title
winbuild: http digest authentication not working with algorithm set as SHA256 in header but working with less secure MD5 and MD5-sess
winbuild: http digest authentication not working with SHA-256
Dec 11, 2020
jay
added a commit
to jay/curl
that referenced
this issue
Dec 13, 2020
The error is shown with infof rather than failf so that the user will see the extended error message information only in verbose mode, and will still see the standard CURLE_AUTH_ERROR message. For example: --- * schannel: InitializeSecurityContext failed: SEC_E_QOP_NOT_SUPPORTED (0x8009030A) - The per-message Quality of Protection is not supported by the security package * multi_done * Connection curl#1 to host 127.0.0.1 left intact curl: (94) An authentication function returned an error --- Ref: curl#6302 Closes #xxxx
jay
mentioned this issue
Dec 13, 2020
jay
added a commit
that referenced
this issue
Dec 14, 2020
The error is shown with infof rather than failf so that the user will
see the extended error message information only in verbose mode, and
will still see the standard CURLE_AUTH_ERROR message. For example:
---
* schannel: InitializeSecurityContext failed: SEC_E_QOP_NOT_SUPPORTED
(0x8009030A) - The per-message Quality of Protection is not supported by
the security package
* multi_done
* Connection #1 to host 127.0.0.1 left intact
curl: (94) An authentication function returned an error
---
Ref: #6302
Closes #6315
jay
added a commit
that referenced
this issue
Dec 14, 2020
jay
mentioned this issue
Nov 30, 2022
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
Добрый день Настраиваю TLS на Windows 10 и Крипто Про 4.0.9914. Лицензия на CSP серверная. Что это за ошибка и как ее побороть? В eventlog чисто. |
|
|
Максим Коллегин |
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Что за сервер? IE работает правильно? |
Знания в базе знаний, поддержка в техподдержке |
|
|
WWW |
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
Сервер самописанный. IE тоже не работает, но тут дело не в клиенте, так как этим браузером нормально цепляемся к стенду на линуксе. То есть браузер и клиентский сертификат корректные. |
|
|
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
Эта ошибка возникает при вызове функции QueryContextAttributes с SECPKG_ATTR_REMOTE_CERT_CONTEXT |
|
|
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
Сделал сертификат с CN, совпадающим с именем хоста (localhost). Теперь соединение просто рвется, а Fox v31 выдает: Fox 45: Fox v.24 устанавливает https без предоставления клиентского сертификата. При попытке его получить сервер выдает ошибку. В общем все браузеры работают по-разному. Отредактировано пользователем 3 октября 2017 г. 21:33:40(UTC) |
|
|
Максим Коллегин |
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Кажется, что клиент тут ни при чем. Вы как на сервере требуете клиентскую аутентификацию? Нужно в Accept передать флаг Mutual. |
Знания в базе знаний, поддержка в техподдержке |
|
|
WWW |
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
В функцию AcceptSecurityContext мы передаем |
|
|
Роман кислухин |
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
В общем проблема оказалась в том, что серверный сертификат был выпущен на localhost. Как только выпустили на другое имя и прописали его в hosts чтобы клиент находил сервер, сразу заработало. Но заработало только в IE. Fox после выбора клиентского сертификата выпадает в ошибку security library: invalid algorithm. Отредактировано пользователем 10 октября 2017 г. 18:49:08(UTC) |
|
|
Пользователи, просматривающие эту тему |
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
There are many posts online listing many different possible causes for these errors, so it’s not possible for this article to encompass all the solutions. These are just solutions to common causes for these errors. If the suggestions listed here don’t work for you, please email support at support@nsoftware.com
Errors
- 80090302
- 8009030D
- 8009030E
- 80090304
- 80090308
- 80090325
- 80090326
- 80090327
- 80090331
- 8009035D
- 8009030F and 80090321
This error can occur when the component is using an older version of TLS, but the server requires a newer version. For instance if the component is using TLS 1.0, but the server requires TLS 1.2, you can see this error. Older versions of the components may not have the newer protocols enabled by default. In the current versions TLS 1.2 is enabled by default.
- Enable Supported Protocol Versions
This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this
icharge1.Config("SSLEnabledProtocols=4032");
Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.
Possible Solutions
This error is often seen when using PEM keys, and translates to «The credentials supplied to the package were not recognized».
- Translate the PEM file into a PFX file.
Using OpenSSL, the certificate can be converted with the command:
openssl pkcs12 -export -passout pass:"" -in cert_key_pem.txt -out cert_key_out.pfx -name "My Certificate"
Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.
- Ensure the Network Service account has access to «C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSA.»
- If using a certificate from a Windows certificate store verify the certificate was imported wit the «Mark this key as exportable» option checked.
- If you are running the components from IIS, ensure that the Application Pool has Load User Profile set to true.
Possible Solutions
This error translates to «No credentials are available in the security package».
- When using a certificate for client authentication, ensure the certificate’s private keys are accessible.
The certificate in the Windows certificate store must contain the corresponding private keys, and be marked as exportable. - Ensure that the current user and administrators have full access to «C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSAMachineKeys».
- Import the certificates directly into both LOCAL_MACHINEPersonal and ADAMPersonal if ADAM is installed.
Possible Solutions
This error translates to «The Local Security Authority cannot be contacted «.
- This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200.
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman
After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.
- Additional reasons and solutions for this problem are detailed in Microsoft KB 813550
This error translates to «The token supplied to the function is invalid «.
- The server is using a certificate with an outdated signature algorithm. See this MSDN Article
- The server doesn’t expect SSL over this port.
Set the SSLStartMode property to sslExplicit. - FileZilla and other FTP servers require a PROT P command to be sent for the data connection when using implicit SSL.
Set the UseProtWhenImplicit configuration setting to True. - The server returns a large number of CA’s in the handshake.
Possible Causes
Also see this Knowledge Base article about this error: SSL: Error During Handshake: 80090308
This error translatest to «The certificate chain was issued by an authority that is not trusted.»
The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.
This error translates to «The message received was unexpected or badly formatted.»
- This error may also happen if the server and client don’t posses a common supported cipher suite. This can be the case if you’re connecting from Windows XP to a site that has recent/strict security requirements. Here is a list of ciphers supported in XP. Setting UseInternalSecurityAPI to true may help with this error as it supports many newer protocols not supported on older systems.
- Client authentication is required. Ensure that you are loading the certificate correctly.
- The server does not support the SSL Client Hello version being used. Set the SSLEnabledProtocols configuration setting to an appropriate value.
- The server does not support SSL session re-use. You can disable this by setting the ReuseSSLSession and/or ReuseSSLSessionInDI configuration setting to false.
- The server returns SSL handshake packets larger than 16K. This is a CryptoAPI limitation.
Possible Solutions
In ThreeDSecure, this error is typically related to a problem with client authentication.
This error translates to «An unknown error occurred while processing the certificate.»
This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.
This error translates to «The client and server cannot communicate, because they do not possess a common algorithm».
Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn’t support the newer ciphers required by the server. Here is a list of ciphers supported in XP.
This error translates to «One or more of the parameters passed to the function was invalid.»
- Similar to 80090304, this error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200.
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman
After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.
-
The below Windows updates have been known to cause the issue:
- KB3172605
- KB3175024
- KB3177186
- KB3184122
- KB3185911
- Additional reasons and solutions for this problem are detailed in Microsoft KB 813550
Possible Solutions
These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.
Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:
- Use our internal security API by passing the string «UseInternalSecurityAPI=True» to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
- Disable the two cipher suites mentioned above
- Disable support for TLS 1.2
- Upgrade your machine to a newer version of Windows
We appreciate your feedback. If you have any questions, comments, or
suggestions about this entry please contact our support team at
kb@nsoftware.com.