Исправна 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.

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

Лозинка је била исправна. Акредитив који је методи заправо требао био је негде другде.