|
DVAckom |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 17 раз |
В последнее время все чаще и чаще сталкиваемся с проблемой расшифровки сообщений в КриптоПро CSP 3.6. Раньше данная проблема возникала и лечилась переустановкой CSP. Но это были единичные случаи, и мы списывали их на естественные проблемы конкретных пользователей. В последние 3-4 месяца количество подобных обращений выросло значительно. |
![]() |
|
|
Molostvov |
|
|
Статус: Сотрудник Группы: Участники Сказал(а) «Спасибо»: 2 раз |
В Outlook может быть такое: |
![]() |
|
|
DVAckom |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 17 раз |
К сожалению, Outlook тут ни при чем. В других продуктах ошибка воспроизводится, ключи исключительно ГОСТовые. |
![]() |
|
|
Андрей Писарев |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 451 раз |
Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… |
|
Техническую поддержку оказываем тут |
|
![]() |
WWW |
|
Андрей Писарев |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 451 раз |
Дополнительно, еще можно посмотреть сертификаты (asn1dump) и сравнить информацию в OID «1.2.643.2.2.19» Цитата: OBJECT IDENTIFIER ‘1 2 643 2 2 19’ |
|
Техническую поддержку оказываем тут |
|
![]() |
WWW |
|
infocentre |
|
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 22 раз |
Автор: Андрей * Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… Тот же Випнет, к примеру. |
![]() |
|
|
Андрей Писарев |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 451 раз |
Автор: infocentre Автор: Андрей * Такое поведение, также возможно, если установлен другой CSP, с поддержкой ГОСТ… Тот же Випнет, к примеру. |
|
Техническую поддержку оказываем тут |
|
![]() |
WWW |
|
Дина |
|
|
Статус: Новичок Группы: Участники
|
Автор: DVAckom В последнее время все чаще и чаще сталкиваемся с проблемой расшифровки сообщений в КриптоПро CSP 3.6. Раньше данная проблема возникала и лечилась переустановкой CSP. Но это были единичные случаи, и мы списывали их на естественные проблемы конкретных пользователей. В последние 3-4 месяца количество подобных обращений выросло значительно. Столкулись с аналогичной проблемой, переустановка криптопро CSP версия 3.6.7777 решает проблему на один раз, после того как проблема решена у одного пользователя, она возникает у другого пользователя, либо при следующем приеме/расшифровке сообщений. Другой CSP, с поддержкой ГОСТ, не установлен. |
![]() |
|
|
DVAckom |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 17 раз |
Известна проблема плохой совместимости КриптоПро CSP и VipNet CSP и даже предложены варианты решения. Проблема стоит, похоже, шире: КриптоПро CSP перестает расшифровывать файлы при установленном VipNet-клиенте, VipNet-мониторе. При этом VipNet CSP не устанавливалась, но в ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyDefaultsProvider появляются сведения о VipNet CSP. В настоящий момент имеем два компьютера, у которых в реестре есть упоминание о VipNet CSP. На одном все работает корректно, на другом, сообщение не расшифровывается. Может не туда копаем? |
![]() |
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Попробуйте CSP 3.9R2 |
|
Знания в базе знаний, поддержка в техподдержке |
|
![]() |
WWW |
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
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.4k9 gold badges45 silver badges63 bronze badges
asked Feb 24, 2010 at 15:12
2
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
1
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.4k18 gold badges127 silver badges186 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
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.4k9 gold badges45 silver badges63 bronze badges
asked Feb 24, 2010 at 15:12
2
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
1
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.4k18 gold badges127 silver badges186 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
- Remove From My Forums
-
Вопрос
-
I am running Windows Server 2012 Standard and my client with the issue is on Windows 10 Pro Version 1703.
I have created a new GPO to schedule a task. I have confirmed the GPO is working and the task has been created on a client with Windows 10 Pro Version 1607. I checked another computer running Version 1703 and it is also having the same problem.
The GPO I have created in under Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks, and my new task is set to update.
The policy is being applied on both V1703 PC’s but returns error:
The computer ‘Cleanup_Script’ preference item in the ‘Cleanup_Script {5ADA0CC5-0969-4FF4-B203-85F160979FE8}’ Group Policy Object did not apply because it failed with error code ‘0x80090005 Bad Data.’ This error was suppressed.
Is this a bug with the new creators update or has the Group Policies for Scheduled Tasks been changed?
I came up with a work-around, but it’s really not pretty: The Old is New again.
Background: We moved from using a simple CMD login script to GPO mapped drives when we moved from Windows XP to Windows 8, and User Account control stopped mapped drives working, due to standard and admin tokens conflicting (See TechNet note here)
As Creators update removed the ability to save credentials in group policy, and I couldn’t get group policy to add the details to the local Credential Manager (Tried using this script, but looks like it won’t work with User Account Control and allowing unsigned scripts), I turned on the EnableLinkedConnections registry key, and mapped this one drive using the old skool net use command.
Full Details:
Step 1
Create a new WMI Filter specifically to detect Creators update (This reduces the lower security footprint to only the machines that need it):
select * from Win32_OperatingSystem WHERE Version like "10.0.15063%" AND ProductType="1"
Step 2
Add the WMI Filter to a new GPO, which:
- Sets the DWORD regkey SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemEnableLinkedConnections to 1
- Add a cmd Login script in the Sysvol folder

Step 3
In the login script, add the following code:
net use m: /delete /y
net use m: \[Server][Share] /user:[Server FQDN][Username] [Password] /PERSISTENT:YES
As a sidenote, this only fully affects users that are Local Administrators on Creator Update systems: If you have the option to take their administrator rights away, you can take out the EnableLinkedConnections step in the GPO, which improves the security for the other GPO mapped drives (The drive in question will still have a plaintext password script, though), but I’m working with a Legacy Program which needed the cross domain mapping AND Admin rights to work.
Know this is less than ideal as it goes back to the XP days of having a plaintext password in a not too hard to locate file, but it’s the only workaround I’ve found so far to this Creators Update issue: I have a feeling programming Credential Manager via GPO or a PowerShell login script is the correct answer, but I just can’t get it to work: If anyone can improve on this answer by getting that way to work, then that’s what I’ll go for.
При подключении диска возникает ошибка «Плохие данные»
ID статьи: 92
Последнее обновление: 03 Nov, 2015
|
ID статьи: 92 Последнее обновление: 03 Nov, 2015 Ревизия: 1 |
|
Просмотры: 285 Комментарии: 0 |
Версия ПО: Secret Disk 4.x (Персональная)
Проблема:
При подключении диска возникает ошибка «Плохие данные».
Причина:
Используется криптопак версии, отличной от той, с помощью которой шифровался диск.
Решение:
-
Удалить криптопак текущей версии.
-
Установить криптопак версии, которая была установлена на момент шифрования диска.
ID статьи: 92
Последнее обновление: 03 Nov, 2015
Ревизия: 1
Просмотры: 285
Комментарии: 0
Добрый день!
KSC 13.2.0.1511 внезапно перестал создавать резервную копию данных. Резервная копия всегда создавалась с использованием klbackup. Ниже приведён журнал, из которого непонятно, какой файл отсутствует и, тем самым, генерирует ошибку.
Проверка параметров командной строки…OK
10:15:48 Проверка путей…OK (952 мсек)
10:15:48 Подготовка…OK (31 мсек)
10:15:48 Проверка хранилищ…OK (16 мсек)
10:15:48 Проверка базы данных…OK (15 сек 288 мсек)
10:16:03 Открытие SCM…OK (15 мсек)
10:16:03 Сохранение параметров Сервера администрирования…
Копирование ‘SSP_TASKS-1093.dat’… 0.02 MB: OK (0 мсек)
Копирование ‘SSP_TASKS-1103.dat’… 0.01 MB: OK (0 мсек)
Копирование ‘Packages’… 687.83 MB: OK (515 мсек)
Копирование ‘OsImages’… 0.00 MB: OK (0 мсек)
Копирование ‘Uninstall’… 0.00 MB: OK (0 мсек)
Копирование ‘MST’… 0.00 MB: OK (0 мсек)
Копирование ‘dat’… 1.46 MB: OK (125 мсек)
Копирование ‘gsyn’… 0.06 MB: OK (0 мсек)
Копирование ‘Updates’… 0.00 MB: OK (0 мсек)
Копирование ‘GsynSuper’… 0.00 MB: OK (0 мсек)
Ошибка — 1181 (‘System error 0x2 (Не удается найти указанный файл.)’)
Помогите решить проблему. Спасибо!




