Bir VPN sertifika yetkilisini değiştirdiğinizde ne olur

Bir VPN sertifika yetkilisini değiştirmek dosya değiştirmek değildir. Yeni CA ilk sertifikasını imzaladığı anda, hâlâ yalnızca eskisine güvenen her doğrulayıcı bir karar vermek zorundadır ve yeni çapayı hiç almayan makineler iyi eşleri reddetmeye devam eder. Bunun iki yönde de bozulduğunu gördüm: ağ geçidi yeni CA'yı öğrendi, istemciler öğrenmedi, bu yüzden yeni bağlantılar başarısız oldu; oysa zaten ayakta olan tüneller kaldı ve kesintiyi yönlendirme sorunu gibi gösterdi. Neyin değiştiğini, hataların ortaya çıkış sırasıyla anlatıyorum.

Tek değişim, iki ayrı değişiklik

Bir sertifika yetkilisi bir ad, bir açık anahtar ve imzalayan özel anahtardır. Doğrulayıcılar soyut olarak «CA»ya asla güvenmez. Güven deposunda zaten duran belirli bir sertifikaya güvenirler ve ancak imza zinciri o saklanan kopyaya ulaşırsa vericiyi kabul ederler. Bu yüzden CA değişimi birbirinden bağımsız olarak başarısız olan iki şeyi değiştirir: hangi çapaların kabul edildiği ve bunların altında hangi eş kimliklerinin verildiği.

Çoğu VPN kurulumu iki yönde de doğrular. İstemci ağ geçidinin sertifikasını, ağ geçidi de istemcinin sertifikasını doğrular. Yalnızca istemci paketini yenileyen bir geçiş, sunucuyu hâlâ eski CA kimliğini sunan her istemciyi reddetmeye bırakır ve tersi de aynı ölçüde yaygındır. Önce uygulama noktalarını listeleyin: istemci güven depoları, ağ geçidinin ca dosyası, önünde TLS'i sonlandıran herhangi bir vekil sunucu ve uç noktayı dışarıdan denetleyen sonda.

Doğrulayıcı neyi kontrol eder, sırasıyla

Yol doğrulaması eş sertifikasından ara sertifikalar üzerinden güvenilir bir çapaya ulaşana kadar tırmanır. Her adımda imzayı doğrular, her sertifikanın geçerlilik penceresi içinde olduğunu denetler ve temel kısıtlar ile anahtar kullanımının vericinin imzalamasına izin verdiğini onaylar. Ancak ondan sonra uygulama yaprak sertifikaya bakar: özne alternatif adları çevrilen adı kapsamalı ve genişletilmiş anahtar kullanımı sunucu veya istemci kimlik doğrulamasına izin vermelidir.

Bu yürüyüşü çevrimdışı yinelemek için -CAfile değişkenini dağıtacağınız tam pakete yönlendirin, sistem deposuna değil. Aksi halde değişikliği değil, makineyi test edersiniz:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Bu komut yalnızca ağ geçidinin HTTPS yönetim sayfası gibi düz bir TLS dinleyicisine karşı çalışır; OpenVPN'in denetim kanalı TLS'ten önce gelir, bu yüzden s_client tünelin el sıkışmasını inceleyemez.

Bu hataların arkasındaki yol oluşturma kuralları RFC 5280 bölüm 6 içinde. Aksi halde keyfi görünen başarısızlıkları açıklarlar: kimsenin hatırlamadığı süresi geçmiş bir ara sertifika, anahtar kullanımı imzalamayı yasaklayan bir sertifika veya test ettiğiniz makineyi dışlayan bir ad kısıtı.

Eski tünel neden çalışmaya devam eder

TLS ve OpenVPN ikisi de el sıkışması bittikten sonra kurulmuş oturumu canlı tutar. Hiçbir şey eş sertifikasını paket başına yeniden doğrulamaz, bu yüzden değişiklikten önce bağlanan istemci yeniden müzakere edene, yeniden bağlanana veya tünel düşene kadar trafiği geçirmeye devam eder. Tam bu boşluk, bir CA değişiminin saatlerce iyi görünüp sonra en kötü anda başarısız olmasının nedenidir: dizüstü bilgisayar uykudan uyanır, NAT eşlemesi zaman aşımına uğrar, ağ geçidi yeniden başlar.

Oturum devamı bu yanılsamayı daha da uzatır. Bir TLS oturum bileti istemcinin sertifikaları yeniden göndermeden dönmesine izin verir ve devam, yol doğrulamasını atlar çünkü ilk el sıkışması bunu zaten yapmıştır. Dolayısıyla dürüst test yeni bir süreçte tam el sıkışmadır. Tüneli yeniden bağlamak yerine istemciyi yeniden başlatın ve bir test profilinde biletleri devre dışı bırakmayı düşünün, böylece devam yolu kopuk bir zinciri gizleyemez.

Statik anahtar katmanını bundan ayrı tutun. tls-auth denetim kanalına HMAC ekler, tls-crypt onu şifreler ve doğrular ve ikisi de sertifika malzemesi taşımaz, bu yüzden herhangi birinin döndürülmesi kendi arıza modu olan ayrı bir değişikliktir. İkisini karıştıran kurulumlar, statik anahtarı sağlam, sertifikası eskimiş ve hata mesajı ikisinden de söz etmeyen bir istemciyle sonuçlanır.

Özne adını yeniden kullanma tuzağı

Hiçbir şeyin alt akışta değişmemesi için selefin ayırt edici adını yeniden kullanmak cezbedicidir. Bu, arayüzde verici satırını sabit tutar ve ihtiyaç duyduğunuz tek sinyali yok eder. Aynı öznelere ve farklı anahtarlara sahip iki sertifika ada göre ayırt edilemez, bu yüzden iki çapayı da taşıyan bir paket doğrulayıcıya iki aday verir ve seçim için hiçbir kural bırakmaz.

Yol oluşturma o zaman yanlış olanı seçebilir, doğru çapa yerindeyken «yerel verici sertifikası alınamıyor» diye bildirebilir veya aday sırası farklı olduğu için aynı pakete sahip başka bir makinede başarılı olup burada başarısız olabilir. Ad yeniden kullanılmak zorundaysa geçiş sırasında iki çapayı ayrı dosyalarda tutun ve açıkça yükleyin, ancak her eş yeni vericiyi sunduğunda birleştirin. Aksi halde yerine ayrı bir ortak ad verin — bir nesil veya tarih soneki yeterlidir — böylece günlükler ve hata metinleri başarısız eşin hangi otorite altında verildiğini söylesin.

Ağı devirmeyen bir geçiş

Planlı bir değişim için tek adımda geçmek yerine sınırlı bir süre iki çapayı da kabul edin. Yeni CA'yı ve ara sertifikalarını verin, yeni çapayı her doğrulayıcının paketine eskinin yanına koyun ve ancak ondan sonra ondan eş sertifikası vermeye başlayın. Eski kimlikli eşler eski çapaya göre doğrulanır; yeniler yeni çapaya göre çalışır.

Bu sırayla yapıldığında her adım geri alınabilir. Kaçındığınız arıza eşzamanlı geçiştir: paket güncellemesini kaçıran istemci, eski çapayı çoktan emekliye ayırmış bir ağ geçidiyle karşılaşır, el sıkışması ölür ve hiçbir günlük hangi tarafın eskimiş olduğunu söylemez.

Ters yönde emekliye ayırın. Hayatta kalması gereken her kimliği yeniden verin, her birinin yeni zinciri sunduğunu doğrulayın, sonra eski çapayı paketlerden çıkarın. Eski CA'nın özel anahtarını hizmetten çıkarın, çünkü hâlâ imzalayabilen bir verici geçişin bitmediği anlamına gelir. Sertifikaları ve verme kayıtlarını denetim için saklayın. Kayıp bir verici aynı güvene geri getirilir; bir ifşa yeni kimlikler gerektirir ve eski çapaya dönüş yoktur.

Sonucu doğrulayın, dosya listesini değil

Beklenen dizindeki bir güven dosyası çok az şey kanıtlar. Uygulama başka bir yol, başka bir biçim veya bir yükseltmenin değiştirdiği paketin içindeki bir kopyayı okuyabilir. Davranışı iki uçta denetleyin, dosyanın varlığını değil.

Yeni kimlikle yeni bir bağlantının başarılı olduğunu doğrulayın, ardından emekliye ayrılan CA tarafından verilen bir kimliğin reddedildiğini doğrulayın. İnsanların atladığı o ikinci testtir ve eski otoritenin artık erişim vermediğini gösteren tek şeydir. Kurulum CRL veya OCSP'ye dayanıyorsa yeni sertifikalardaki dağıtım noktalarının çözüldüğünü ve sorgulayan eşlerin yanıtlayıcıya ulaştığını denetleyin.

Hiç bağlanmamış bir istemciyle bitirin: profil durumunu silin, bağlanın ve müzakere edilen zinciri okuyun. Önbelleğe alınmış bir oturumu sürdüren eş, hiçbir şeyi doğrulamadığı halde geçişin işe yaradığını neşeyle bildirir.