Ніхто не чапаў профіль, але той жа кліент цяпер патрабуе парольную фразу да прыватнага ключа пры кожным запуску. Калі гэта змена адбылася праз некалькі дзён пасля абнаўлення дыстрыбутыва, верагодная прычына — само абнаўленне: OpenSSL 3 пераарганізаваў падтрымку алгарытмаў, і ключ, які старая бібліятэка чытала без праблем, можа стаць нечытэльным без змены хоць аднаго байта. Выконвайце праверкі па парадку, бо дзве з іх выглядаюць аднолькава, калі глядзець толькі на запыт.

Першае пытанне — ці зашыфраваны ключ, а другое — ці можа гэтая зборка яго расшыфраваць. Змены канфігурацыі маюць сэнс толькі пасля таго, як вядомыя абодва адказы.

Праверце, ці зашыфраваны ключ

Прачытайце першы радок файла і дайце бібліятэцы разабраць яго, бо імя файла нічога не даказвае. Блок PEM з пазнакай ENCRYPTED PRIVATE KEY — гэта зашыфраваны PKCS#8, а старэйшы RSA PRIVATE KEY блок з Proc-Type: 4,ENCRYPTED — гэта традыцыйная форма, і абодва патрабуюць парольную фразу. Незашыфраваны PRIVATE KEY блок не павінен патрабаваць яе зусім. Запускайце разбор ад імя ўліковага запісу, які валодае файлам, бо праблема з правамі дае іншую і куды менш цікавую памылку.

Калі ключ сапраўды не зашыфраваны, а кліент усё роўна пытае, спыніце глядзець на крыптаграфію і праверце, ці не называе профіль файл askpass, які служба ўсё яшчэ можа прачытаць.

Праверце, ці можа гэтая зборка яго расшыфраваць

OpenSSL 3 падзяліў падтрымку алгарытмаў на правайдэры, і набор старых шыфраў цяпер знаходзіцца ў legacy-правайдэры, а не ў стандартным. Ключ, зашыфраваны адным з гэтых шыфраў, застаецца сапраўдным, але бібліятэка, загружаная без legacy-правайдэра, не можа яго расшыфраваць. У адных кліентах гэта выглядае як запыт, што паўтараецца, у іншых — як жорсткая памылка адразу пасля парольнай фразы.

Разбярыце той жа ключ двойчы адной і той жа праграмай: спачатку толькі са стандартным правайдэрам, потым з legacy і стандартным, запытанымі ў камандным радку. Калі другая спроба атрымліваецца там, дзе першая не ўдалася, дыягназ абапіраецца на доказы, а не на час абнаўлення. Калі ж абедзве спробы правальваюцца аднолькава, парольная фраза няправільная або файл пашкоджаны, і ніякая налада правайдэра не выправіць ні таго, ні другога.

Праверце найбольш вузкае даступнае выпраўленне

Аддавайце перавагу змене, абмежаванай кліентам, а не сістэмнай. Некаторыя зборкі 2.6 прымаюць опцыю профілю, якая загружае абодва правайдэры для працэсу гэтага дэмана, таму зверце дырэктыву з дапаможнікам для вашай дакладнай версіі, перш чым спадзявацца на яе; рэдагаванне жа сістэмнага openssl.cnf закранае кожную праграму OpenSSL на хаст. Вузкая налада таксама значна прасцей адкочваецца пасля перакадзіравання ключа.

Не выдаляйце парольную фразу, каб запыт знік. Так вы ператвараеце абароненыя ўліковыя даныя ў тэкставы файл і ціха змяняеце рызыку кожнай рэзервовай копіі, копіі і зборкі падтрымкі, дзе ён з’явіцца. Важная розніца — паміж ключом, якому патрэбна яго парольная фраза, і ключом, які гэтая бібліятэка не можа расшыфраваць.

Праверце кантэкст службы, затым перакадзіруйце

Пасля таго як ключ удаецца адкрыць, перашыфруйце яго сучасным алгарытмам каб залежнасць знікла. Запішыце новы файл з сучасным шыфрам, праверце, што ён разбіраецца, абнавіце профіль і трымайце старую копію толькі да паспяховага злучэння. Ніколі не змяшчайце парольную фразу ў камандны радок, дзе любы лакальны карыстальнік можа прачытаць яе са спісу працэсаў. Выдаліце стары файл толькі пасля таго, як новы падключыцца ад уліковага запісу службы, а не толькі з вашай абалонкі.

Затым праверце юніт, які насамрэч запускае кліент. Ключ, чытэльны ў вашай абалонцы, можа быць нечытэльным для службы, што працуе пад іншым уліковым запісам або з узмацнёнай наладай хатняга каталога.

Запішыце наладу правайдэра побач з профілем і трымайце там жа тэст з двух каманд. Калі пазнейшае абнаўленне прыбярэ legacy-правайдэр, паўтарыце гэты тэст, каб убачыць, ці ключ усё яшчэ мае патрэбу ў ім, ці профіль можна вывесці з абыходнага рашэння.

Запыт — гэта сімптом, які мае як мінімум тры прычыны, і толькі адна з іх — адсутная парольная фраза.

Падобныя артыкулы