Düzgün VPN parolu itkin sertifikatı əvəz edə bilməz

Etimad məlumatları doğrudur, profil təmiz idxal olunur və bağlantı yenə də autentifikasiya tamamlanmadan uğursuz olur. Windows-da mesaj EAP metodu üçün tapılmayan sertifikatla bağlı 798 xətası ola bilər. OpenVPN üzərində müştəri jurnalı serveri heç vaxt qane etməyən TLS əl sıxışması göstərir. Hər ikisi eyni itkin obyekti təsvir edir: müştərinin təqdim etməli olduğu müştəri sertifikatı.

Parol bir sirri bilməyi sübut edir; sertifikat isə açara sahib olmağı sübut edir və biri digərini əvəz etmir.

Parol heç vaxt problem deyildi

798 xətası sertifikat axtarışının uğursuzluğudur. Müştəridən konfiqurasiya edilmiş autentifikasiya metoduna uyğun sertifikat tələb olundu, o, öz anbarını axtardı və istifadəyə yararlı heç nə tapmadı. Bu o demək ola bilər ki, sertifikat yoxdur, şəxsi açarı olmadan mövcuddur, müddəti bitib və ya axtarışın çatmadığı yerdə saxlanılır. Parolu yenidən cəhd etmək bu şərtlərdən heç birini dəyişə bilməz, buna görə də xəta düzgün etimad məlumatları ilə qayıdır.

Mesajı oxuyun, sonra hərəkət edin. Etimad məlumatının rədd edilməsi, sertifikat axtarışının uğursuzluğu və TLS əl sıxışmasının uğursuzluğu üç fərqli tapıntıdır və yalnız biri parolla bağlıdır.

Müştəri anbarında nə olmalıdır

İki obyekt iştirak edir. Müştəri sertifikatı VPN müştərisini işlədən istifadəçi üçün şəxsi açarı ilə birlikdə quraşdırılmalı, verən kökə isə etimad edilməlidir. .cer faylı yalnız açıq sertifikatı ehtiva edir, ona görə də tək başına heç nəyi autentifikasiya edə bilməz. Windows sertifikat menecerində müştəri kimliyi cari istifadəçinin şəxsi anbarına, kök isə etibarlı kök anbarına aiddir.

Kimliyi maşın anbarına və ya yalnız kök anbarına quraşdırmaq istifadəçinin şəxsi anbarına yönəlmiş axtarışı təmin etmir. Anbarı, şəxsi açar işarəsini və etibarlılıq tarixlərini birlikdə yoxlayın, sonra anbarı yenidən oxuması üçün müştərini yenidən başladın.

İki məhsul, eyni itkin etimad məlumatı

OpenVPN serverləri standart olaraq müştəri sertifikatı tələb edir. Müştəriyə auth-user-pass əlavə etmək istifadəçi adı və parol göndərir, TLS əl sıxışması isə yenə sertifikat istəyir, buna görə də yalnız parol verify-client-cert require altında bağlantını tamamlaya bilməz. Server heç nə tələb etməmək üçün qurula bilər, bu da parolu yeganə müştəri etimad məlumatına çevirir və gücdə real azalmadır. auth-user-pass-verify arxasındakı shell skripti etimad məlumatlarını yoxlaya bilər və bu, skript icrasının aktivləşdirilməsini tələb edir, bu da onu düzgün autentifikasiya backend-indən daha riskli dizayn edir.

Yalnız parola əsaslanan profil həmçinin ötürülən seçimlərdən asılıdır, onlar da öz növbəsində çəkmə mexanizminin aktiv olmasından asılıdır.

İtkin sertifikatı yoxlamaları söndürməklə düzəltməyin

Cazibə mesaj yox olsun deyə yoxlamanı yumşaltmaqdır. Bu, öz işini görən nəzarəti aradan qaldırır və artıq iddia etdiyini sübut etməyən bağlantı qoyur. Şlüz yaxınlarda kökünü dəyişibsə, profili redaktə etmək əvəzinə müştəri paketini yenidən yükləyin, çünki köhnə paket hələ də əvvəlki kökü daşıya bilər. Sertifikat autentifikasiyası seçimi profil redaktorunda yoxdursa, quraşdırılmış Windows versiyası bu metodu göstərməyə bilər; XML-i əl ilə redaktə etmək əvəzinə sistemi yeniləyin.

Sertifikatın hansı anbarda olduğunu, müştərini hansı istifadəçinin işlətdiyini və şəxsi açarın mövcud olub-olmadığını qeyd edin. Bu üçü bu uğursuzluğun demək olar ki, hər halını izah edir.

Parol yaxşı idi. Metodun əslində ehtiyac duyduğu etimad məlumatı başqa yerdə idi.