Penyiapan sertifikat IKEv2 di iPhone: pendaftaran manual atau terkelola

Memilih RSA karena alat sertifikat gateway menggunakannya secara default adalah keputusan yang diambil sebelum pertanyaan yang penting: bagaimana iPhone ini akan didaftarkan? Koneksi yang diketik pengguna dan profil konfigurasi yang dikirim oleh manajemen menampilkan pengaturan berbeda, dan sebagian pilihan sertifikat hanya ada di salah satu jalur itu. Atur urutannya dengan benar dan rencana sertifikat menjadi singkat; salah urutan dan Anda menerbitkan kredensial yang tidak akan dipakai telepon. Perlakukan langkah-langkah di bawah sebagai rangkaian, karena setiap langkah mempersempit pilihan yang tersedia bagi langkah berikutnya.

Langkah pertama: pilih jalur pendaftaran

Penyiapan manual berarti pengguna memasukkan alamat server, memilih metode autentikasi, dan menyediakan kredensial apa pun yang diizinkan antarmuka. Pendaftaran terkelola berarti profil membawa alamat, pengenal, dan rujukan ke muatan kredensial. Jalur terkelola dapat menyatakan kombinasi yang tidak dapat dilakukan layar manual, karena itu keputusan sertifikat harus datang setelah pilihan ini, bukan sebelumnya.

Kedua jalur dapat mengautentikasi telepon. Keduanya berbeda dalam hal yang dapat dikonfigurasi dan siapa yang memiliki identitas, jadi pilih satu dengan sengaja alih-alih mencampur profil terkelola dengan entri kredensial manual.

Langkah kedua: pilih algoritme untuk jalur yang Anda pilih

Untuk iPhone yang dikonfigurasi manual, catatan interoperabilitas iOS dari strongSwan menyarankan sertifikat server RSA, karena klien manual mungkin tidak menerima sertifikat server ECDSA; catatan yang sama menangani macOS secara terpisah. Bacalah itu sebagai panduan untuk kumpulan klien yang didukung, bukan hukum permanen tentang perangkat Apple. Profil terkelola memiliki lebih banyak ruang: ia dapat memilih jenis sertifikat secara eksplisit, termasuk identitas klien ECDSA, ketika muatan dan gateway keduanya mendukungnya.

Validasi versi iOS yang benar-benar Anda dukung sebelum menerapkan apa pun. Telepon laboratorium pada rilis terbaru tidak menggambarkan armada yang mencakup perangkat lama, dan algoritme yang berfungsi di laboratorium tetap bisa gagal pada telepon tertua di lapangan. Ambil rentang versi dari manajemen perangkat, bukan dari ingatan. Jika armada mencakup beberapa rilis, uji yang tertua lebih dulu, karena di sanalah antarmuka manual paling membatasi.

Langkah ketiga: baca bidang profil sebagai hal-hal terpisah

Beberapa kunci dengan nama serupa menggambarkan objek yang berbeda. Alamat jarak jauh adalah host yang dihubungi telepon. Pengenal jarak jauh adalah identitas IKE yang diharapkan telepon akan ditampilkan gateway. Rujukan sertifikat pada muatan menunjuk ke kredensial klien, dan bidang jenis sertifikat memilih jenis yang dipakai untuk autentikasi mesin IKEv2. Tidak satu pun dari itu adalah algoritme tanda tangan CA, meskipun kata-katanya tumpang tindih.

Rujukan muatan IKEv2 Apple mencantumkan RSA sebagai jenis sertifikat default dengan varian ECDSA eksplisit, dan mengikat kunci nama penerbit ke pengaturan autentikasi tertentu. Baca hubungan itu di rujukan untuk metode yang Anda pilih alih-alih menyalin satu kunci dari penerapan yang berfungsi.

Langkah keempat: selaraskan identitas gateway dengan sertifikatnya

Gunakan nama gateway eksplisit, misalnya vpn.example.com dan letakkan nama subjek alternatif yang cocok di sertifikat server. Panduan Apple dari strongSwan juga mengharapkan penggunaan kunci diperluas untuk autentikasi server. Memilih RSA atau ECDSA tidak mengubah hal itu: algoritme tidak dapat memperbaiki ketidakcocokan nama, EKU yang hilang, atau rantai yang tidak lengkap.

Mendistribusikan jangkar kepercayaan adalah tugas terpisah dari menegaskan identitas. Telepon membutuhkan rantai sertifikat yang dapat divalidasi, dan harus dikonfigurasi untuk mengharapkan nama yang benar-benar Anda masukkan ke sertifikat.

Platform lain yang berhasil terhubung adalah bukti tentang aturan validasi platform itu, bukan izin untuk melonggarkan aturan telepon. Jaga pemeriksaan tetap sama di seluruh klien kecuali Anda punya alasan terdokumentasi untuk berbeda.

Langkah kelima: pisahkan identitas klien dari kepercayaan CA

Sertifikat klien dan kunci privatnya bukan objek yang sama dengan sertifikat CA yang dipercaya telepon. Membungkus sertifikat CA di dalam identitas PKCS#12 tidak otomatis memasangnya sebagai jangkar kepercayaan pada setiap perangkat yang didukung, jadi perlakukan distribusi kepercayaan sebagai langkah tersendiri dengan verifikasinya sendiri.

Jika desain menggunakan EAP berbasis kata sandi, telepon membutuhkan autentikasi akun yang dimaksud ditambah validasi server. Jalur itu tidak membenarkan pengiriman satu kunci privat klien bersama ke seluruh armada, yang merupakan desain berbeda dengan mode kegagalan jauh lebih buruk.

Akhiri rencana dengan mempertimbangkan pembaruan dan pencabutan: siapa menerbitkan ulang kredensial klien, bagaimana profil diperbarui, dan bagaimana telepon yang hilang diputus. Catat versi profil dan versi perangkat yang Anda gunakan untuk validasi, karena catatan itulah yang membuat rotasi sertifikat berikutnya menjadi perubahan rutin.