desteklenmeyen sertifika amacı: ara CA neden başarısız olur

Sunucu sertifikasının amacı doğru görünüyor, anahtar eşleşiyor, tarihler yerinde ve bağlantı hâlâ unsupported certificate purpose ile başarısız oluyor. Bunu çözen ayrıntı genellikle hatayla aynı satırdadır: zincirde daha yukarıdaki bir sertifikayı adlandıran bir derinlik değeri ve subject. İki farklı test çalıştırılıyor ve bunlardan yalnızca biri uç sertifikayla ilgili. Bunları karşılaştırmak, sunucu sertifikasını değiştirmenin neden hiçbir şeyi değiştirmediğini açıklar.

Doğrulayıcının gerçekte reddettiği sertifika

Zincir, üç kez yinelenen tek bir nesne değildir. Uç sertifika sunucunun adını ve anahtarını taşır, ara sertifikalar onu bir köke bağlar ve her birinin kendi geçerlilik süresi, kısıtları ve kullanımları vardır. Hata bir derinlik belirttiğinde, bu sayı doğrulayıcının oluşturduğu zincirdeki bir konumu tanımlar ve sunucu beklenmedik bir zincir gönderiyorsa bu, beklediğiniz konum olmayabilir.

O derinlikteki sertifikanın alanlarını okuyun, suçlu sandığınız sertifikanınkini değil. Her alanı dökmek yerine verilmesini kısıtlayan iki uzantıyı isteyin, çünkü cevap neredeyse her zaman bunlardan birindedir. Uzantı çıktısını paylaşmak güvenlidir; özel anahtarları asla.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Adlandırılan sertifika, genişletilmiş anahtar kullanımı TLS sunucu kimlik doğrulamasıyla ilgisiz bir şey belirten bir ara sertifika ise, hatanın geri kalanı mekanik olarak gelir. Zincir, OpenVPN tarafından istenen amaç için kullanılamaz.

Uç sertifikanın amacı ve zincir politikası iki testtir

Uç testi dar bir soru sorar: bu son varlık sertifikası bu ad için sunucu kimlik doğrulamasına izin veriyor mu? Zincir testi daha geniş bir soru sorar: yoldaki her sertifika o amaca hizmet edebilir mi? Yalnızca istemci sertifikaları vermeye yetkili bir sertifika otoritesi kendi imza kontrollerini geçer ve yine de ikinci testte başarısız olur, çünkü yetkilendirdiği yol, uygulamanın ihtiyaç duyduğu amacı içermez. İki test aynı sözcüklerle başarısız olur ve tamamen farklı onarımları vardır.

Bu yüzden yeni verilmiş, görünen her alanı doğru bir uç sertifika hemen başarısız olabilir. Bu yüzden düzeltme genellikle VPN yapılandırmasına değil, veren otoritenin profiline aittir.

Olmayan EKU kısıtlayıcı EKU değildir

RFC 5280, genişletilmiş anahtar kullanımı uzantısını isteğe bağlı yapar ve mevcut olduğunda kısıtlayıcı kılar. Bu nedenle uzantısı olmayan bir CA sertifikası sunucu kimlik doğrulamasına «hayır» dememiştir, yalnızca ilgisiz bir amaç listeleyen bir sertifika ise çok belirgin bir şey söylemiştir. Bu iki durumu eşdeğer saymak yanlış tanıya ve daha kötüsü yanlış onarıma yol açar. Fark, konsolda benzer görünen iki otoritenin zincirde neden tamamen farklı davrandığını da açıklar.

Kitaplıkların davranışı burada da tekdüze değildir. OpenSSL'in doğrulama seçenekleri belgesi, CA sertifikalarındaki amaç kontrollerine kendi yaklaşımını açıklar ve bu yaklaşım bir uygulama politikasıdır, her TLS yığınının aynı şekilde izlediği bir kural değildir. Doğrulayıcınızın ne yaptığını açıklayın, sonra bunu gerçekten çalıştırdığınız sürümle doğrulayın.

Yeniden vermeden önce hatayı çevrimdışı yeniden üretin

Çevrimdışı doğrulama uygulamayı denklemden çıkarır. Zincir aynı amaç altında aynı şekilde başarısız olursa sorun sertifikadır ve hiçbir sunucu yapılandırması bunu gizleyemez. Zincir çevrimdışı geçerken hizmet hâlâ reddediyorsa, uygulama başka bir amaç istiyor ya da test ettiğinizden farklı bir zincir kullanıyordur.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain önemlidir çünkü aracın oluşturduğu yolu yazdırır ve bu genellikle verdiğiniz dosya sırası değildir. Bu çıktı, ikinci bir ara sertifikanın bir güven deposundan çekildiğini, sunucunun amaçlamadığınız çapraz imzalı bir varyant gönderdiğini veya bir eğitimden kopyaladığınız amaç bayrağının hizmet verilen rolden farklı bir role ait olduğunu keşfetmenin en hızlı yoludur.

Verme politikasını düzeltin, doğrulama çağrısını değil

Kalıcı onarım, hizmet etmesi gereken amaçlara izin veren bir politika altında verilmiş bir ara sertifikadır ve kısıt yazılıp gözden geçirilmiştir. Her otoriteye her amacı eklemek politika değildir; uzantıya anlam veren kısıtı ortadan kaldırır ve genellikle onu tetikleyen olaydan daha uzun yaşar. Profilde otoritenin hangi rolleri sertifikalandırabileceğini açıklayan kısa bir not, bir sonraki yeniden vermenin aynı tartışmayı yinelemesini önler.

Doğrulamayı kapatmak diğer cazip kısa yoldur ve bir sertifika sorununu güven sorununa dönüştürür. Amaç denetimini yerinde tutun, zinciri düzeltin ve yolun artık amaçlanan role hizmet ettiğini doğrulamak için aynı çevrimdışı doğrulamayı yeniden çalıştırın, sonra hizmete tekrar dokunun.