OpenSSL 3-dən sonra OpenVPN açar sorğusu: provayderi yoxlayın

Heç kim profilo toxunmayıb, lakin eyni klient indi hər dəfə işə düşəndə şəxsi açar üçün parol tələb edir. Bu dəyişiklik distributiv yenilənməsindən bir neçə gün ərzində baş verirsə, çox güman ki, səbəb yenilənmənin özüdür: OpenSSL 3 alqoritm dəstəyini yenidən təşkil etdi və köhnə kitabxananın asanlıqla oxuduğu açar bir bayt dəyişmədən oxunmaz hala gələ bilər. Yoxlamaları ardıcıllıqla aparın, çünki onlardan ikisi yalnız sorğuya baxanda eyni görünür.

Birinci sual açarın şifrələnib-şifrələnmədiyi, ikincisi isə bu buildin onu deşifrə edə bilib-bilmədiyidir. Konfiqurasiya dəyişiklikləri yalnız hər iki cavab bilindikdən sonra məntiqlidir.

Açarın şifrələndiyini yoxlayın

Faylın ilk sətrini oxuyun və sonra kitabxananın onu təhlil etməsinə icazə verin, çünki fayl adı heç nə sübut etmir. Etiketli PEM bloku ENCRYPTED PRIVATE KEY şifrələnmiş PKCS#8-dir, daha köhnə RSA PRIVATE KEY bloku isə Proc-Type: 4,ENCRYPTED daşıyan ənənəvi formadır; hər ikisi parol gözləyir. Şifrələnməmiş PRIVATE KEY bloku ümumiyyətlə parol istəməməlidir. Təhlili faylın sahibi olan hesabla işə salın, çünki icazə problemi fərqli və qat-qat az maraqlı xəta verir.

Əgər açar həqiqətən şifrələnməyibsə və klient hələ də soruşursa, kriptoqrafiyaya baxmağı dayandırın və profilin xidmətin hələ də oxuya bildiyi askpass faylını göstərib-göstərmədiyini yoxlayın.

Bu buildin onu deşifrə edə bildiyini yoxlayın

OpenSSL 3 alqoritm dəstəyini provayderlərə böldü və bir sıra köhnə şifrlər indi standart provayderdə deyil, legacy provayderdə yerləşir. Bu şifrlərdən biri ilə şifrələnmiş açar etibarlı qalır, lakin legacy provayder olmadan yüklənən kitabxana onu deşifrə edə bilmir. Bəzi klientlərdə bu, təkrarlanan sorğu kimi, digərlərində isə paroldan dərhal sonra sərt uğursuzluq kimi görünür.

Eyni açarı eyni binary ilə iki dəfə təhlil edin: əvvəlcə yalnız standart provayderlə, sonra komanda sətrində həm legacy, həm də standart istənilmiş halda. İkinci cəhd birincinin uğursuz olduğu yerdə uğur qazanırsa, diaqnoz yenilənmənin vaxtına deyil, sübuta əsaslanır. Hər ikisi eyni şəkildə uğursuz olursa, parol səhvdir və ya fayl zədəlidir və heç bir provayder ayarı bunların heç birini düzəltmir.

Ən dar mövcud düzəlişi yoxlayın

Sistem üzrə dəyişiklikdən çox klientlə məhdudlaşan dəyişikliyə üstünlük verin. Bəzi 2.6 buildləri həmin daemon prosesi üçün hər iki provayderi yükləyən profil seçimini qəbul edir, ona görə də etibar etməzdən əvvəl direktivi dəqiq versiyanız üçün təlimata uyğun təsdiqləyin; əvəzində sistem openssl.cnf faylını redaktə etmək hostdakı hər OpenSSL proqramına təsir edir. Açar yenidən kodlaşdırıldıqdan sonra dar ayar geri qaytarmaq baxımından da qat-qat asandır.

Sorğunun yox olması üçün parolu silməyin. Bu, qorunan etimad məlumatını açıq mətn faylına çevirir və onun yer aldığı hər ehtiyat nüsxənin, kopyanın və dəstək paketinin riskini səssizcə dəyişir. Vacib olan fərq paroluna ehtiyacı olan açar ilə bu kitabxananın deşifrə edə bilmədiyi açar arasındadır.

Xidmət kontekstini yoxlayın, sonra yenidən kodlaşdırın

Açar açıla bildikdən sonra onu müasir alqoritmlə yenidən şifrələyin ki, asılılıq yox olsun. Yeni faylı müasir şifrlə yazın, təhlil olunduğunu yoxlayın, profili yeniləyin və köhnə kopyanı yalnız əlaqə uğur qazanana qədər saxlayın. Parolu heç vaxt komanda sətrinə qoymayın, çünki istənilən yerli istifadəçi onu proses siyahısından oxuya bilər. Köhnə faylı yalnız yeni fayl xidmət hesabından qoşulduqdan sonra silin, təkcə sizin shellinizdən deyil.

Sonra klienti həqiqətən işə salan vahidi yoxlayın. Shellinizdə oxuna bilən açar fərqli hesab altında və ya sərtləşdirilmiş ev kataloqu ayarı ilə işləyən xidmət üçün oxunmaz ola bilər.

Provayder ayarını profilin yanında qeyd edin və iki əmrdən ibarət testi onunla birlikdə saxlayın. Sonrakı yenilənmə legacy provayderi çıxardıqda həmin testi yenidən işə salın ki, açarın ona hələ də ehtiyacı olub-olmadığını və ya profilin bu keçici həlldən çıxarıla biləcəyini görəsiniz.

Sorğu ən azı üç səbəbi olan bir simptomdur və onlardan yalnız biri itkin paroldur.