Пакетният файл спира със съобщението “Системата не успя да намери указания ключ или стойност в регистъра” и всички предполагат, че сертификатният орган е счупен. Не е, или поне още не: скриптът се провали, докато търсеше софтуер, преди да помоли Easy-RSA да направи каквото и да е с ключ. Тази последователност е важна, защото означава, че поправката е проблем с търсенето, а PKI е страничен наблюдател. Прочитането на неуспешния ред е целият диагноз и отнема по-малко време от всяко заобикалящо решение.

Грешката възниква, преди CA да бъде докоснат

Старите пакетни файлове на Easy-RSA 2 намират OpenSSL или инсталацията на OpenVPN чрез заявка към регистъра, след което задават променливи въз основа на намереното. Когато заявката не върне нищо, скриптът прекъсва, преди да се изпълни каквато и да е операция със сертификат.

Следователно съобщението за ключ в регистъра е доказателство за средата на скрипта, а не за директорията на CA.

Два изгледа на регистъра, един пакетен файл

32-битов процес и 64-битов процес могат да виждат различни изгледи на регистъра и пакетен файл, който предполага единия, може да пропусне записа, който съществува в другия. Тези сравнения само за четене показват разликата за стария ключ, който използват някои стари скриптове:

reg query "HKLM\SOFTWARE\OpenVPN" /reg:32
reg query "HKLM\SOFTWARE\OpenVPN" /reg:64

Справката за reg query описва селекторите за изглед. Стартирайте и двете в същия контекст като неуспешния скрипт, защото изгледът зависи от това как стартира процесът, както и от флаговете. Ако записът съществува само в един изглед, сравнете пътя, към който сочи, с инсталираните инструменти, преди да промените нещо. Ключ, който съществува, но сочи към стара инсталационна директория, е различна повреда от липсващ ключ.

Ако нито един изглед няма записа, инсталаторът никога не го е създавал и ръчното създаване на стойност няма да накара инструментите да работят.

Не добавяйте /reg:64 безусловно

Изкушаващата поправка е да добавите 64-битовия селектор към всяка заявка и да продължите. При някои инсталации това е правилно, а при други изпраща скрипта в изглед, който наистина няма нищо.

Променете търсенето само след като сте видели кой изглед съдържа очакваната стойност.

Откриването не е ремонт на PKI

Тази грешка не доказва, че сертификатът на CA, ключът за подписване, файлът със серийни номера или базата данни за отмяна са повредени. Изпълнението на clean-all, копирано от стар урок, би унищожило напълно различен набор от обекти, оставяйки търсенето счупено. Дръжте двете дейности отделно в главата си и в заявката. Ако по-късно операция със сертификат се провали, оценете я по собствените ѝ доказателства.

Направете резервно копие на директорията на CA преди всеки експеримент, дори такъв, за който сте сигурни, че е само за четене.

Преминаването към Easy-RSA 3 е миграция

Поддържаната инсталация трябва да използва собствения стартер и модел на конфигурация на текущия пакет, и Easy-RSA 3 не е същият работен процес с пакетни файлове като Easy-RSA 2. Бързият му старт за нов PKI не е инструкция за миграция на съществуващ орган. Преди смяна на версиите запазете материала на CA плюс записите за издаване и отмяна и следвайте указанията за надграждане на тази версия. Инициализирането на заместващ CA в авторитетната директория, за да изчезне грешка при откриване на инструмент, е най-лошият вариант в списъка.

Смяната на версия е проект; грешката в регистъра е един следобед.

Сравнението, което наистина решава проблема

Запишете четири неща и ги сравнете директно:

  • Кой скрипт се е изпълнил и кой ред се е провалил.
  • Кой изглед на регистъра е заявил този ред.
  • Кой път до изпълним файл е очаквал скриптът.
  • Коя инсталация действително съществува на машината.

Когато тези четири съвпадат, грешката изчезва и всеки останал проблем със сертификат може да се чете по собствените му доказателства, вместо да се обвинява CA.

Подобни статии