Профильге ешкім қол тигізген жоқ, бірақ сол клиент енді әр іске қосылғанда жеке кілт үшін құпияфраза сұрайды. Бұл өзгеріс дистрибутивті жаңартудан кейінгі бірнеше күн ішінде пайда болса, ықтимал себеп — жаңартудың өзі: 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 бағдарламасына әсер етеді. Тар параметр кілт қайта кодталғаннан кейін кері қайтаруға да әлдеқайда оңай.

Сұраныс жоғалсын деп құпияфразаны жоймаңыз. Бұл қорғалған тіркелгі деректерін ашық мәтінді файлға айналдырады және ол кездесетін әрбір сақтық көшірме, көшірме және қолдау бумасының тәуекелін байқатпай өзгертеді. Маңызды айырма — өз құпияфразасын қажет ететін кілт пен бұл кітапхана шеше алмайтын кілттің арасында.

Қызмет контекстін тексеріңіз, содан кейін қайта кодтаңыз

Кілтті ашу мүмкін болғаннан кейін, оны заманауи алгоритммен қайта шифрлаңыз тәуелділік жойылуы үшін. Жаңа файлды заманауи шифрмен жазыңыз, оның талданатынын тексеріңіз, профильді жаңартыңыз және ескі көшірмені қосылым сәтті болғанша ғана сақтаңыз. Құпияфразаны ешқашан пәрмен жолына қоймаңыз, онда кез келген жергілікті пайдаланушы оны процестер тізімінен оқи алады. Ескі файлды жаңасы қызмет шотынан қосылғаннан кейін ғана жойыңыз, тек өз shell-іңізден емес.

Содан кейін клиентті шын мәнінде іске қосатын бірлікті тексеріңіз. Сіздің shell-іңізде оқылатын кілт басқа шот астында немесе қатаңдатылған үй каталогы параметрімен жұмыс істейтін қызмет үшін оқылмайтын болуы мүмкін.

Провайдер параметрін профильдің қасына жазыңыз және екі пәрменді тестті сол жерде ұстаңыз. Кейінгі жаңарту legacy провайдерін алып тастаса, сол тестті қайта іске қосып, кілтке ол әлі қажет пе, әлде профильді бұл айналма шешімнен шығаруға бола ма, соны көріңіз.

Сұраныс — кемінде үш себебі бар симптом, және олардың тек біреуі ғана жоғалған құпияфраза.

Қатысты мақалалар