AWS Client VPN: серверны сертыфікат і роля кліенцкага сертыфіката

Канчатковаму пункту Client VPN заўсёды патрэбны TLS-сертыфікат сервера. Гэта тая ідэнтычнасць, якую кіраваны канчатковы пункт прад'яўляе пры падключэнні кліента. Гэта іншы аб'ект, чым сертыфікаты, якія прад'яўляюць асобныя кліенты пры ўзаемнай аўтэнтыфікацыі. Блытаць іх — самая частая прычына, чаму інакш правільная налада ACM усё роўна зрываецца на першым жа падключэнні.

Ніжэй — праход ад кансолі вонкі, у тым парадку, у якім злучэнне сапраўды ідзе.

Дзве ролі, адзін канчатковы пункт

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

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

Што робіць сертыфікат сервера ў ACM

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

Выбірайце шлях атрымання па тым, хто можа прадоўжыць сертыфікат, а не па тым, які выпадкова даў файл, што выглядае правільным.

Што дадае ўзаемная аўтэнтыфікацыя

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

Метад аўтэнтыфікацыі канчатковага пункта — гэта выбар, а не ўсеагульнае патрабаванне.

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

Чаму той жа ARN CA — не абмен ключамі

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

Калі CA кліента — іншы выдавец, дакументаваны шлях — імпартаваць гэты CA у ACM і выбраць яго для ролі кліента.

Вярніце збой да этапу

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

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

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

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