Сообщение об ошибке плохие данные 0x80090005 - Ремонт и установка крупной бытовой техники

DVAckom	#1 Оставлено : 28 апреля 2014 г. 12:33:59(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 27.05.2011(UTC) Сообщений: 102 Сказал(а) «Спасибо»: 17 раз Поблагодарили: 56 раз в 18 постах	В последнее время все чаще и чаще сталкиваемся с проблемой расшифровки сообщений в КриптоПро CSP 3.6. Раньше данная проблема возникала и лечилась переустановкой CSP. Но это были единичные случаи, и мы списывали их на естественные проблемы конкретных пользователей. В последние 3-4 месяца количество подобных обращений выросло значительно. Симптомы: CSP работает корректно при подписи, проверке подписи, шифровании. Только при расшифровке сообщений появляется ошибка «Плохие данные. (0x80090005)». Расшифровку проводили несколькими программными продуктами, включая КриптоАРМ. На всех продуктах одинаковая ошибка. Ошибка появляется на различных ОС и при различных антивирусах. В настоящий момент имеется один пользователь, у которого переустановка CSP проблему не решила (версия CSP 3.6.7777, Windows7, NOD32) и еще один у которого специально не переустанавливали CSP в надежде найти решение проблемы.

Molostvov	#2 Оставлено : 28 апреля 2014 г. 12:57:35(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 14.03.2013(UTC) Сообщений: 448 Откуда: Москва Сказал(а) «Спасибо»: 2 раз Поблагодарили: 95 раз в 85 постах	В Outlook может быть такое: У Пользователя1 по умолчанию выставлен RSA сертификат. Он пытается зашифровать и отправить письмо Пользователю2 с ГОСТ сертификатом по умолчанию. Пользователь1 получит ошибку «Ошибка на нижнем уровне системы безопасности. Плохие данные»

DVAckom	#3 Оставлено : 28 апреля 2014 г. 13:01:29(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 27.05.2011(UTC) Сообщений: 102 Сказал(а) «Спасибо»: 17 раз Поблагодарили: 56 раз в 18 постах	К сожалению, Outlook тут ни при чем. В других продуктах ошибка воспроизводится, ключи исключительно ГОСТовые.

Андрей Писарев	#4 Оставлено : 28 апреля 2014 г. 13:24:31(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… Ветка реестра: HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyDefaultsProvider
Техническую поддержку оказываем тут Наша база знаний
	WWW

Андрей Писарев	#5 Оставлено : 28 апреля 2014 г. 13:28:48(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Дополнительно, еще можно посмотреть сертификаты (asn1dump) и сравнить информацию в OID «1.2.643.2.2.19» Например: Цитата: OBJECT IDENTIFIER ‘1 2 643 2 2 19’ SEQUENCE { OBJECT IDENTIFIER ‘1 2 643 2 2 36 0’ OBJECT IDENTIFIER ‘1 2 643 2 2 30 1’ } }
Техническую поддержку оказываем тут Наша база знаний
	WWW

infocentre	#6 Оставлено : 29 апреля 2014 г. 10:05:47(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 26.07.2012(UTC) Сообщений: 255 Сказал «Спасибо»: 22 раз Поблагодарили: 13 раз в 9 постах	Автор: Андрей * Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… Тот же Випнет, к примеру.

Андрей Писарев	#7 Оставлено : 29 апреля 2014 г. 10:06:54(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Автор: infocentre Автор: Андрей * Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… Тот же Випнет, к примеру.
Техническую поддержку оказываем тут Наша база знаний
	WWW

Дина	#8 Оставлено : 6 марта 2015 г. 14:07:49(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.03.2015(UTC) Сообщений: 1 Откуда: Казань	Автор: DVAckom В последнее время все чаще и чаще сталкиваемся с проблемой расшифровки сообщений в КриптоПро CSP 3.6. Раньше данная проблема возникала и лечилась переустановкой CSP. Но это были единичные случаи, и мы списывали их на естественные проблемы конкретных пользователей. В последние 3-4 месяца количество подобных обращений выросло значительно. Симптомы: CSP работает корректно при подписи, проверке подписи, шифровании. Только при расшифровке сообщений появляется ошибка «Плохие данные. (0x80090005)». Расшифровку проводили несколькими программными продуктами, включая КриптоАРМ. На всех продуктах одинаковая ошибка. Ошибка появляется на различных ОС и при различных антивирусах. В настоящий момент имеется один пользователь, у которого переустановка CSP проблему не решила (версия CSP 3.6.7777, Windows7, NOD32) и еще один у которого специально не переустанавливали CSP в надежде найти решение проблемы. Столкулись с аналогичной проблемой, переустановка криптопро CSP версия 3.6.7777 решает проблему на один раз, после того как проблема решена у одного пользователя, она возникает у другого пользователя, либо при следующем приеме/расшифровке сообщений. Другой CSP, с поддержкой ГОСТ, не установлен.

DVAckom	#9 Оставлено : 12 августа 2015 г. 12:44:54(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 27.05.2011(UTC) Сообщений: 102 Сказал(а) «Спасибо»: 17 раз Поблагодарили: 56 раз в 18 постах	Известна проблема плохой совместимости КриптоПро CSP и VipNet CSP и даже предложены варианты решения. Проблема стоит, похоже, шире: КриптоПро CSP перестает расшифровывать файлы при установленном VipNet-клиенте, VipNet-мониторе. При этом VipNet CSP не устанавливалась, но в ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyDefaultsProvider появляются сведения о VipNet CSP. В настоящий момент имеем два компьютера, у которых в реестре есть упоминание о VipNet CSP. На одном все работает корректно, на другом, сообщение не расшифровывается. Может не туда копаем?

Максим Коллегин	#10 Оставлено : 12 августа 2015 г. 12:58:04(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,297 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 680 раз в 599 постах	Попробуйте CSP 3.9R2
Знания в базе знаний, поддержка в техподдержке
	WWW

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

Guest

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

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

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

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

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

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

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

Источник

Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро CSP 5.0
»
При попытке импорта .pfx вылезает ошибка «0x80090005 плохие данные»

Анатолий Колкочев	#1 Оставлено : 17 августа 2021 г. 17:55:17(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 412 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 54 раз в 49 постах	Попытался импортировать файл .pfx через инструменты КриптоПро: Сервис -> Установить личный сертификат. При попытке импорта pfx возникает ошибка «0x80090005 плохие данные». Сам pfx во вложении: temp.zip (2kb) загружен 2 раз(а). Пароль: 111 Подскажите, пожалуйста, в чем проблема? Импорт через встроенный инструмент Windows (мастер импорта сертификатов) проходит успешно Отредактировано пользователем 17 августа 2021 г. 18:23:18(UTC) \| Причина: Не указана
GithHub: https://github.com/anatolkavassermann/

Андрей *	#2 Оставлено : 17 августа 2021 г. 18:33:52(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Здравствуйте. В каком CSPПО создавали такой … pfx? Для примера (слева нормальный PFX, справа вложенный на форуме) Snimok ehkrana ot 2021-08-17 19-32-45.png (76kb) загружен 15 раз(а).
Техническую поддержку оказываем тут Наша база знаний
	WWW

Андрей *	#3 Оставлено : 17 августа 2021 г. 18:35:03(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Автор: Анатолий Колкочев Сам pfx во вложении: temp.zip (2kb) загружен 2 раз(а). Пароль: 111 Не принимает 111: Snimok ehkrana ot 2021-08-17 19-34-23.png (22kb) загружен 6 раз(а).
Техническую поддержку оказываем тут Наша база знаний
	WWW

Анатолий Колкочев	#4 Оставлено : 17 августа 2021 г. 18:39:51(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 412 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 54 раз в 49 постах	Автор: Андрей * Здравствуйте. В каком CSPПО создавали такой … pfx? Для примера (слева нормальный PFX, справа вложенный на форуме) Snimok ehkrana ot 2021-08-17 19-32-45.png (76kb) загружен 15 раз(а). Создавал в BouncyCastle… Удивился сам сейчас содержимому (и тому, что мастер импорта сертификатов не ругается) Автор: Андрей * Не принимает 111: Snimok ehkrana ot 2021-08-17 19-34-23.png (22kb) загружен 6 раз(а). У меня принимает пароль 111 … Сейчас изменю пароль и новый залью UPD: новый pfx temp.zip (2kb) загружен 1 раз(а). Пароль: 1234 Отредактировано пользователем 17 августа 2021 г. 18:43:00(UTC) \| Причина: Не указана
GithHub: https://github.com/anatolkavassermann/

Андрей *	#5 Оставлено : 17 августа 2021 г. 18:43:50(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Автор: Анатолий Колкочев Создавал в BouncyCastle… Удивился сам сейчас содержимому (и тому, что мастер импорта сертификатов не ругается) Конечная цель какая? Почему не используется генерация ключа в КриптоПРО CSP?
Техническую поддержку оказываем тут Наша база знаний
	WWW

Анатолий Колкочев	#6 Оставлено : 17 августа 2021 г. 18:52:20(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 412 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 54 раз в 49 постах	Автор: Андрей * Автор: Анатолий Колкочев Создавал в BouncyCastle… Удивился сам сейчас содержимому (и тому, что мастер импорта сертификатов не ругается) Конечная цель какая? Почему не используется генерация ключа в КриптоПРО CSP? Если честно, цель — исключительно научный интерес) Хотел сгенерировать ключи в BouncyCastle и попробовать скормить это КриптоПро через pfx. Поэтому ключи генерировались не КриптоПро
GithHub: https://github.com/anatolkavassermann/

Анатолий Колкочев	#7 Оставлено : 18 августа 2021 г. 11:23:08(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 412 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 54 раз в 49 постах	Разобрался в проблеме формирования pfx. Была путаница между PEM и DER. Пришлось еще немного в исходниках BC поковыряться. Еще обнаружил следующее: если BouncyCastle передать пароль для pfx при его создании, то BouncyCastle автоматом шифрует и certBag. На время вырезал это. Поэтому так странно, на первый взгляд, изначально выглядело. Вот новый pfx: temp.zip (3kb) загружен 3 раз(а).. Пароль: 1234 Но проблема, к сожалению, осталась. Импорт через КриптоПро не проходит. Ошибка та же: «0x80090005 плохие данные» Отредактировано пользователем 18 августа 2021 г. 12:18:49(UTC) \| Причина: Не указана
GithHub: https://github.com/anatolkavassermann/

two_oceans	#8 Оставлено : 19 августа 2021 г. 1:27:17(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,598 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 389 раз в 364 постах	Подозреваю, что при экспорте и импорте применены разные алгоритмы. К слову, импортировать можно по-разному: 1) через certmgr (или двойным щелчком или из контекстного меню или командной строкой); 2) через p12util. При этом у них разные требования к алгоритмам p12/pfx: 1) смешанно гост и не гост; 2) только гост. Еще вариант — если BC, допустим, работает с сертификатом гост, связанным с контейнером криптопро csp (и неявно обращается к криптопро csp), то стоит помнить, что криптопро csp вместо реального закрытого ключа возвращает всем внешним приложениям дескриптор, связанный с закрытым ключом, который сохранять или экспортировать смысла не имеет. Однако если этот дескриптор пока еще связан с ключом, то при передаче обратно в криптопро csp он будет работать как будто передан реальный ключ. При перезапуске криптопровайдера дескриптор закрывается (читай отвязывается от ключа) и сохраненный дескриптор «превращается в тыкву».

Анатолий Колкочев	#9 Оставлено : 19 августа 2021 г. 8:50:28(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 412 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 54 раз в 49 постах	Автор: two_oceans Подозреваю, что при экспорте и импорте применены разные алгоритмы. К слову, импортировать можно по-разному: 1) через certmgr (или двойным щелчком или из контекстного меню или командной строкой); 2) через p12util. При этом у них разные требования к алгоритмам p12/pfx: 1) смешанно гост и не гост; 2) только гост. Еще вариант — если BC, допустим, работает с сертификатом гост, связанным с контейнером криптопро csp (и неявно обращается к криптопро csp), то стоит помнить, что криптопро csp вместо реального закрытого ключа возвращает всем внешним приложениям дескриптор, связанный с закрытым ключом, который сохранять или экспортировать смысла не имеет. Однако если этот дескриптор пока еще связан с ключом, то при передаче обратно в криптопро csp он будет работать как будто передан реальный ключ. При перезапуске криптопровайдера дескриптор закрывается (читай отвязывается от ключа) и сохраненный дескриптор «превращается в тыкву». Сравнил OID-ы алгоритмов — действительно разные (слева — pfx BouncyCastle, справа — pfx КриптоПро): BC vs CP.gif (50kb) загружен 6 раз(а). При попытке импорта через утилиту certmgr возникает «ошибка при шифровании или расшифровывании. [Error code: 0x80092002]». Я так и не понял, что за OID алгоритма шифрования в pfx, полученном при экспорте ключей с использованием КриптоПро: 1.2.840.113549.1.12.1.80. Вроде как ветка 1.2.840 к США относится, но в инете так и не нашел информации об этом OID: OIDs.jpg (248kb) загружен 4 раз(а).. Через p12util пока не пробовал импортировать, но импорт через через встроенный инструмент Windows (мастер импорта сертификатов) проходит успешно. Отредактировано пользователем 19 августа 2021 г. 9:11:13(UTC) \| Причина: Не указана
GithHub: https://github.com/anatolkavassermann/

Андрей *	#10 Оставлено : 19 августа 2021 г. 9:48:47(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,012 Сказал «Спасибо»: 457 раз Поблагодарили: 1912 раз в 1478 постах	Автор: Анатолий Колкочев Через p12util пока не пробовал импортировать, но импорт через через встроенный инструмент Windows (мастер импорта сертификатов) проходит успешно. Тот, что выкладывали с 1234 — не проходит импорт. Пробуйте сами на другой ОС (чистой, только с КриптоПРО CSP)
Техническую поддержку оказываем тут Наша база знаний
	WWW

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

Guest

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

Источник

Host Integration Server 2013 BizTalk Server 2013 R2 Branch BizTalk Server 2013 R2 Developer BizTalk Server 2013 R2 Enterprise BizTalk Server 2013 R2 Standard Еще…Меньше

Обновленные рекомендации

После применить исправление, описанное в разделе «Решение», службы корпоративного единого входа (ENTSSO) происходит утечка памяти. Поэтому рекомендуется вместо установки более поздней версии исправления .

Симптомы

Рассмотрим следующий сценарий:

Был установлен компонент версии 5 корпоративного единого входа (SSO), включенный в Microsoft BizTalk Server 2013 R2 или узла Integration Server 2013.
В одном из следующих сценариев восстановления главного ключа из файла резервной копии:
- При установке кластера SSO в сети предприятия
- Во время корпоративного единого входа аварийного восстановления
- Когда повышение роли сервер корпоративного единого входа для сервера главный секрет (MSS)
- Во время миграции с более ранней версии SSO в сети предприятия
- Во время обновления на месте с более ранней версии SSO в сети предприятия
- При выполнении нескольких V5 единого входа предприятия восстановления и резервного копирования последовательности

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

Код события: 10536
Источник: ENTSSO
Уровень: предупреждение
АУДИТА функция единого входа: Идентификатор трассировки GetConfigInfo ({11111111-6055-4cda-89CD-389E8A2B1640}): b084f15b-43fd-474e-a075-398943753c91 клиентский компьютер: имя компьютера (имя: PID исполняемый) пользователь клиента: имя пользователя имя приложения: имя приложения код ошибки: 0x80090005, неверные данные.

Кроме того может быть зарегистрировано следующее всплывающее сообщение об ошибке, при открытии оснастки MMC администрирования BizTalk Server:

Администрирования BizTalk Server
Неверные данные.
(WinMgmt)
Кнопки:
Хорошо

Причина

V5 единого входа предприятия добавляет метку времени главный секретный ключ для ограничения продолжительности использования ключа. Кроме того проверка была добавлена для определения, содержит ли главный секретный ключ штамп времени. Служба единого входа предприятия неправильно определяет, что отсутствует отметка времени при восстановлении главного ключа возникает проблема, описанная в разделе «Проблема». Так как восстановленный главный секретный ключ был добавлен штамп времени, восстановленный ключ не соответствует ключ, используемый для шифрования данных в базе данных единого входа предприятия. Поэтому не удается расшифровать данные, и это вызывает сообщения об ошибках, описанные выше.

Решение

Сведения об исправлении

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Это исправление ко всем системам V5 единого входа предприятия для предотвращения этой проблемы, а также для всех систем, которые уже испытывают проблемы. Для установки исправления требуется не дополнительных действий для предотвращения и устранения проблемы.

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Для получения полного списка телефонов поддержки и обслуживания клиентов корпорации Майкрософт, или для создания отдельного запроса на обслуживание, посетите следующий веб-сайт Майкрософт:

http://support.microsoft.com/contactus/?ws=support

Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Для установки этого исправления необходимо иметь корпоративного единого входа V5 (9.0.2096) установлен.

Сведения о перезагрузке компьютера

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

Сведения о файлах

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

32-разрядный (x 86) версии

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Infocache.dll	9.0.2187.0	130,536	01-Oct-2014	22:00	x86
Microsoft.enterprisesinglesignon.systemmmc.dll	9.0.2187.0	198,632	01-Oct-2014	22:00	x86
Ssoss.dll	9.0.2187.0	113,128	01-Oct-2014	22:00	x86

64-разрядный (x 64) версии

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Infocache.dll	9.0.2187.0	130,536	01-Oct-2014	22:00	x86
Microsoft.enterprisesinglesignon.systemmmc.dll	9.0.2187.0	198,632	01-Oct-2014	22:00	x86
Ssoss.dll	9.0.2187.0	113,128	01-Oct-2014	22:00	x86
Infocache.dll	9.0.2187.0	151,528	01-Oct-2014	22:00	x64
Microsoft.enterprisesinglesignon.systemmmc.dll	9.0.2187.0	198,632	01-Oct-2014	22:00	x86
Ssoss.dll	9.0.2187.0	124,392	01-Oct-2014	22:00	x64

Примечание из-за зависимостей между файлами, последние исправления, содержит эти файлы также могут содержать дополнительные файлы.

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Дополнительные сведения

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

Источник

When I tried to set Physical Path Credentials in the Advanced Settings, I’ve got an error message as follows:

Internet Information Services (IIS) Manager

Bad Data. (Exception from HRESULT: 0x80090005)

And it prevents me to set specific user to access network shared folder.

Strangely, I have another server with same configuration, it works fine but this one raised the error. Any idea?

Jim Counts

12.5k9 gold badges45 silver badges63 bronze badges

asked Feb 24, 2010 at 15:12

if you copied over the applicationhost.config, you need to export and import also accounts encrypted through WAS.

What i did (taken from here):

Export:

aspnet_regiis -px "iisConfigurationKey" "D:iisConfigurationKey.xml" -pri 
aspnet_regiis -px "iisWasKey" "D:iisWasKey.xml" -pri

Import:

aspnet_regiis -pi "iisConfigurationKey" "D:iisConfigurationKey.xml" 
aspnet_regiis -pi "iisWasKey" "D:iisWasKey.xml"

then copy again the applicationhost.config
working again!

answered Jun 14, 2012 at 7:33

I have seen that problem when the encryption keys have been misconfigured, usually because an ApplicationHost.config was copied from a different machine (without importing the encryption keys) or the encryption keys have been override incorrectly.

The reason you get that error is because whenever a password is stored (such as a virtual directory user/pwd) it is stored using encryption and that will cause it to fail.

answered Jun 22, 2010 at 4:45

Thanks to a good answer by Mathieu Chateau, I discovered that the applicationHost.config file can be edited manually to avoid the need to export and import the machine key used for the encoding. I just manually set all the app pool identities to the default app pool identity like so:

<add name="local.com">
    <processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="false" />
</add>

I refreshed the list of app pools in the IIS manager UI, and all seemed to work just fine, including the ability to edit the app pool settings for another identity. I would expect that any other change to the properties would work fine as well.

answered May 14, 2013 at 20:01

Ben CollinsBen Collins

20.5k18 gold badges126 silver badges187 bronze badges

Simple fix for me:
If you are using a shared configuration for IIS, re-add the user credentials for the network location where the applicationHost file is shared. This will remove the previously encrypted credentials from the config file and replace it with the updated one.

You can also remove the encrypted field from the applicationHost file manually, e.g:

        <add name="site.com" autoStart="true" enable32BitAppOnWin64="true" managedRuntimeVersion="v4.0" startMode="AlwaysRunning">
            <processModel identityType="SpecificUser" userName=".username" password="[enc:IISWASOnlyAesProvider:IIasdfasd225223xxx:enc]" />
        </add>

answered Nov 21, 2016 at 12:37

Источник

когда я попытался установить учетные данные физического пути в расширенных настройках, у меня появилось сообщение об ошибке следующим образом:

Internet Information Services (IIS) Manager

Неверные Данные. (Исключение из HRESULT: 0x80090005)

и это мешает мне установить конкретного пользователя на доступ к общей сетевой папке.

странно, у меня есть другой сервер с той же конфигурацией, он работает нормально, но этот вызвал ошибку. Есть идеи?

4 ответов

Если вы скопировали файл applicationhost.config, вам нужно экспортировать и импортировать также учетные записи, зашифрованные через WAS.

что я сделал (взято из здесь):

экспортировать:

aspnet_regiis -px "iisConfigurationKey" "D:iisConfigurationKey.xml" -pri 
aspnet_regiis -px "iisWasKey" "D:iisWasKey.xml" -pri

импорт:

aspnet_regiis -pi "iisConfigurationKey" "D:iisConfigurationKey.xml" 
aspnet_regiis -pi "iisWasKey" "D:iisWasKey.xml"

затем скопируйте снова applicationhost.конфиг
снова работает!

Я видел эту проблему, когда ключи шифрования были неправильно настроены, обычно из-за ApplicationHost.config был скопирован с другого компьютера (без импорта ключей шифрования) или ключи шифрования были неправильно переопределить.

причина, по которой вы получаете эту ошибку, заключается в том, что всякий раз, когда пароль хранится (например, пользователь виртуального каталога/pwd), он хранится с помощью шифрования, и это приведет к сбою.

автор: Carlos Aguilar Mares

благодаря хорошему ответу Матье Шато, я обнаружил, что applicationHost.файл конфигурации можно редактировать вручную, чтобы избежать необходимости экспортировать и импортировать машинный ключ, используемый для кодирования. Я просто вручную установил все идентификаторы пула приложений на идентификатор пула приложений по умолчанию следующим образом:

<add name="local.com">
    <processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="false" />
</add>

я обновил список пулов приложений в интерфейсе диспетчера IIS, и все, казалось, работали нормально, включая возможность редактирования параметров пула приложений для другого идентификатора. Я бы ожидайте, что любое другое изменение свойств также будет работать нормально.

простое исправление для меня:
Если вы используете общую конфигурацию для IIS, повторно добавьте учетные данные пользователя для сетевого расположения, где файл applicationHost является общим. Это позволит удалить ранее зашифрованные учетные данные из файла конфигурации и заменить его обновленным.

вы также можете удалить зашифрованное поле из файла applicationHost вручную, e.g:

        <add name="site.com" autoStart="true" enable32BitAppOnWin64="true" managedRuntimeVersion="v4.0" startMode="AlwaysRunning">
            <processModel identityType="SpecificUser" userName=".username" password="[enc:IISWASOnlyAesProvider:IIasdfasd225223xxx:enc]" />
        </add>

Источник