Настройка на сертификат 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 с парола, телефонът се нуждае от предвиденото удостоверяване на акаунта плюс валидиране на сървъра. Този път не оправдава изпращането на един споделен частен клиентски ключ до целия парк, което е различен дизайн с много по-лош режим на отказ.

Завършете плана с мисъл за подновяване и отзоваване: кой преиздава клиентските идентификационни данни, как се актуализира профилът и как се отрязва изгубен телефон. Записвайте версията на профила и версиите на устройствата, срещу които сте валидирали, защото този запис прави следващата смяна на сертификата рутинна промяна.