راه‌اندازی گواهی IKEv2 در iPhone: ثبت‌نام دستی در برابر ثبت‌نام مدیریت‌شده
مسیر ثبت‌نام تعیین می‌کند که کدام گزینه‌های گواهی وجود دارند. ابتدا دستی یا مدیریت‌شده را انتخاب کنید، سپس هویت سرور، اعتبارنامهٔ مشتری و الگوریتم را تطبیق دهید.
انتخاب RSA به این دلیل که ابزار گواهی دروازه به‌طور پیش‌فرض از آن استفاده می‌کند، تصمیمی است که پیش از پرسش مهم گرفته می‌شود: این iPhoneها چگونه ثبت‌نام خواهند شد؟ اتصالی که کاربر خودش وارد می‌کند و نمایهٔ پیکربندی‌ای که مدیریت تحویل می‌دهد تنظیمات متفاوتی ارائه می‌کنند و برخی گزینه‌های گواهی فقط در یکی از این دو مسیر وجود دارند. ترتیب را درست بچینید تا برنامهٔ گواهی کوتاه شود؛ اشتباه کنید و اعتبارنامه‌ای صادر می‌کنید که تلفن از آن استفاده نخواهد کرد. مراحل زیر را یک زنجیره در نظر بگیرید، چون هر کدام گزینه‌های موجود برای مرحلهٔ بعد را تنگ‌تر می‌کند.
مرحلهٔ اول: مسیر ثبت‌نام را انتخاب کنید
راه‌اندازی دستی یعنی کاربر نشانی سرور را وارد می‌کند، روش احراز هویت را انتخاب می‌کند و هر اعتبارنامه‌ای را که رابط اجازه دهد ارائه می‌دهد. ثبت‌نام مدیریت‌شده یعنی نمایه نشانی، شناسه‌ها و ارجاعی به محمولهٔ اعتبارنامه را حمل می‌کند. مسیر مدیریت‌شده می‌تواند ترکیب‌هایی را بیان کند که صفحهٔ دستی نمی‌تواند، و به همین دلیل تصمیم گواهی باید پس از این انتخاب بیاید نه پیش از آن.
هر دو مسیر می‌توانند تلفن را احراز هویت کنند. آن‌ها در آنچه می‌توانید پیکربندی کنید و در اینکه مالک هویت کیست تفاوت دارند، پس آگاهانه یکی را انتخاب کنید به‌جای اینکه نمایهٔ مدیریت‌شده را با ورود دستی اعتبارنامه ترکیب کنید.
مرحلهٔ دوم: الگوریتم‌ها را برای مسیری که انتخاب کردید برگزینید
برای iPhoneهایی که دستی پیکربندی شده‌اند، یادداشت‌های سازگاری strongSwan با iOS گواهی سرور RSA را توصیه می‌کنند، چون مشتری دستی ممکن است گواهی سرور ECDSA را نپذیرد؛ همان یادداشت‌ها macOS را جداگانه بررسی می‌کنند. این را راهنمایی برای مجموعهٔ مشتریان پشتیبانی‌شده بخوانید، نه قانونی دائمی دربارهٔ دستگاه‌های Apple. نمایهٔ مدیریت‌شده فضای بیشتری دارد: می‌تواند نوع گواهی را به‌صراحت انتخاب کند، از جمله هویت مشتری ECDSA، وقتی محموله و دروازه هر دو از آن پشتیبانی کنند.
پیش از هر استقراری، نسخه‌های iOS را که واقعاً پشتیبانی می‌کنید اعتبارسنجی کنید. تلفن آزمایشگاهی با جدیدترین نسخه، ناوگانی را توصیف نمی‌کند که دستگاه‌های قدیمی‌تر را دربر می‌گیرد، و الگوریتمی که در آزمایشگاه کار می‌کند ممکن است روی قدیمی‌ترین تلفن در میدان شکست بخورد. بازهٔ نسخه‌ها را از مدیریت دستگاه‌ها بگیرید نه از حافظه. اگر ناوگان چند نسخه را دربر می‌گیرد، ابتدا قدیمی‌ترین را آزمایش کنید، چون رابط دستی همان‌جا محدودترین است.
مرحلهٔ سوم: فیلدهای نمایه را چیزهای جداگانه بخوانید
چند کلید با نام‌های مشابه اشیای متفاوتی را توصیف می‌کنند. نشانی راه دور میزبان مورد تماس تلفن است. شناسهٔ راه دور همان هویت IKE است که انتظار دارد دروازه ارائه کند. ارجاع گواهی در محموله به اعتبارنامهٔ مشتری اشاره می‌کند و فیلد نوع گواهی، نوعی را انتخاب می‌کند که برای احراز هویت ماشین IKEv2 به کار می‌رود. هیچ‌کدام از این‌ها الگوریتم امضای CA نیست، هرچند واژه‌ها هم‌پوشانی دارند.
مرجع محمولهٔ IKEv2 اپل، RSA را به‌عنوان نوع گواهی پیش‌فرض با گونه‌های صریح ECDSA فهرست می‌کند و کلید نام صادرکننده را به تنظیمات احراز هویت مشخصی گره می‌زند. این روابط را در مرجع روشی که انتخاب کرده‌اید بخوانید، نه اینکه کلیدی را از یک استقرار کارکننده کپی کنید.
مرحلهٔ چهارم: هویت دروازه را با گواهی‌اش همسان کنید
از یک نام دروازهٔ صریح استفاده کنید، مثلاً vpn.example.com و یک نام جایگزین موضوع همسان را در گواهی سرور بگذارید. راهنمای strongSwan برای Apple همچنین استفادهٔ گسترده از کلید برای احراز هویت سرور را انتظار دارد. انتخاب RSA یا ECDSA هیچ‌کدام از این‌ها را تغییر نمی‌دهد: الگوریتم نمی‌تواند ناسازگاری نام، نبود EKU یا زنجیرهٔ ناقص را ترمیم کند.
توزیع لنگر اعتماد کاری جدا از اثبات هویت است. تلفن به زنجیرهٔ گواهی نیاز دارد که بتواند اعتبارسنجی کند و باید طوری پیکربندی شود که همان نامی را انتظار داشته باشد که واقعاً در گواهی گذاشته‌اید.
اتصال موفق پلتفرم دیگر شواهدی دربارهٔ قواعد اعتبارسنجی همان پلتفرم است، نه اجازهٔ سست کردن قواعد تلفن. بازبینی‌ها را میان مشتریان یکسان نگه دارید مگر اینکه دلیل مستندی برای تفاوت داشته باشید.
مرحلهٔ پنجم: هویت مشتری را از اعتماد به CA جدا کنید
گواهی مشتری و کلید خصوصی‌اش همان شیء گواهی CA نیست که تلفن به آن اعتماد دارد. گنجاندن گواهی CA درون هویت PKCS#12 آن را به‌طور خودکار به‌عنوان لنگر اعتماد روی هر دستگاه پشتیبانی‌شده نصب نمی‌کند، پس توزیع اعتماد را مرحله‌ای جداگانه با بازبینی خودش بدانید.
اگر طراحی به‌جای آن از EAP مبتنی بر گذرواژه استفاده می‌کند، تلفن به احراز هویت حساب موردنظر به‌همراه اعتبارسنجی سرور نیاز دارد. این مسیر ارسال یک کلید خصوصی مشتری مشترک به کل ناوگان را توجیه نمی‌کند، که طراحی متفاوتی با حالت شکست بسیار بدتر است.
برنامه را با در نظر گرفتن تمدید و ابطال تمام کنید: چه کسی اعتبارنامهٔ مشتری را دوباره صادر می‌کند، نمایه چگونه به‌روزرسانی می‌شود و تلفن گم‌شده چگونه قطع می‌شود. نسخهٔ نمایه و نسخه‌های دستگاهی را که با آن‌ها اعتبارسنجی کردید ثبت کنید، چون همان سابقه است که چرخش گواهی بعدی را به تغییری روتین تبدیل می‌کند.