Ağ geçidinin sertifika aracı varsayılan olarak kullandığı için RSA seçmek, önemli olan sorudan önce verilen bir karardır: bu iPhone'lar nasıl kaydedilecek? Kullanıcının kendi yazdığı bağlantı ile yönetimin sağladığı yapılandırma profili farklı ayarlar sunar ve bazı sertifika seçenekleri bu yollardan yalnızca birinde bulunur. Sırayı doğru kurarsanız sertifika planı kısalır; yanlış kurarsanız telefonun kullanmayacağı bir kimlik bilgisi yayımlarsınız. Aşağıdaki adımları bir sıra olarak ele alın, çünkü her biri bir sonrakinin kullanabileceği seçenekleri daraltır.

Birinci adım: kayıt yolunu seçin

Elle kurulum, kullanıcının sunucu adresini girip kimlik doğrulama yöntemini seçtiği ve arayüzün izin verdiği her türlü kimlik bilgisini sağladığı anlamına gelir. Yönetilen kayıt, bir profilin adresi, tanımlayıcıları ve bir kimlik bilgisi yüküne başvuruyu taşıdığı anlamına gelir. Yönetilen yol, elle ekranın gösteremediği birleşimleri ifade edebilir; bu nedenle sertifika kararı bu seçimden sonra gelmelidir, önce değil.

Her iki yol da bir telefonu doğrulayabilir. Neyin yapılandırılabileceği ve kimliğin kime ait olduğu konusunda farklılaşırlar; bu nedenle yönetilen profili elle kimlik bilgisi girişiyle karıştırmak yerine birini bilinçli olarak seçin.

İkinci adım: seçtiğiniz yol için algoritmaları seçin

Elle yapılandırılmış iPhone'lar için strongSwan'ın iOS birlikte çalışabilirlik notları RSA sunucu sertifikası önerir, çünkü elle istemci ECDSA sunucu sertifikasını kabul etmeyebilir; aynı notlar macOS'u ayrı ele alır. Bunu desteklenen istemci kümesi için bir kılavuz olarak okuyun, Apple aygıtları hakkında kalıcı bir yasa olarak değil. Yönetilen profilin daha fazla alanı vardır: yük ve ağ geçidi ikisi de desteklediğinde ECDSA istemci kimliği dahil sertifika türünü açıkça seçebilir.

Herhangi bir şey dağıtmadan önce gerçekten desteklediğiniz iOS sürümlerini doğrulayın. En yeni sürümdeki laboratuvar telefonu, daha eski aygıtları içeren bir filoyu tanımlamaz ve laboratuvarda çalışan bir algoritma sahada en eski telefonda yine de başarısız olabilir. Sürüm aralığını bellekten değil aygıt yönetiminden alın. Filo birden çok sürümü kapsıyorsa önce en eskisini test edin, çünkü elle arayüzün en kısıtlayıcı olduğu yer orasıdır.

Üçüncü adım: profil alanlarını ayrı şeyler olarak okuyun

Benzer adlı birkaç anahtar farklı nesneleri tanımlar. Uzak adres, telefonun aradığı ana bilgisayardır. Uzak tanımlayıcı, ağ geçidinin sunmasının beklendiği IKE kimliğidir. Yükteki sertifika başvurusu bir istemci kimlik bilgisine işaret eder ve sertifika türü alanı IKEv2 makine kimlik doğrulaması için kullanılan türü seçer. Sözcükler örtüşse de bunların hiçbiri CA'nın imza algoritması değildir.

Apple'ın IKEv2 yük başvurusu, RSA'yı açık ECDSA çeşitleriyle varsayılan sertifika türü olarak listeler ve veren adı anahtarını belirli kimlik doğrulama ayarlarına bağlar. Bu ilişkileri, çalışan bir kurulumdan bir anahtar kopyalamak yerine seçtiğiniz yöntemin başvurusunda okuyun.

Dördüncü adım: ağ geçidi kimliğini sertifikasıyla eşleştirin

Açık bir ağ geçidi adı kullanın, örneğin vpn.example.com ve sunucu sertifikasına eşleşen bir alternatif konu adı koyun. strongSwan'ın Apple kılavuzu sunucu kimlik doğrulaması için genişletilmiş anahtar kullanımını da bekler. RSA veya ECDSA seçmek bunlardan hiçbirini değiştirmez: bir algoritma ad uyuşmazlığını, eksik EKU'yu veya tamamlanmamış zinciri onaramaz.

Güven çapasının dağıtımı, kimliği beyan etmekten ayrı bir iştir. Telefonun doğrulayabileceği bir sertifika zincirine ihtiyacı vardır ve sertifikaya gerçekten koyduğunuz adı bekleyecek şekilde yapılandırılmalıdır.

Başka bir platformun başarıyla bağlanması o platformun doğrulama kurallarına dair kanıttır, telefonunkileri gevşetme izni değildir. Farklılaşmak için belgelenmiş bir nedeniniz yoksa denetimleri istemciler arasında aynı tutun.

Beşinci adım: istemci kimliğini CA güveninden ayırın

Bir istemci sertifikası ve özel anahtarı, telefonun güvendiği CA sertifikasıyla aynı nesne değildir. Bir CA sertifikasını PKCS#12 kimliği içine paketlemek, onu desteklenen her aygıtta otomatik olarak güven çapası kurmaz; bu nedenle güven dağıtımını kendi doğrulaması olan ayrı bir adım olarak ele alın.

Tasarım bunun yerine parola tabanlı EAP kullanıyorsa telefonun amaçlanan hesap kimlik doğrulamasına ve sunucu doğrulamasına ihtiyacı vardır. Bu yol, tüm filoya tek bir paylaşılan istemci özel anahtarı göndermeyi haklı çıkarmaz; bu, çok daha kötü bir hata moduna sahip farklı bir tasarımdır.

Planı yenileme ve iptali akılda tutarak bitirin: istemci kimlik bilgisini kim yeniden yayımlar, profil nasıl güncellenir ve kayıp bir telefon nasıl kesilir. Doğruladığınız profil sürümünü ve aygıt sürümlerini kaydedin, çünkü o kayıt bir sonraki sertifika değişimini rutin bir işlem yapar.

İlgili makaleler