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

Захтев је симптом са најмање три узрока, и само један од њих је приступна фраза која недостаје.