Правилна парола за 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 ръчно.

Запишете кое хранилище е съдържало сертификата, кой потребител е стартирал клиента и дали частният ключ е присъствал. Тези три неща обясняват почти всеки случай на този провал.

Паролата беше наред. Идентификаторът, който методът всъщност изискваше, беше другаде.