Error 0x8009030e authenticating server credentials

Добрый день, Пытаюсь настроить взаимодейтсвие с ФинЦЕРТ через stunnel установил согласно регламенту ФинЦЕРТ сертификаты из архива: http://cbr.ru/StaticHtml/File/14408/ASOI_docs.zip Приложил лог с...

Offline

Boris7772

 


#1
Оставлено
:

24 ноября 2020 г. 12:47:18(UTC)

Boris7772

Статус: Новичок

Группы: Участники

Зарегистрирован: 21.11.2020(UTC)
Сообщений: 3

Добрый день,

Пытаюсь настроить взаимодейтсвие с ФинЦЕРТ через stunnel установил согласно регламенту ФинЦЕРТ сертификаты из архива: http://cbr.ru/StaticHtml/File/14408/ASOI_docs.zip

Приложил лог с ошибкой и конфигурацию stunnel. Использую stunnel из CSP 4.0.9963

Конфигурация stunnel
setgid = stunnel
setuid = stunnel
pid=/var/opt/cprocsp/tmp/stunnel_cli.pid
output=/var/opt/cprocsp/tmp/stunnel_cli.log
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 7

[portal]
client=yes
accept = localhost:8181
connect = portal.fincert.cbr.ru:443
verify=2

Лог с проблемой:

Цитата:

2020.11.24 12:30:44 LOG3[1123:140439079679744]: Error 0x8009030e returned by VerifyCertChain
2020.11.24 12:30:44 LOG3[1123:140439079679744]: **** Error 0x8009030e authenticating server credentials!
2020.11.24 12:30:44 LOG5[1123:140439079679744]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2020.11.24 12:30:44 LOG7[1123:140439079679744]: free Buffers
2020.11.24 12:30:44 LOG7[1123:140439079679744]: delete c->hContext
2020.11.24 12:30:44 LOG7[1123:140439079679744]: delete c->hClientCreds
2020.11.24 12:30:44 LOG5[1123:140439079679744]: incomp_mess = 0, extra_data = 0
2020.11.24 12:30:44 LOG7[1123:140439079679744]: portal finished (0 left)
2020.11.24 12:30:54 LOG7[1123:140439079688000]: portal accepted FD=8 from ::1:48772
2020.11.24 12:30:54 LOG7[1123:140439079679744]: client start
2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal started
2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 8 in non-blocking mode
2020.11.24 12:30:54 LOG7[1123:140439079679744]: TCP_NODELAY option set on local socket
2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 10 in non-blocking mode
2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 11 in non-blocking mode
2020.11.24 12:30:54 LOG7[1123:140439079679744]: Connection from ::1:48772 permitted by libwrap
2020.11.24 12:30:54 LOG5[1123:140439079679744]: portal connected from ::1:48772
2020.11.24 12:30:54 LOG7[1123:140439079688000]: Cleaning up the signal pipe
2020.11.24 12:30:54 LOG6[1123:140439079688000]: Child process 1739 finished with code 0
2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 16 in non-blocking mode
2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal connecting
2020.11.24 12:30:54 LOG7[1123:140439079679744]: connect_wait: waiting 10 seconds
2020.11.24 12:30:54 LOG7[1123:140439079679744]: connect_wait: connected
2020.11.24 12:30:54 LOG7[1123:140439079679744]: Remote FD=16 initialized
2020.11.24 12:30:54 LOG7[1123:140439079679744]: TCP_NODELAY option set on remote socket
2020.11.24 12:30:54 LOG7[1123:140439079679744]: start SSPI connect
2020.11.24 12:30:54 LOG3[1123:140439079679744]: Credentials complete
2020.11.24 12:30:54 LOG7[1123:140439079679744]: 113 bytes of handshake data sent
2020.11.24 12:30:54 LOG5[1123:140439079679744]: 2018 bytes of handshake(in handshake loop) data received.
2020.11.24 12:30:54 LOG5[1123:140439079679744]: 215 bytes of handshake data sent
2020.11.24 12:30:54 LOG5[1123:140439079679744]: 31 bytes of handshake(in handshake loop) data received.
2020.11.24 12:30:54 LOG5[1123:140439079679744]: Handshake was successful
2020.11.24 12:30:54 LOG5[1123:140439079679744]: PerformClientHandshake finish
2020.11.24 12:30:54 LOG5[1123:140439079679744]: Server subject: 1.2.643.100.111=»#0C818AD0A1D0A0D095D094D0A1D0A2D092D09E20D09AD0A0D098D09FD0A2D09ED093D0A0D090D0A4D098D0A7D095D0A1D09AD09ED09920D097D090D0A9D098D0A2D0AB20D098D09DD0A4D09ED0A0D09CD090D0A6D098D0982022D09AD09ED09DD0A2D098D09DD095D09DD0A220544C532DD0A1D095D0A0D092D095D0A02220D092D095D0A0D0A1D098D0AF2032″, C=RU, L=Москва, O=CBR, OU=Центр мониторинга и реагирования на компьютерные атаки ЦБ РФ, STREET=»ул.Неглинная, д.12″, CN=portal.fincert.cbr.ru, E=info_fincert@cbr.ru
2020.11.24 12:30:54 LOG5[1123:140439079679744]: Server issuer: DC=ru, DC=cbr, DC=region, OU=PKI, OU=GUBZI, CN=ROOTsvc-CA
2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x10000 ((unknown)) returned by CertVerifyCertificateChainPolicy!
2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x10000 when validate certificate

2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x8009030e returned by VerifyCertChain
2020.11.24 12:30:54 LOG3[1123:140439079679744]: **** Error 0x8009030e authenticating server credentials!
2020.11.24 12:30:54 LOG5[1123:140439079679744]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2020.11.24 12:30:54 LOG7[1123:140439079679744]: free Buffers
2020.11.24 12:30:54 LOG7[1123:140439079679744]: delete c->hContext
2020.11.24 12:30:54 LOG7[1123:140439079679744]: delete c->hClientCreds
2020.11.24 12:30:54 LOG5[1123:140439079679744]: incomp_mess = 0, extra_data = 0
2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal finished (0 left)

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

Отредактировано пользователем 24 ноября 2020 г. 18:01:23(UTC)
 | Причина: Не указана


Вверх


Offline

Михаил Селезнёв

 


#2
Оставлено
:

24 ноября 2020 г. 17:52:02(UTC)

Михаил Селезнёв

Статус: Сотрудник

Группы: Участники

Зарегистрирован: 05.04.2017(UTC)
Сообщений: 354
Мужчина
Российская Федерация

Сказал «Спасибо»: 3 раз
Поблагодарили: 49 раз в 49 постах

Добрый день!
Приложенные файлы пустые. Прошу запаковать их в архив.


Вверх


Offline

Boris7772

 


#3
Оставлено
:

24 ноября 2020 г. 18:02:28(UTC)

Boris7772

Статус: Новичок

Группы: Участники

Зарегистрирован: 21.11.2020(UTC)
Сообщений: 3

Автор: Михаил Селезнёв Перейти к цитате

Добрый день!
Приложенные файлы пустые. Прошу запаковать их в архив.

Что-то не удалось загрузить файлы нормально, опубликовал лог и конфигурацию в посте


Вверх


Offline

Nikolay Batischev

 


#4
Оставлено
:

24 ноября 2020 г. 18:13:58(UTC)

Nikolay

Статус: Сотрудник

Группы: Участники

Зарегистрирован: 06.11.2013(UTC)
Сообщений: 70
Мужчина
Албания
Откуда: Тирана

Сказал «Спасибо»: 3 раз
Поблагодарили: 11 раз в 11 постах

Добрый день!
Нужно установить корневой сертификат от сертификата в доверенное хранилище.
Или в конфиге использовать verify =0


Вверх


Offline

Boris7772

 


#5
Оставлено
:

24 ноября 2020 г. 18:26:15(UTC)

Boris7772

Статус: Новичок

Группы: Участники

Зарегистрирован: 21.11.2020(UTC)
Сообщений: 3

Автор: Nikolay Batischev Перейти к цитате

Добрый день!
Нужно установить корневой сертификат от сертификата в доверенное хранилище.
Или в конфиге использовать verify =0

Установил этот параметр в 0, ошибка ушла спасибо, запросы к сервису стали отбиваться с 421 статусом, это я так понимаю уже внешняя проблема?

Лог при этом следующий:
2020.11.24 18:28:35 LOG7[23480:139871409022784]: portal accepted FD=8 from 192.168.24.98:59128
2020.11.24 18:28:35 LOG7[23480:139871409014528]: client start
2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal started
2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 8 in non-blocking mode
2020.11.24 18:28:35 LOG7[23480:139871409014528]: TCP_NODELAY option set on local socket
2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 9 in non-blocking mode
2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 11 in non-blocking mode
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Connection from 192.168.24.98:59128 permitted by libwrap
2020.11.24 18:28:35 LOG5[23480:139871409014528]: portal connected from 192.168.24.98:59128
2020.11.24 18:28:35 LOG7[23480:139871409022784]: Cleaning up the signal pipe
2020.11.24 18:28:35 LOG6[23480:139871409022784]: Child process 24405 finished with code 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 15 in non-blocking mode
2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal connecting
2020.11.24 18:28:35 LOG7[23480:139871409014528]: connect_wait: waiting 10 seconds
2020.11.24 18:28:35 LOG7[23480:139871409014528]: connect_wait: connected
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Remote FD=15 initialized
2020.11.24 18:28:35 LOG7[23480:139871409014528]: TCP_NODELAY option set on remote socket
2020.11.24 18:28:35 LOG7[23480:139871409014528]: start SSPI connect
2020.11.24 18:28:35 LOG3[23480:139871409014528]: Credentials complete
2020.11.24 18:28:35 LOG7[23480:139871409014528]: 118 bytes of handshake data sent
2020.11.24 18:28:35 LOG5[23480:139871409014528]: 1975 bytes of handshake(in handshake loop) data received.
2020.11.24 18:28:35 LOG5[23480:139871409014528]: 215 bytes of handshake data sent
2020.11.24 18:28:35 LOG5[23480:139871409014528]: 31 bytes of handshake(in handshake loop) data received.
2020.11.24 18:28:35 LOG5[23480:139871409014528]: Handshake was successful
2020.11.24 18:28:35 LOG5[23480:139871409014528]: PerformClientHandshake finish
2020.11.24 18:28:35 LOG5[23480:139871409014528]: Verify_level = 0, skipping Server certificate verification
2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool
2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=0,want_rd = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer
2020.11.24 18:28:35 LOG7[23480:139871409014528]: data reciev from socket = 116
2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool
2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=116,want_rd = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer
2020.11.24 18:28:35 LOG5[23480:139871409014528]: SSPI_write start
2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_write data is GET
2020.11.24 18:28:35 LOG7[23480:139871409014528]: send all data after encrypt
2020.11.24 18:28:35 LOG7[23480:139871409014528]: data send to ssl_socket =116
2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool
2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=0,want_rd = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer
2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read start
2020.11.24 18:28:35 LOG7[23480:139871409014528]: recv ok on SSPI_read err= 324
2020.11.24 18:28:35 LOG5[23480:139871409014528]: Received 324 bytes from ssl socket
2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read data in ssl_buff is HTTP
2020.11.24 18:28:35 LOG7[23480:139871409014528]: data read from ssl_sock =315
2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool
2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 315,c->sock_ptr=0,want_rd = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: add write socket to poll
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer
2020.11.24 18:28:35 LOG7[23480:139871409014528]: data send to socket = 315
2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read start
2020.11.24 18:28:35 LOG7[23480:139871409014528]: recv ok on SSPI_read err= 0
2020.11.24 18:28:35 LOG3[23480:139871409014528]: recv return 0 and ask more but there is not complete data for decrypt. Peer disconnected?
2020.11.24 18:28:35 LOG5[23480:139871409014528]: SSPI_read: read socket closed
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Socket write shutdown
2020.11.24 18:28:35 LOG7[23480:139871409014528]: c->ssl_ptr = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer
2020.11.24 18:28:35 LOG3[23480:139871409014528]: readsocket: Connection reset by peer (104)
2020.11.24 18:28:35 LOG5[23480:139871409014528]: Connection reset: 116 bytes sent to SSL, 315 bytes sent to socket
2020.11.24 18:28:35 LOG7[23480:139871409014528]: free Buffers
2020.11.24 18:28:35 LOG7[23480:139871409014528]: delete c->hContext
2020.11.24 18:28:35 LOG7[23480:139871409014528]: delete c->hClientCreds
2020.11.24 18:28:35 LOG5[23480:139871409014528]: incomp_mess = 2, extra_data = 0
2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal finished (0 left)

Отредактировано пользователем 24 ноября 2020 г. 18:29:32(UTC)
 | Причина: Не указана


Вверх

Пользователи, просматривающие эту тему

Guest (3)

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.


Offline

Иван Бахтин

 


#1
Оставлено
:

4 апреля 2022 г. 15:11:58(UTC)

Иван Бахтин

Статус: Участник

Группы: Участники

Зарегистрирован: 24.02.2021(UTC)
Сообщений: 18
Российская Федерация
Откуда: Сыктывкар

Сказал(а) «Спасибо»: 5 раз

Здравствуйте!
Пытаюсь наладить интеграцию с ГИС ЖКХ через их API + stunnel. И выходит ошибка Error 0x8009030e returned by VerifyCertChain.

Установленный сертификат:

Настройки stunnel.conf:

Вывод log stunnel:

Так же хочу сказать, что проверил сертификаты на совпадение (т.е. установленный у меня и передаваемый с сервера ГИС ЖКХ) утилитой /opt/cprocsp/bin/amd64/csptest, сертификаты совпадают.

Подскажите, пожалуйста, где я допустил ошибку и как её исправить?
Спасибо!


Вверх


Offline

two_oceans

 


#2
Оставлено
:

5 апреля 2022 г. 7:20:56(UTC)

two_oceans

Статус: Эксперт

Группы: Участники

Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,598
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 388 раз в 363 постах

Добрый день.
Вижу 2 варианта исправления: 1) verify=0 и не задаваться таким неблагодарным делом как проверка сертификата, выданного тестовым УЦ. Имитировать такое сложное API как у ГИС ЖКХ — сомневаюсь, что хакеры будут. Если работает, значит это подлинная ГИС ЖКХ. Серьезно, добавлять тестовый УЦ в доверенные представляет намного больший риск чем игнорировать проверку сертификата сервера. Отключение проверки действует только на конкретное соединение, а тестовый УЦ неизвестно где потом вылезет. Если ГИС ЖКХ реально хотят безопасности, то они должны серверный сертификат получить у Минцифры, а не вот эту подделку для галочки. Для тестовых соединений так точно стоит ставить verify=0, так как там реальных персональных данных не передается.

2) в строке CAFile по идее должен быть не сам сертификат сервера, а список сертификатов УЦ, выдавшего сертификат серверу. В случае тестового УЦ КриптоПро это обычно 2 сертификата от корневого и промежуточного УЦ. Обычно это выглядит как:

Код:

===== BEGIN TRUSTED CERTIFICATE =====
сертификат 1
===== END TRUSTED CERTIFICATE =====
===== BEGIN TRUSTED CERTIFICATE =====
сертификат 2
===== END TRUSTED CERTIFICATE =====

заголовки могут немного отличаться смотря какая версия stunnel и openssl

Отредактировано пользователем 5 апреля 2022 г. 7:27:39(UTC)
 | Причина: Не указана


Вверх

thanks 1 пользователь поблагодарил two_oceans за этот пост.

Иван Бахтин

оставлено 05.04.2022(UTC)


Offline

Иван Бахтин

 


#3
Оставлено
:

5 апреля 2022 г. 11:51:18(UTC)

Иван Бахтин

Статус: Участник

Группы: Участники

Зарегистрирован: 24.02.2021(UTC)
Сообщений: 18
Российская Федерация
Откуда: Сыктывкар

Сказал(а) «Спасибо»: 5 раз

Автор: two_oceans Перейти к цитате

Добрый день.
Вижу 2 варианта исправления: 1) verify=0 и не задаваться таким неблагодарным делом как проверка сертификата, выданного тестовым УЦ. Имитировать такое сложное API как у ГИС ЖКХ — сомневаюсь, что хакеры будут. Если работает, значит это подлинная ГИС ЖКХ. Серьезно, добавлять тестовый УЦ в доверенные представляет намного больший риск чем игнорировать проверку сертификата сервера. Отключение проверки действует только на конкретное соединение, а тестовый УЦ неизвестно где потом вылезет. Если ГИС ЖКХ реально хотят безопасности, то они должны серверный сертификат получить у Минцифры, а не вот эту подделку для галочки. Для тестовых соединений так точно стоит ставить verify=0, так как там реальных персональных данных не передается.

2) в строке CAFile по идее должен быть не сам сертификат сервера, а список сертификатов УЦ, выдавшего сертификат серверу. В случае тестового УЦ КриптоПро это обычно 2 сертификата от корневого и промежуточного УЦ. Обычно это выглядит как:

Код:

===== BEGIN TRUSTED CERTIFICATE =====
сертификат 1
===== END TRUSTED CERTIFICATE =====
===== BEGIN TRUSTED CERTIFICATE =====
сертификат 2
===== END TRUSTED CERTIFICATE =====

заголовки могут немного отличаться смотря какая версия stunnel и openssl

Большое спасибо! С verify=0 запросы проходят. Очень надеюсь, что на боевом сервере с verify=2 всё будет работать. :)


Вверх

Пользователи, просматривающие эту тему

Guest (2)

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Обновлено 19.06.2017

0x8009030E

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

Давайте подробнее посмотрим как она выглядит, я про 0x8009030E .

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

ошибка 0x8009030e

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

Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.

миграция виртуальных машин hyper v

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

миграция виртуальных машин hyper v

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

0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2-5

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

0x8009030E

Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер 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, то проверьте, что в свойствах хоста

0x8009030E

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

0x8009030E при миграции виртуальной машины

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

Move-VM <VMName> <Hyper-V-Servername> -IncludeStorage -DestinationStoragePath D:Hyper-V<VMNameFolder>

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

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

Hi everyone, my name is Tobias Kathein and I’m a Senior Engineer in Microsoft’s Customer Success Unit. Together with my colleagues Victor Zeilinger, Serge Gourraud and Rodrigo Sanchez from Customer Service & Support we’re going to discuss a real-world scenario in which a customer was unable to live migrate Virtual Machines in his newly set up Hyper-V environment.

In our scenario the customer was trying to initiate a Live Migration for a Virtual Machine from a remote system. This is quite a common scenario, that administrators open the Hyper-V Management console on an administrative Remote Desktop Services server and initiate the Live Migration of a VM between two Hyper-V hosts. The customer got doubts whether this is even opposed to work. Just to rule this one out upfront. Yes, it is opposed to work.

The customer was complaining that this isn’t working for him in his environment even though he set up the delegation correctly and enabled Kerberos as authentication protocol for Live Migrations. The issue wasn’t with a particular Virtual Machine, as all, even newly created VMs failed to be moved to another host. No matter if the Hyper-V Management console or the PowerShell Cmdlet Move-VM is used both fail. The error message returned is “No credentials are available in the security package (0x8009030E)”. The full error message including some additional details is shown below.

BrandonWilson_0-1616784388020.png

Even though the red error message in PowerShell looks a little bit fancier, it is the same error message that is returned telling us that there are no suitable credentials available. So, you can be assured the issue is not with the Hyper-V Management console nor with the Move-VM Cmdlet, because neither of them is working.

BrandonWilson_1-1616784388054.png

There are multiple reasons why Live Migrations fail with the message “No Credentials are available in the security package (0x8009030E).”

The most known cause of this issue is the absence a correct Kerberos Constrained Delegation. Either Kerberos Delegation is missing completely or for single services like in this case for CIFS or the Microsoft Virtual System Migration Service. Also don’t mix up the Microsoft Virtual System Migration Service with the Microsoft Virtual Console Service which can happen quite easily when using ADUC to configure Constrained Delegation as you can see below. The default column size doesn’t show what’s what.

BrandonWilson_2-1616784388058.png

Finding out which Kerberos Delegation entries have been configured is a little bit unclear in the ADUC. An easier way to verify all required entries are present is to run the following PowerShell command.

get-adcomputer -Identity [ComputerAccount goes here] -Properties msDS-AllowedToDelegateTo | select -ExpandProperty msDS-AllowedToDelegateTo

Starting Windows Server 2016 there is the need to select “Use any authentication protocol” when setting up the Kerberos Delegation, instead of “Use Kerberos only”. This is due to some changes made in the operating system that require protocol transition. Protocol transition is only possible if the above-mentioned option is selected. On systems older than Windows Server 2016 selecting “Use Kerberos only” is sufficient. If “Use any authentication protocol” was not selected, Live Migration initiated from remote hosts will fail.

The error message also appears when trying to move a VM and the account that is being used to initiate the Live Migration is member of the Protected Users group. Members of this group automatically have non-configurable protections applied to their accounts. Among other things the user’s credentials are not allowed to be passed along and therefore Live Migration will not work when initiated from a remote system.

Another possibility why Live Migrations fail with this error message is when the user account being used to initiate the Live Migration has the option “Account is sensitive and cannot be delegated” set to enabled. This is sometimes configured to avoid highly privileged accounts to ensure that the credentials of these accounts cannot be forwarded by a trusted application to another computer or service. However, accounts having configured this setting cannot be used to initiate a Live Migration between two Hyper-V from a third machine.

BrandonWilson_3-1616784388061.png

And that’s it. We hope to have shed some light on this topic and the posting was helpful for you. Thanks for reading and never stop live migrating.

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Содержание

  1. Веб — сервис интеграции
  2. Веб — сервис интеграции
  3. Stunnel error 0x8009030e returned by acquirecredentialshandle
  4. Question
  5. Answers
  6. Stunnel error 0x8009030e returned by acquirecredentialshandle
  7. Вопрос
  8. Ответы
  9. Stunnel error 0x8009030e returned by acquirecredentialshandle
  10. Question
  11. Answers

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

2022.01.29 15:37:14 LOG7[48488:77600]: Creating a new thread

2022.01.29 15:37:14 LOG7[48488:77600]: New thread created

2022.01.29 15:37:14 LOG7[48488:67800]: client start

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT started

2022.01.29 15:37:14 LOG7[48488:67800]: FD 336 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on local socket

2022.01.29 15:37:14 LOG5[48488:67800]: Work_AT connected from 127.0.0.1:54057

2022.01.29 15:37:14 LOG7[48488:67800]: FD 412 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT connecting

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: waiting 10 seconds

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: connected

2022.01.29 15:37:14 LOG7[48488:67800]: Remote FD=412 initialized

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on remote socket

2022.01.29 15:37:14 LOG7[48488:67800]: start SSPI connect

2022.01.29 15:37:14 LOG5[48488:67800]: try to read the client certificate

2022.01.29 15:37:14 LOG7[48488:67800]: open file C:stunnelWork_AT.cer with certificate

2022.01.29 15:37:14 LOG3[48488:67800]: **** Error 0x8009030e returned by AcquireCredentialsHandle

2022.01.29 15:37:14 LOG3[48488:67800]: Credentials complete

2022.01.29 15:37:14 LOG3[48488:67800]: Error creating credentials

2022.01.29 15:37:14 LOG5[48488:67800]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

2022.01.29 15:37:14 LOG7[48488:67800]: free Buffers

2022.01.29 15:37:14 LOG5[48488:67800]: incomp_mess = 0, extra_data = 0

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT finished (0 left)

Источник

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

2022.01.29 15:37:14 LOG7[48488:77600]: Creating a new thread

2022.01.29 15:37:14 LOG7[48488:77600]: New thread created

2022.01.29 15:37:14 LOG7[48488:67800]: client start

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT started

2022.01.29 15:37:14 LOG7[48488:67800]: FD 336 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on local socket

2022.01.29 15:37:14 LOG5[48488:67800]: Work_AT connected from 127.0.0.1:54057

2022.01.29 15:37:14 LOG7[48488:67800]: FD 412 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT connecting

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: waiting 10 seconds

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: connected

2022.01.29 15:37:14 LOG7[48488:67800]: Remote FD=412 initialized

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on remote socket

2022.01.29 15:37:14 LOG7[48488:67800]: start SSPI connect

2022.01.29 15:37:14 LOG5[48488:67800]: try to read the client certificate

2022.01.29 15:37:14 LOG7[48488:67800]: open file C:stunnelWork_AT.cer with certificate

2022.01.29 15:37:14 LOG3[48488:67800]: **** Error 0x8009030e returned by AcquireCredentialsHandle

2022.01.29 15:37:14 LOG3[48488:67800]: Credentials complete

2022.01.29 15:37:14 LOG3[48488:67800]: Error creating credentials

2022.01.29 15:37:14 LOG5[48488:67800]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

2022.01.29 15:37:14 LOG7[48488:67800]: free Buffers

2022.01.29 15:37:14 LOG5[48488:67800]: incomp_mess = 0, extra_data = 0

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT finished (0 left)

Источник

Stunnel error 0x8009030e returned by acquirecredentialshandle

Question

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 successfully

I’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»

Has anybody expierenced this before? Any help is appreciated ! THanks!

Answers

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:

Источник

Stunnel error 0x8009030e returned by acquirecredentialshandle

Вопрос

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 successfully

I’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»

Has anybody expierenced this before? Any help is appreciated ! THanks!

Ответы

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:

Источник

Stunnel error 0x8009030e returned by acquirecredentialshandle

Question

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 successfully

I’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»

Has anybody expierenced this before? Any help is appreciated ! THanks!

Answers

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:

Источник

I have three servers.

Server A — Windows 2012 data center with Hyper-V role
Server B — Hyper-V 2012 server
Server C — Windows 2012 data center as SMB server

All servers are in the same domain that is a Windows 2003 domain controller. Both server A and B are configured for delegation to each other following the instructions from step by step as this page
http://technet.microsoft.com/en-us/library/jj134199.aspx (Configure and Use Live Migration on Non-clustered Virtual Machines). My account is a member of domain admins and is also added into
the local administators groups on the both servers.

When I tried to move a virtual machine from server A to server B, I got the following error.

————————————————————

Virtual machine migration operation failed at migration source.

Failed to establish a connection with host ‘serverB’: No credentials are available in the security package (0x8009030E).

The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host
is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.

[Expanded Information]
Virtual machine migration operation for ‘share-win7templ-diff1’ failed at migration source ‘serverA’. (Virtual machine ID 250EF943-3A89-4E30-8643-E01563AF3889)

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘serverB’: No credentials are available in the security package (0x8009030E).

Failed to authenticate the connection at the source host: no suitable credentials available.

————————————————————

Any advice is appreciated.

Содержание

  1. Stunnel error 0x8009030e authenticating server credentials
  2. Причины ошибки 0x8009030E
  3. Если у вас SCVMM
  4. Мигрируем через Powershell
  5. Веб — сервис интеграции
  6. Stunnel error 0x8009030e authenticating server credentials
  7. Вопрос
  8. Stunnel error 0x8009030e authenticating server credentials
  9. Question
  10. Answers
  11. Common Windows Security Errors
  12. Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
  13. Errors
  14. 0x80090302
  15. Possible Solutions
  16. 0x8009030D
  17. Possible Solutions
  18. 0x8009030E
  19. Possible Solutions
  20. 0x80090304
  21. 0x80090308
  22. Possible Causes
  23. 0x80090325
  24. 0x80090326
  25. Possible Solutions
  26. 0x80090327
  27. 0x80090331
  28. 0x8009035D
  29. Possible Solutions
  30. 0x8009030F or 0x80090321

Stunnel error 0x8009030e authenticating server credentials

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

Давайте подробнее посмотрим как она выглядит, я про 0x8009030E .

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

Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.

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

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

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

Для того чтобы kerberos отработал и вы не получили 0x8009030E при миграции виртуальной машины 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.

Источник

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

2022.01.29 15:37:14 LOG7[48488:77600]: Creating a new thread

2022.01.29 15:37:14 LOG7[48488:77600]: New thread created

2022.01.29 15:37:14 LOG7[48488:67800]: client start

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT started

2022.01.29 15:37:14 LOG7[48488:67800]: FD 336 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on local socket

2022.01.29 15:37:14 LOG5[48488:67800]: Work_AT connected from 127.0.0.1:54057

2022.01.29 15:37:14 LOG7[48488:67800]: FD 412 in non-blocking mode

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT connecting

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: waiting 10 seconds

2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: connected

2022.01.29 15:37:14 LOG7[48488:67800]: Remote FD=412 initialized

2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on remote socket

2022.01.29 15:37:14 LOG7[48488:67800]: start SSPI connect

2022.01.29 15:37:14 LOG5[48488:67800]: try to read the client certificate

2022.01.29 15:37:14 LOG7[48488:67800]: open file C:stunnelWork_AT.cer with certificate

2022.01.29 15:37:14 LOG3[48488:67800]: **** Error 0x8009030e returned by AcquireCredentialsHandle

2022.01.29 15:37:14 LOG3[48488:67800]: Credentials complete

2022.01.29 15:37:14 LOG3[48488:67800]: Error creating credentials

2022.01.29 15:37:14 LOG5[48488:67800]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

2022.01.29 15:37:14 LOG7[48488:67800]: free Buffers

2022.01.29 15:37:14 LOG5[48488:67800]: incomp_mess = 0, extra_data = 0

2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT finished (0 left)

Источник

Stunnel error 0x8009030e authenticating server credentials

Вопрос

I have three servers.

Server A — Windows 2012 data center with Hyper-V role
Server B — Hyper-V 2012 server
Server C — Windows 2012 data center as SMB server

All servers are in the same domain that is a Windows 2003 domain controller. Both server A and B are configured for delegation to each other following the instructions from step by step as this page http://technet.microsoft.com/en-us/library/jj134199.aspx (Configure and Use Live Migration on Non-clustered Virtual Machines). My account is a member of domain admins and is also added into the local administators groups on the both servers.

When I tried to move a virtual machine from server A to server B, I got the following error.

Virtual machine migration operation failed at migration source.

Failed to establish a connection with host ‘serverB’: No credentials are available in the security package (0x8009030E).

The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.

[Expanded Information]
Virtual machine migration operation for ‘share-win7templ-diff1’ failed at migration source ‘serverA’. (Virtual machine ID 250EF943-3A89-4E30-8643-E01563AF3889)

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘serverB’: No credentials are available in the security package (0x8009030E).

Failed to authenticate the connection at the source host: no suitable credentials available.

Источник

Stunnel error 0x8009030e authenticating server credentials

Question

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 successfully

I’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»

Has anybody expierenced this before? Any help is appreciated ! THanks!

Answers

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:

Источник

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.

  • 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.
  • 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.

  • Additional reasons and solutions for this problem are detailed in Microsoft KB 813550
  • 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

    Источник

    • Question

    • I am using the Live Connect SDK in my Windows 8 app. On one of my machines I am getting the following exception:

      No credentials are available in the security package (Exception from HRESULT: 0x8009030E)

      It is when I try to initialize the client:

      LiveLoginResult result = await this.client.InitializeAsync();

      What would cause this and how do I address it?

      -Steven

    All replies

    • I should add that if I sign out of the Microsoft account that it is failing with and log onto the machine with another live account it works fine. 

      I logged in with the failing account on another machine and it’s fine. 

      So, seems specific to this one account on one machine. 

    • Do you use the latest version of Live SDK (v5.4)?

      Did you get this issue when invoking InitializeAsync() and after you already invoked LoginAsync() successfully for the problem account?


      Lin Wang

    • It is v5.4.

      I create an instance of LiveAuthClient, then immediately call InitializeAsync(). The exception happens somewhere within InitializeAsync.

      I have successfully used the machine before with this account and it works find with this account on another machine. I’ve uninstalled and reinstalled the app, as well as restarted the machine.

      -Steven

      • Edited by

        Monday, October 7, 2013 9:52 PM

    • *poke* I am seeing this on multiple machines now.

    • I’m abandoning the usage of this SDK due to a complete lack of support for it.

      I’ve posted this issue a while ago, got a response but no follow up, and still can’t get any help a month later. I have no idea how to get some actual help with this issue. It’s 100% reproducible by me and I will not ship an app where a subset
      of users can’t even sign in.

      This has me alarmed, in general, for Windows 8 and it’s ecosystem.

    • I’m abandoning the usage of this SDK due to a complete lack of support for it.

      I’ve posted this issue a while ago, got a response but no follow up, and still can’t get any help a month later. I have no idea how to get some actual help with this issue. It’s 100% reproducible by me and I will not ship an app where a subset
      of users can’t even sign in.

      This has me alarmed, in general, for Windows 8 and it’s ecosystem.

      I am getting this error now with SDK 5.5 in exactly the same place. All I can add to this is I started using this account on a Windows Phone app I am developing with Live SDK also.

    Понравилась статья? Поделить с друзьями:

    Читайте также:

  • Error 0x80090308 returned by initializesecuritycontext 2
  • Error 0x80090304 the local security authority cannot be contacted
  • Error 0x80090304 returned by initializesecuritycontext
  • Error 0x80090304 returned by acquirecredentialshandle stunnel
  • Error 0x80090010 returned by initializesecuritycontext

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии