OCSP'ye karşı CRL: her iptal denetimi gerçekte nasıl çalışır

Bu iki iptal denetiminden biri tek bir sertifika hakkında imzalı bir yanıt döndürür, diğeri ise tamamını indirdiğiniz imzalı bir liste döndürür. İkisi de bir doğrulayıcıya kimlik bilgisinin hâlâ güvenilir olup olmadığını söylemek içindir ve ikisi de birbirine hiç benzemeyen biçimlerde başarısız olur. Aşağıdaki sıra, bir operatörün üretimde gerçekte karşılaştığı şeyi izler: kablodaki baytlardan başlayıp bağlantıyı reddeden bir ağ geçidiyle biter. Bir adımı atlamak, bir kurulumun yalnızca kâğıt üzerinde var olan bir iptal politikasıyla sonuçlanmasının yoludur.

Adım 1: Her denetim ne döndürür ve ne kadar süre kullanılabilir kalır

Bir CRL, bir vericinin iptal ettiği her sertifikayı kapsayan tek bir imzalı nesne olarak yayımlanır, bu yüzden doğrulayıcı onu bir kez alır ve listenin nextUpdate değeri geçene kadar yeniden kullanır. Bir OCSP yanıtı daha dardır: tam olarak tek bir sertifika için yanıt verir ve thisUpdate, producedAt ile genellikle nextUpdate de taşır. Her şeyi bu fark yönetir. Önbelleğe alınmış bir CRL sessizce eskir, çünkü dosya hâlâ ayrıştırılır ve imzası hâlâ doğrulanır; oysa süresi geçmiş bir OCSP yanıtı, zaman damgalarını okuduğunuz anda açıkça değersizdir.

Bu yüzden önbellekleme ilk belirlenmesi gereken şeydir: hangi bileşen kopyayı tutar ve o kopya hangi üst sınıra uyar. Bir ağ geçidinde üst sınır nextUpdate eksi güvenlik payı olmalıdır, asla bir HTTP önbellek başlığının tesadüfen önerdiği şey değil. openssl crl -in issuer.crl -noout -lastupdate -nextupdate iki tarihi de yazdırır, ve nextUpdate değeri zaten geçmişte olan bir liste yalnızca eski değil, eksik olarak ele alınmalıdır.

Adım 2: Sertifika istemciyi nereye yönlendirir

Uç sertifika genellikle iki ipucu taşır: bir CRL dağıtım noktası uzantısı ve OCSP için bir yetkili bilgi erişim kaydı. openssl x509 -in client.pem -noout -ext crlDistributionPoints birincisini yazdırır, ikincisi openssl x509 -in client.pem -noout -text çıktısının AIA bölümü altındadır. Her iki uzantı da bir işaretçidir, yükümlülük değildir. İptal denetimini hiç uygulamayan bir istemci, uzantıları bir yıldır ölü olan bir yanıtlayıcıyı adlandıran bir sertifikaya sorunsuz bağlanır.

Dağıtım noktaları sıklıkla yalnızca tek bir ağ segmentinde çözülen dahili bir ana bilgisayarı adlandırır ve bazı eski istemciler ldap URL'lerini tümüyle reddeder. Erişilebilirliği tüneli sonlandıran ana bilgisayardan test edin, kendi dizüstü bilgisayarınızdan değil, çünkü gerçekten önem taşıyan tek bakış açısı odur.

Adım 3: Kesintiden önce fail-closed ya da fail-open seçin

Erişilemeyen bir yanıtlayıcı veya süresi geçmiş bir liste bir karar dayatır: bağlantıyı reddet ya da kabul et ve boşluğu kaydet. OpenSSL'in verify alt komutu katı seçimi açık kılar, çünkü -crl_check eklemek kullanılamayan bir CRL'yi unable to get certificate CRL ve başarısız bir doğrulamaya dönüştürür. Çoğu yığında yumuşak hata bir bayrak bile değildir, denetimin yokluğudur ve tam bu yüzden kazara sevk edilir.

Bir istemcinin gerçekte hangi davranışa sahip olduğunu görmek için yanıtlayıcıyı kaldırın ve yeniden bağlanın. Tünel yine de açılıyorsa, atlanan denetimi kaydeden günlük satırını bulun ve bir olay sırasında birinin o satırı okuyup okumayacağını sorun. Aynı üretici protokole göre farklılaşabilir: aynı makinedeki bir IKEv2 istemcisi ve bir OpenVPN istemcisi ilgisiz yapılandırma ayarlarını okur.

Adım 4: Denetimin trafiğin kabul edildiği yerde çalıştığını kanıtlayın

Bağlantıyı sonlandıran veya yetkilendiren süreci bulun ve ona iptal denetimini etkinleştiren yapılandırma satırını sorun. Zinciri doğrulayan ama iptal hakkında hiç sormayan bir ağ geçidi, belgelerinizdeki politikadan farklı bir politika uygular ve hiçbir sertifika zinciri ekran görüntüsü bunun tersini kanıtlamaz. OpenVPN seçeneği crl-verify olarak yazar; strongSwan CRL ve OCSP aramalarını CA yapılandırması altında tutar, burada crl_uris veya ocsp_uris ayarlanır. İkisinden birini gösteremiyorsanız denetimin olmadığını varsayın.

Bir OCSP yanıtı yalnızca veren CA imzaladığında veya o CA'nın devrettiği OCSPSigning genişletilmiş anahtar kullanımına sahip bir yanıtlayıcı imzaladığında geçerlidir, bu yüzden ilgisiz bir hizmetten gelen yanıt hiçbir şeyi kanıtlamaz. Yanıtlayıcıyı kendiniz işletiyorsanız onu katı bir bağımlılık olarak izleyin, çünkü tek bir ölü hizmet aynı anda her fail-closed istemci için kesintiye dönüşür.

Adım 5: Bir sertifikayı kasten iptal edin

Bir test sertifikası alın, üretimin kullandığı kanaldan iptal edin ve yanıtlayıcıya doğrudan sorun. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text iptal zamanıyla birlikte Cert Status: revoked bildirmelidir ve good yanıtı iptalinizin istemcilerinizin sorduğu yanıtlayıcıya ulaşmadığı anlamına gelir. Ardından liste yolundan aynı kararı görmek için openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem çalıştırın. Çıkış kodu yerine neden dizgesini okuyun, çünkü iptal reddi ve zincir hatası ikisi de başarısızlıkla biter.

Gerçekten önemli olan adım sonuncusudur: eski profille gerçek uygulama noktasına karşı yeniden bağlanın ve reddin iptalden geldiğini doğrulayın. Ardından yalnızca dinleyiciyi bozmadığınızı kanıtlamak için yeni ve geçerli bir sertifikayla yeniden bağlanın. İstemcideki profili silmek sunucunun kararı hakkında hiçbir şey kanıtlamaz; hiçbir zaman bir tüneli sonlandırmayan bir makinede openssl verify çalıştırmasının başarılı olması da. RFC 6960 uyumlu bir OCSP yanıtının ne içerdiğini tanımlar, bu testin okuduğu durum değerleri de dahil.