إعداد شهادة IKEv2 على iPhone: التسجيل اليدوي مقابل التسجيل المُدار

اختيار RSA لأن أداة شهادات البوابة تعتمدها افتراضياً قرار يُتخذ قبل السؤال الأهم: كيف ستُسجَّل هواتف iPhone هذه؟ الاتصال الذي يكتبه المستخدم يدوياً والملف التعريفي الذي تُسلّمه الإدارة يعرضان إعدادات مختلفة، وبعض خيارات الشهادة لا توجد إلا في أحد المسارين. اضبط الترتيب بشكل صحيح يصبح مخطط الشهادة قصيراً؛ أخطئ فيه وتُصدر بيانات اعتماد لن يستخدمها الهاتف. تعامل مع الخطوات أدناه كتسلسل، لأن كل خطوة تضيّق الخيارات المتاحة للخطوة التالية.

الخطوة الأولى: اختر مسار التسجيل

الإعداد اليدوي يعني أن يدخل المستخدم عنوان الخادم، ويختار طريقة المصادقة، ويقدّم أي بيانات اعتماد تسمح بها الواجهة. التسجيل المُدار يعني أن يحمل ملف تعريفي العنوان والمعرّفات ومرجعاً إلى حِزمة بيانات اعتماد. يستطيع المسار المُدار التعبير عن توليفات لا تستطيع الشاشة اليدوية التعبير عنها، ولهذا يجب أن يأتي قرار الشهادة بعد هذا الاختيار لا قبله.

كلا المسارين يستطيع مصادقة الهاتف. يختلفان في ما يمكنك إعداده وفي من يملك الهوية، فاختر مساراً واحداً عن قصد بدلاً من خلط ملف تعريفي مُدار بإدخال يدوي لبيانات الاعتماد.

الخطوة الثانية: اختر الخوارزميات للمسار الذي اخترته

بالنسبة إلى هواتف iPhone المُعدّة يدوياً، توصي ملاحظات التوافق مع iOS من strongSwan بشهادة خادم RSA، لأن العميل اليدوي قد لا يقبل شهادة خادم ECDSA؛ والملاحظات نفسها تتناول macOS بشكل منفصل. اقرأ ذلك كإرشاد لمجموعة العملاء المدعومة لا كقانون دائم بشأن أجهزة Apple. الملف التعريفي المُدار لديه مساحة أوسع: يمكنه اختيار نوع الشهادة صراحةً، بما في ذلك هوية عميل ECDSA، عندما تدعم الحِزمة والبوابة ذلك معاً.

تحقّق من إصدارات iOS التي تدعمها فعلاً قبل نشر أي شيء. هاتف مختبر بأحدث إصدار لا يصف أسطولاً يضم أجهزة أقدم، والخوارزمية التي تعمل في المختبر قد تفشل مع ذلك على أقدم هاتف في الميدان. استخرج نطاق الإصدارات من إدارة الأجهزة لا من ذاكرتك. إذا كان الأسطول يمتد عبر إصدارات، فاختبر الأقدم أولاً، لأن الواجهة اليدوية هي الأكثر تقييداً هناك.

الخطوة الثالثة: اقرأ حقول الملف التعريفي كأشياء منفصلة

عدة مفاتيح متشابهة الأسماء تصف كائنات مختلفة. العنوان البعيد هو المضيف الذي يتصل به الهاتف. المعرّف البعيد هو هوية IKE التي يتوقع أن تعرضها البوابة. مرجع شهادة الحِزمة يشير إلى بيانات اعتماد عميل، وحقل نوع الشهادة يختار النوع المستخدم لمصادقة الجهاز عبر IKEv2. لا شيء من ذلك هو خوارزمية توقيع CA، رغم تداخل الكلمات.

يسرد مرجع حِزمة IKEv2 من Apple خوارزمية RSA كنوع الشهادة الافتراضي مع صيغ ECDSA صريحة، ويربط مفتاح اسم المُصدر بإعدادات مصادقة معينة. اقرأ تلك العلاقات من المرجع الخاص بالطريقة التي اخترتها بدلاً من نسخ مفتاح واحد من نشر يعمل.

الخطوة الرابعة: اجعل هوية البوابة تطابق شهادتها

استخدم اسم بوابة صريحاً مثل vpn.example.com وضع اسم موضوع بديل مطابق في شهادة الخادم. ترشد إرشادات strongSwan لأجهزة Apple أيضاً إلى استخدام مفتاح موسّع لاستخدام مصادقة الخادم. اختيار RSA أو ECDSA لا يغيّر شيئاً من ذلك: لا تستطيع الخوارزمية إصلاح عدم تطابق اسم أو غياب EKU أو سلسلة ناقصة.

توزيع مرساة الثقة مهمة منفصلة عن تأكيد الهوية. يحتاج الهاتف إلى سلسلة شهادات يستطيع التحقق منها، ويجب إعداده ليتوقع الاسم الذي وضعته فعلاً في الشهادة.

نجاح منصة أخرى في الاتصال دليل على قواعد التحقق لدى تلك المنصة، وليس إذناً بتخفيف قواعد الهاتف. أبقِ الفحوص متطابقة بين العملاء ما لم يكن لديك سبب موثّق للاختلاف.

الخطوة الخامسة: افصل هوية العميل عن ثقة CA

شهادة العميل ومفتاحها الخاص ليسا الكائن نفسه الذي هو شهادة CA التي يثق بها الهاتف. تضمين شهادة CA داخل هوية PKCS#12 لا يثبّتها تلقائياً كمرساة ثقة على كل جهاز مدعوم، فتعامل مع توزيع الثقة كخطوة قائمة بذاتها بتحقّق خاص بها.

إذا كان التصميم يستخدم EAP القائم على كلمة المرور بدلاً من ذلك، فيحتاج الهاتف إلى مصادقة الحساب المقصودة بالإضافة إلى التحقق من الخادم. هذا المسار لا يبرر تسليم مفتاح خاص واحد مشترك للعميل إلى الأسطول بأكمله، فهو تصميم مختلف بنمط فشل أسوأ بكثير.

أنهِ الخطة مع وضع التجديد والإبطال في الاعتبار: من يعيد إصدار بيانات اعتماد العميل، وكيف يُحدَّث الملف التعريفي، وكيف يُقطع هاتف مفقود. سجّل إصدار الملف التعريفي وإصدارات الأجهزة التي تحققت منها، لأن هذا السجل هو ما يجعل تجديد الشهادة التالي تغييراً روتينياً.