Барање за клуч на OpenVPN по OpenSSL 3: проверете го провајдерот

Никој не го допре профилот, а сепак истиот клиент сега бара пристапна фраза за приватниот клуч при секое стартување. Кога таа промена се појавува во рок од неколку дена по надградба на дистрибуцијата, веројатната причина е самата надградба: 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 провајдерот, извршете го тој тест повторно за да видите дали на клучот и понатаму му треба или профилот може да се извади од привременото решение.

Барањето е симптом со најмалку три причини, и само една од нив е пристапна фраза што недостасува.