Точна VPN лозинка не може да замени сертификат што недостасува

Податоците за најава се точни, профилот се увезува чисто, а врската сѐ уште не успева пред автентикацијата да заврши. Во Windows пораката може да биде грешка 798, за сертификат што не е пронајден за методот EAP. На OpenVPN дневникот на клиентот покажува TLS ракување што никогаш не го задоволува серверот. Двете опишуваат истиот објект што недостасува: клиентски сертификат што клиентот требало да го претстави.

Лозинката докажува знаење на тајна; сертификатот докажува поседување на клуч, и едното не го заменува другото.

Лозинката никогаш не беше проблемот

Грешката 798 е неуспешно барање на сертификат. Од клиентот беше побарано сертификат што одговара на конфигурираниот метод за автентикација, тој го прегледа своето складиште и не најде ништо употребливо. Тоа може да значи дека сертификатот недостасува, е присутен без приватниот клуч, е истечен или е зачуван таму каде што барањето не стигнува. Повторното внесување на лозинката не може да промени ниту еден од тие услови, затоа грешката се враќа и со точни податоци.

Прочитајте ја пораката пред да постапите. Одбивање на податоци за најава, неуспешно барање на сертификат и неуспешно TLS ракување се три различни наоди, и само еден од нив ја вклучува лозинката.

Што треба да содржи клиентското складиште

Вклучени се два објекта. Клиентскиот сертификат мора да биде инсталиран за корисникот што го извршува VPN клиентот, заедно со неговиот приватен клуч, а коренот што го издава мора да биде доверлив. Датотеката .cer содржи само јавен сертификат, така што сама по себе не може ништо да автентицира. Во управникот со сертификати на Windows, идентитетот на клиентот припаѓа на личното складиште на тековниот корисник, а коренот во складиштето на доверливи корени.

Инсталирањето на идентитетот во складиштето на машината, или само во складиштето на корените, не задоволува барање насочено кон личното складиште на корисникот. Проверете ги складиштето, ознаката за приватен клуч и датумите на важност заедно, потоа рестартирајте го клиентот за повторно да го прочита складиштето.

Два производи, истиот податок што недостасува

OpenVPN серверите стандардно бараат клиентски сертификат. Додавањето auth-user-pass на клиент испраќа корисничко име и лозинка, а TLS ракувањето сѐ уште бара сертификат, па само лозинка не може да ја заврши врската под verify-client-cert require. Серверот може да се постави да не бара ништо, што ја прави лозинката единствен податок на клиентот и претставува вистинско намалување на јачината. Shell скрипта зад auth-user-pass-verify може да ги валидира податоците, а бара вклучено извршување на скрипти, што ја прави поризичен дизајн од соодветен автентикациски бекенд.

Профил заснован само на лозинка зависи и од туркани опции, кои пак зависат од вклучениот механизам за влечење.

Не го поправајте сертификатот што недостасува со исклучување на проверките

Искушението е да се олесни верификацијата за да исчезне пораката. Тоа ја отстранува контролата што ја вршеше својата работа и остава врска што повеќе не го докажува тоа што го тврди. Ако портата неодамна го сменила својот корен, преземете го клиентскиот пакет повторно наместо да го уредувате профилот, бидејќи стариот пакет може сѐ уште да го носи претходниот корен. Ако опцијата за автентикација со сертификат недостасува во уредувачот на профили, инсталираната верзија на Windows можеби не го изложува тој метод; ажурирајте го системот наместо рачно да уредувате XML.

Забележете во кое складиште бил сертификатот, кој корисник го извршил клиентот и дали приватниот клуч бил присутен. Тие три објаснуваат речиси секој случај на овој неуспех.

Лозинката беше во ред. Податокот што на методот навистина му требаше беше на друго место.