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

Парадак важны: апошнія два пытанні маюць сэнс толькі тады, калі вы ведаеце, які матэрыял павінен існаваць.

Пачніце з таго, што ўжо змяшчае профіль

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Праверце дастаўлены пакет на прадмет файлаў, на якія спасылаецца профіль: сертыфікат CA, часам асобны сертыфікат кліента і ключ, а магчыма, файл tls-auth або tls-crypt. Профіль, які спасылаецца на чатыры файлы, а прыходзіць з двума, няпоўны, і ніякая колькасць паказальных палёў гэтага не выправіць. Папрасіце ў аператара адсутную частку, замест таго каб падстаўляць сертыфікат, які ў вас выпадкова ёсць.

Аддзяліце чатыры віды матэрыялу

Сертыфікат CA — публічны матэрыял, які выкарыстоўваецца для праверкі ідэнтычнасці сервера. Сертыфікат кліента паказвае серверу карыстальніка або прыладу. Прыватны ключ — сакрэтная палова гэтага сертыфіката кліента, і ён ніколі не павінен быць ключом подпісу CA або ключом сервера. Матэрыял tls-auth або tls-crypt — асобны агульны сакрэт, які абараняе канал кіравання. Гэтыя чатыры не ўзаемазамяняльныя, і накіраванне поля CA на сертыфікат кліента дае збой праверкі, які выглядае як праблема даверу.

Аўтэнтыфікацыя толькі па паролі змяняе, які з чатырох вам патрэбны, а не іх сэнс. З auth-user-pass і remote-cert-tls server кліент усё яшчэ правярае сервер супраць CA, таму поле CA з'яўляецца нават тады, калі сертыфіката кліента няма. Палітыка аператара вырашае, ці патрэбны таксама сертыфікат кліента, і ніякі дыялог не можа гэта вам паведаміць.

Накіруйце кліент на файл даверу

Выберыце сам файл сертыфіката CA, а не папку, якая яго змяшчае, і не пакет .p12, які змяшчае ідэнтычнасць кліента. У Windows сінтаксіс шляху і выбар файла паводзяць сябе інакш, чым у прыкладах для Linux у большасці кіраўніцтваў, таму выкарыстоўвайце тое, што прымае ўсталяваны кліент, і пацвердзіце, што файл чытэльны для ўліковага запісу, які яго запускае. Праблема правоў і адсутны файл выглядаюць у дыялогу аднолькава, але даюць розныя радкі журналу. Пасля выбару зноў адкрыйце налады профілю, каб пераканацца, што кліент захаваў выбар.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

Чытайце наступную памылку, а не тую ж самую

Мэта падачы правільнага CA — змяніць памылку, а не прымусіць яе знікнуць. Збой ідэнтычнасці сервера пасля загрузкі CA азначае, што сертыфікат не супаў з чаканым імем або з чаканнем remote-cert-tls, і гэта іншае выпраўленне, чым адмова ў паролі. Адмова ў паролі азначае, што ўзровень TLS прайшоў, а ўліковыя даныя няверныя. Захавайце першае новае паведамленне; менавіта яно карыснае.

Кліент, які падключаецца, але нічога не дасягае, цалкам прайшоў давер і цяпер сутыкаецца з пытаннем маршрутызацыі або DNS.

Ніколі не адключайце праверку, каб абысці гэты дыялог. Кліент, які прымае любы сертыфікат, не мае прычыны пытаць CA, і тунэль, які ён будуе, не той, што меў на ўвазе аператар.

Падобныя артыкулы