Наладжванне сертыфіката IKEv2 на iPhone: ручная і кіраваная рэгістрацыя

Выбар RSA толькі таму, што інструмент сертыфікатаў шлюза патрабуе яго па змаўчанні, — гэта рашэнне, прынятае да пытання, якое мае значэнне: як гэтыя iPhone будуць зарэгістраваныя? Злучэнне, якое карыстальнік уводзіць уручную, і профіль канфігурацыі, які дастаўляе кіраванне, прапануюць розныя налады, і некаторыя варыянты сертыфіката існуюць толькі на адным з гэтых шляхоў. Правільна выбудуйце парадак — і план сертыфіката стане кароткім; памыліцеся — і вы выдадзіце ўліковыя даныя, якія тэлефон не выкарыстае. Разглядайце прыведзеныя ніжэй крокі як паслядоўнасць, бо кожны звужвае выбар, даступны наступнаму.

Крок першы: выберыце шлях рэгістрацыі

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

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

Крок другі: выберыце алгарытмы для абранага шляху

Для iPhone, наладжаных уручную, заўвагі strongSwan аб сумяшчальнасці з iOS рэкамендуюць сертыфікат сервера RSA, бо ручны кліент можа не прыняць сертыфікат сервера ECDSA; тыя ж заўвагі разглядаюць macOS асобна. Чытайце гэта як указанне для падтрымліванага набору кліентаў, а не як пастаянны закон пра прылады Apple. Кіраваны профіль мае больш месца: ён можа відавочна выбраць тып сертыфіката, уключаючы ідэнтычнасць кліента ECDSA, калі карысная нагрузка і шлюз падтрымліваюць гэта адначасова.

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

Крок трэці: чытайце поля профілю як асобныя рэчы

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

Даведнік Apple па карыснай нагрузцы IKEv2 пералічвае RSA як прадвызначаны тып сертыфіката з відавочнымі варыянтамі ECDSA і звязвае ключ імя выдаўца з пэўнымі наладамі аўтэнтыфікацыі. Чытайце гэтыя сувязі ў даведніку для абранага метаду, а не капіруйце адзін ключ з працоўнага разгортвання.

Крок чацвёрты: узгадніце ідэнтычнасць шлюза з яго сертыфікатам

Выкарыстоўвайце відавочнае імя шлюза, напрыклад vpn.example.com і змясціце адпаведнае альтэрнатыўнае імя суб'екта у сертыфікат сервера. Кіраўніцтва strongSwan для Apple таксама чакае пашыранае выкарыстанне ключа для аўтэнтыфікацыі сервера. Выбар RSA або ECDSA нічога з гэтага не змяняе: алгарытм не можа выправіць неадпаведнасць імёнаў, адсутны EKU або няпоўны ланцужок.

Размеркаванне якара даверу — асобная задача ад пацверджання ідэнтычнасці. Тэлефону патрэбны ланцужок сертыфікатаў, які ён можа праверыць, і ён павінен быць наладжаны чакаць тое імя, якое вы сапраўды змясцілі ў сертыфікат.

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

Крок пяты: аддзяліце ідэнтычнасць кліента ад даверу да CA

Сертыфікат кліента і яго прыватны ключ — не той самы аб'ект, што сертыфікат CA, якому давярае тэлефон. Уключэнне сертыфіката CA ўнутры ідэнтычнасці PKCS#12 не ўсталёўвае яго аўтаматычна як якар даверу на кожнай падтрымліванай прыладзе, таму разглядайце размеркаванне даверу як асобны крок з уласнай праверкай.

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

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