Ошибка получения секретного ключа пользователя

При попытке входа по сертификату в любую из систем (Бюджетное планирования ГИИС ЭБ, ЕИС) из браузера Internet Explorer возникает ошибка

«Не удается безопасно подключиться к этой странице
Возможно, на сайте используются устаревшие или ненадежные параметры безопасности протокола TLS. Если это будет повторяться, обратитесь к владельцу веб-сайта.»

И в событиях Windows появляется ошибка

КриптоПро TLS. Ошибка 0x8009000d при обращении к CSP: Ключ не существует.

Установленное ПО:
Windows 10 Pro 1803 Сборка 17134.590
Криптопро CSP 4.0.9963
Криптопро плагин 2.0.13579
Internet Explorer 11.590.17134.0
Яндекс.Браузер 18.9.1.954
Microsoft Edge 42.17134.1.0

Ошибка возникает при выборе сертификата, на закрытый ключ которого установлен пин код (пин код не запрашивается, а сразу выкидывает ошибку; с любым сертификатом). Если на контейнер закрытого ключа пин кода нет, то ошибка не возникает, входит успешно.

При этом, если входить через Microsoft Edge или Яндекс браузер, то пин код успешно запрашивается во всех случаях, и вход происходит без ошибок.

Тест подписи на сайте КриптоПРО при этом проходится успешно как с пин кодом, так и без (запрашивается как положено).

На Windows 7, Windows 8.1 и Windows 10 1809 таких ошибок не возникает, только на Windows 10 1803 (на всех машинах, 30 шт).

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

• набор ключей не определен;
• неправильный открытый ключ поставщика;
• не найден сертификат и открытый ключ для расшифровки;
• не найден сертификат руководителя в системном хранилище сертификатов;
• не удалось расшифровать файл обновлений;
• ошибка инициализации криптопровайдера;
• плохие данные;
• ошибка при получении свойств сертификата. Не удалось выполнить подписание сертификатом, Федеральная налоговая служба по причине Ошибка при получении свойства сертификата (0x0000000);
• ошибка интерфейса модуля криптографии. Отсутствует набор ключей. Не удалось выполнить подписание сертификатом по причине: Ошибка интерфейса модуля криптографии. Отсутствует набор ключей;
• ошибка при получении контекста модуля криптографии. Не удалось выполнить подписание сертификатом , Федеральная налоговая служба по причине Ошибка при получении контекста модуля криптографии;
• не удалось подписать файл по причине: Ошибка исполнения функции. Не удалось подписать файл по причине: Ошибка исполнения функции. Ошибка подписания документа: Запрос на информационное обслуживание налогоплательщика, связанное с циклом обмена.

Из нашей статьи вы узнаете:

ЭЦП — довольно сложный цифровой продукт, обращение с которым в определенных ситуациях может потребовать некоторых навыков и знаний. Например, в ходе установки сертификатов ЭП посредством «КриптоПро» после выбора соответствующего ключевого контейнера нередко выдаются неприятные сообщения об ошибке вследствие отсутствия открытого шифровочного ключа, который необходим для обеспечения информационной безопасности, без чего система не будет принимать ЭЦП.

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

Что может послужить причиной такой ошибки

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

• установка сертификата впервые;
• экспортирование данных на внешний носитель;
• попытка просмотра ключей в контейнерах ключей;
• загрузка информации на компьютер извне.

В целях устранения ошибки обычно бывает достаточно произвести корректную ручную переустановку сертификата.

Отсутствие электронного сертификата в контейнере закрытого ключа

Для начала запускаем «КриптоПро» нажатием кнопки «Пуск». Затем выбираем «Настройку», в возникающем на мониторе окне заходим в опцию панели управления, далее «сервис – установить личный сертификат».

Далее, через кнопку «обзор» указываем путь, где сохранен открытый ключ – файл с расширением *.cert или *.crt

Жмём «Далее», в мастере установки сертификата мы увидим путь, который указывали до нашего сертификата.

Нам отображается информация, содержащаяся в открытом ключе на пользователя, жмём «далее»

В следующем окне можно воспользоваться двумя путями поиска нужного контейнера закрытого ключа:

• «найти контейнер автоматически
• вручную через «обзор»

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

Самый простой вариант выбрать автоматический поиск, затем после «обнаружения» необходимого контейнера, мы увидим заполненную строчку с его именем и после жмём «Далее»

Личный сертификат пользователя всегда устанавливается в хранилище «Личное», можно выбрать как вручную, так и КриптоПро может сделать это за вас по умолчанию, затем подтверждаем установку цепочки сертификатов и жмём «Далее»

В случае успешной установки КриптоПро выдаст окно с информацией об окончании процедуры и жмём «Готово»

Затем появится окно с подтверждением данной операции, жмём «ДА»

В следующем окне увидим информацию о том, что процесс окончен успешно. Сертификат установлен в контейнер закрытого ключа.

Особенности версий КриптоПро

С января 2019 года квалифицированные сертификаты могут выпускаться только по ГОСТ 2012, выпуск по другому ГОСТу прекращен. Мы об этом писали ранее в статье. Важно помнить, что версии криптопро на ГОСТ 2012 работают только с версии 4.0 и выше. Все старые версии КриптоПро, для нормальной работы, потребуется обновить или заменить на актуальную. Сделать это нужно не позднее 31 декабря 2019 года.

In my earlier reply, I hope I didn’t give you the impression I was any kind of expert on this stuff. I’m not (0.5 on a 10-point scale if I’m feeling generous). My general approach is to keep belting the problem with whatever digital hammer is within reach and only stop thwacking stuff when the thing I’m trying to achieve seems to work.

I won’t say I followed the DrDuh guide exactly when I set up my own YubiKeys in late 2019 but the notes I made at the time show my process was reasonably close to what the guide says now.

Here are the patterns I see on my own systems:

$ gpg -k $KEYID 
pub   rsa4096/0xAAAAAAAAAAAAAAAA yyyy-mm-dd [C]
      Key fingerprint = AAAA AAAA AAAA AAAA AAAA  AAAA AAAA AAAA AAAA AAAA
uid                   [ultimate] Given Last (nick) mailbox@domain.com>
…
sub   rsa4096/0xBBBBBBBBBBBBBBBB yyyy-mm-dd [S]
sub   rsa4096/0xCCCCCCCCCCCCCCCC yyyy-mm-dd [E]
sub   rsa4096/0xDDDDDDDDDDDDDDDD yyyy-mm-dd [A]

$ gpg -K $KEYID 
sec#  rsa4096/0xAAAAAAAAAAAAAAAA yyyy-mm-dd [C]
      Key fingerprint = AAAA AAAA AAAA AAAA AAAA  AAAA AAAA AAAA AAAA AAAA
uid                   [ultimate] Given Last (nick) mailbox@domain.com>
…
ssb>  rsa4096/0xBBBBBBBBBBBBBBBB yyyy-mm-dd [S]
ssb>  rsa4096/0xCCCCCCCCCCCCCCCC yyyy-mm-dd [E]
ssb>  rsa4096/0xDDDDDDDDDDDDDDDD yyyy-mm-dd [A]

I interpret that as:

1. RSA master key having Certify.
2. Separate RSA sub-keys for each of Signing, Encrypting and Authenticating.
3. The «sub» (public) sub-keys being in the local keychain.
4. The «ssb>» (private) sub-keys being on the YubiKey.

So, let’s put a pin in that and examine your pattern:

gpg --list-keys
/home/ss/.gnupg/pubring.kbx
---------------------------
pub   ed25519 2018-11-30 [SC]
      123456789ABCDEF123456789ABCDEF12345
uid           [ unknown] something@srp.modulus
sub   cv25519 2018-11-30 [E]

I interpret that as:

1. Elliptic curve (rather than RSA) master key having Sign and Certify.
2. A public sub-key with Encryption in the local keychain.
3. No information about private keys.

Quite different — agreed?

The question I ask myself is, «can I replicate that?» After a few false starts, it turns out the answer is yes.

Setup steps (Raspbian):

$ RAMDISK="/run/user/$(id -u)/ramdisk"
$ mkdir "$RAMDISK"
$ sudo mount -t tmpfs -o size=128M myramdisk "$RAMDISK"
$ sudo chown $USER:$USER "$RAMDISK"; chmod 700 "$RAMDISK"
$ export GNUPGHOME=$(mktemp -d -p "$RAMDISK")
$ cd "$GNUPGHOME"
$ wget -O $GNUPGHOME/gpg.conf https://raw.githubusercontent.com/drduh/config/master/gpg.conf
$ PASSPHRASE=$(gpg --gen-random --armor 0 24)

Generate «ECC and ECC» with «Curve 25519»:

$ gpg --expert --full-generate-key
gpg: keybox '/run/user/1002/ramdisk/tmp.USf3fSZhYJ/pubring.kbx' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 1
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Test Example
Email address: test@example.com
Comment: 
You selected this USER-ID:
    "Test Example <test@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /run/user/1002/ramdisk/tmp.USf3fSZhYJ/trustdb.gpg: trustdb created
gpg: key 0xFFA9E42FB6BD3765 marked as ultimately trusted
gpg: directory '/run/user/1002/ramdisk/tmp.USf3fSZhYJ/openpgp-revocs.d' created
gpg: revocation certificate stored as '/run/user/1002/ramdisk/tmp.USf3fSZhYJ/openpgp-revocs.d/436AA047E89984A588D05FA6FFA9E42FB6BD3765.rev'
public and secret key created and signed.

pub   ed25519/0xFFA9E42FB6BD3765 2022-06-10 [SC]
      Key fingerprint = 436A A047 E899 84A5 88D0  5FA6 FFA9 E42F B6BD 3765
uid                              Test Example <test@example.com>
sub   cv25519/0xF9B081BC3EBB4E27 2022-06-10 [E]

Pattern analysis:

$ gpg --list-keys
/run/user/1002/ramdisk/tmp.USf3fSZhYJ/pubring.kbx
-------------------------------------------------
pub   ed25519/0xFFA9E42FB6BD3765 2022-06-10 [SC]
      Key fingerprint = 436A A047 E899 84A5 88D0  5FA6 FFA9 E42F B6BD 3765
uid                   [ultimate] Test Example <test@example.com>
sub   cv25519/0xF9B081BC3EBB4E27 2022-06-10 [E]

Pretty much identical pattern to yours — agreed?

So, the first issue would seem to be to figure out why, if we both followed the DrDuh guide, I wound up with RSA with C plus S+E+A split over sub-keys, while you have elliptic curve with S+C plus a single E sub-key.

One possibility is, assuming your «2018-11-30» is true, you were working a year ahead of me so maybe the guide was different then?

Another possibility. I have another key-pair which is analogous to your pattern:

$ gpg -k 0x1111111111111111
pub   rsa4096/0x1111111111111111 2019-12-18 [SC] [expires: yyyy-mm-dd]
      Key fingerprint = 1111 1111 1111 1111 1111  1111 1111 1111 1111 1111
uid                   [ unknown] Given Last (nick) mailbox@domain.com>
sub   rsa4096/0x2222222222222222 2019-12-18 [E] [expires: yyyy-mm-dd]

$ gpg -K 0x1111111111111111
sec   rsa4096/0x1111111111111111 2019-12-18 [SC] [expires: yyyy-mm-dd]
      Key fingerprint = 1111 1111 1111 1111 1111  1111 1111 1111 1111 1111
uid                   [ unknown] Given Last (nick) mailbox@domain.com>
ssb   rsa4096/0x2222222222222222 2019-12-18 [E] [expires: yyyy-mm-dd]

Those are from Keybase. RSA but the SC plus E is the same as yours. I generated and exported those, and then used them to sign the master key I was generating for the YubiKey. Why? For no better reason than that it seemed like a good idea at the time. Perhaps you did something similar?

While the steps I outlined in my earlier reply let me get going on a new machine given only my public keys plus the YubiKey, any time I want to do something more serious, I need to go back to the snapshot of the master-key generation just before the private keys were transferred to the YubiKey. That’s Backup in the DrDuh guide.

I’m afraid that I didn’t go to quite the extremes in the guide:

$ BACKUP="$RAMDISK/$(date +%F)-$KEYID.tar.gz"
$ tar -zcf "$BACKUP" .

then I saved that .tar.gz into an encrypted disk image. The truly paranoid would probably clutch their worry-beads but…

Anyway, given this backup, I can restore to the moment before the private keys were transferred to the YubiKey. That means I can edit whatever needs to be edited and then repeat the basic process of:

1. Take another backup.
2. Transfer the (updated) private keys to the first YubiKey.
3. Restore the backup.
4. Transfer the (updated) private keys to the second YubiKey.
5. Save the backup into the encrypted disk image ready for next time.

Unless you skipped the «make a backup» step or have since lost the backup, you should be able to do the same.

The last possibility is that you see if Recovering lost GPG public keys from your YubiKey solves your problem. I have not tried it so I have no idea whether it works — please remember to report back here if it does.

If none of this helps you have an «ahah» moment, you might have to start from scratch and generate all-new keys.

Когда кто-то отправляет вам зашифрованное электронное письмо, файл или документ, они используют ваш GPG “Общественные»Ключ для шифрования файла. Ключ дешифрования вашего открытого ключа — это ваш GPG «Частный» или «Секрет» ключ. Однако, если вы получаете «gpg: сбой дешифрования: секретный ключ отсутствует”Ошибка при расшифровке файла означает, что ваша пара ключей GPG неверна или открытый ключ, используемый для шифрования, не совпадает с соответствующим ключом в вашей системе.

Если вы попали в такую ​​ситуацию, то не беспокойтесь! В этой статье будут продемонстрированы различные методы решения проблемы «gpg: сбой дешифрования: секретный ключ отсутствует”Ошибка в вашей системе Linux. Итак, начнем!

Метод 1: решить gpg: сбой дешифрования: ошибка секретного ключа путем убийства gpg-агента

Чтобы решить «gpg: сбой дешифрования: секретный ключ отсутствует», Первый способ, который вы можете попробовать, — это уничтожить существующий«gpg-агент» процесс. Значок «gpg-агент”- это демон, который помогает управлять закрытыми или секретными ключами независимо от протокола. Он служит серверной частью для gpgsm, gpg и некоторых других программ. Чтобы убить «

gpg-агент», Откройте свой терминал, нажав«CTRL + ALT + T”, А затем выполните следующую команду:

$ gpgconf —убийство gpg-агент

Система перезапустит «gpg-агент», Когда это необходимо или по запросу gpg, gpgconf, gpgsm или gpg-connect-agent. Вы также можете выполнить простую команду «gpg -k», Чтобы запустить«gpg-агент»Перезапустить процесс.

Если ваша пользовательская система systemd управляет демоном «gpg-agent», то сначала проверьте его статус:

$ systemctl —Пользователь статус gpg-agent

После этого остановите «gpg-агент”, А затем запустите его снова с помощью следующих команд:

$ systemctl —Пользователь остановить gpg-agent

$ systemctl —Пользователь запустить gpg-agent

Затем снова проверьте статус «gpg-agent»:

$ systemctl —Пользователь статус gpg-agent

Метод 2 Решение gpg: сбой дешифрования: ошибка секретного ключа путем удаления кеша GPG

Если предыдущий метод не помог вам, вы можете сделать еще одну вещь — сначала удалить кеш GPG, а затем перезапустить «gpg-agent».

Вы можете выполнить следующую команду rm для удаления кеша GPG:

$ rm ~/.gnupg/С.*

Затем перезапустите «gpg-агент”В вашей системе Linux:

$ Перезагрузка агента gpg-connect-agent /до свидания

Метод 3: решить gpg: сбой дешифрования: ошибка секретного ключа путем установки и настройки pinentry-tty

Если вы по умолчанию используете систему Ubuntu с графическим интерфейсом Gnome, тогда ваш GPG должен использовать «/usr/bin/pinentry-gnome3”. Чтобы исправить возникшую ошибку «gpg: дешифрование не удалось: нет секретного ключа», вы можете установить «Pinentry-TTY»И добавьте ее в файл конфигурации gpg-agent.

Значок «Pinentry-TTY”- это программа, позволяющая безопасно вводить парольные фразы или PIN-коды. Эта функция полезна для ввода парольных фраз при использовании любой программы шифрования, такой как GPG. Для установки в вашей системе введите следующую команду:

$ судо подходящий установить Pinentry-TTY

На следующем шаге мы установим «pinentry – tty»В качестве программы по умолчанию для gpg-agent. Для этого сначала откройте файл «gpg-agent.conf» в редакторе nano:

$ судонано/.gnupg/gpg-agent.conf

Затем в открывшемся файле конфигурации добавьте строку, указанную ниже:

Pinentry-программа /usr/мусорное ведро/Pinentry-TTY

После этого нажмите «CTRL + O», Чтобы сохранить добавленные изменения. Теперь вам нужно перезагрузить gpg-agent, чтобы он вступил в силу с измененными настройками:

$ Перезагрузка агента gpg-connect-agent /до свидания

Метод 4: Решить gpg: сбой дешифрования: ошибка секретного ключа путем экспорта и импорта закрытого ключа

Если требуемый секретный ключ не найден на другом компьютере, вы получите сообщение «gpg: сбой дешифрования: секретный ключ отсутствует”Ошибка даже с правильным закрытым ключом или парольной фразой. Чтобы решить возникшую проблему в этой конкретной ситуации, вы можете экспортировать секретный ключ, а затем импортировать его на другой компьютер.

Для этого сначала выполните приведенную ниже команду, чтобы вывести список ключей GPG, используя свой идентификатор пользователя «uid”:

$ gpg —list-keys[uid]

Запишите идентификатор пользователя из вывода. Ваш идентификатор пользователя «uid«Будет помещен после»паб”.

Теперь вы можете использовать следующую команду для экспорта секретного ключа GPG:

$ gpg —export-secret-keys[uid]>private.key

Наконец, импортируйте созданный файл «private.key» на другой компьютер:

$ gpg —Импортировать private.key

Вывод сообщит вам, что секретный ключ импортирован:

Метод 5: Решить gpg: сбой дешифрования: ошибка секретного ключа путем установки уровня доверия ключа GPG

Если после копирования пары ключей GPG вы все еще сталкиваетесь с ошибкой «gpg: decryption failed: No secret key», вам необходимо установить уровень доверия. Выполните следующую команду «gpg», чтобы изменить настройки ключа gpg:

$ gpg —edit-key[Key_ID] или [uid]

После выполнения вышеуказанной команды консоль GPG станет активной, затем введите «доверять«И нажмите»Входить”:

gpg>доверять

Теперь на экране появится меню для выбора уровня доверия со следующими параметрами:

Поскольку вы сгенерировали свой ключ, выберите вариант 5, “Я полностью доверяю», Затем подтвердите добавленную опцию и выйдите из«gpg» консоль:

gpg>покидать

Ваш «gpg: сбой дешифрования: секретный ключ отсутствует”Ошибка должна быть решена сейчас!

Вывод

При расшифровке зашифрованного файла, если вы столкнулись с gpg: сбой дешифрования: секретный ключ отсутствует error указывает на то, что открытый ключ зашифрованного файла не соответствует вашей паре ключей GPG. Существует несколько решений для устранения указанной ошибки. Эта статья продемонстрировала, как решить «gpg: сбой дешифрования: секретный ключ отсутствует”Ошибка с использованием пяти различных методов, таких как удаление gpg-agent, удаление кеша GPG, установка и настройка pinentry-tty, экспорт и импорт закрытого ключа, а также установка уровень доверия.