Правільны пароль 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.

Запішыце, у якім сховішчы быў сертыфікат, які карыстальнік запускаў кліент і ці быў прысутны прыватны ключ. Гэтыя тры пункты тлумачаць амаль кожны выпадак гэтай няўдачы.

Пароль быў правільны. Уліковыя даныя, якія метад насамрэч патрабаваў, былі ў іншым месцы.