Bu soru orijinal versiyonundan bu yana önemli ölçüde revize edildi ve netleştirildi.
Güvenilir Kök mağazamdaki her güvenilir sertifikaya bakarsak, onlara ne kadar güvenmeliyim?
Yerel mağazamdan potansiyel olarak kaldırılması için her bir Kök CA'nın güvenini değerlendirdiğimde hangi faktörler dikkate alınmalıdır?
Daha Fazla Bilgi:
Bir CA, doğrulanmamış bir tarafa sertifika verirse, bu CA'ya güvenen tüm makinelerin MITM saldırılarına karşı savunmasız kalmasına neden olur. Sonuç olarak tüm CA'lar, CS zincirlerinin bütünlüğünü sağlamak için belirli bir SSL sertifikası isteğinin istemcisini sıkı bir şekilde doğrular.
Bununla birlikte, bu CA doğrulama sürecinin büyük bir kısmı insan müdahalesine tabidir ve yanlış tarafa bir sertifika verme fırsatları sunar. Bu, CA operatörü hatası, hükümet talepleri veya bir CA operatörünün zorlaması (rüşvet) ile yapılabilir.
Hangi varsayılan CA'ların yanlış tarafa sertifika verme olasılığının daha fazla olduğu hakkında daha fazla bilgi edinmek istiyorum. Bu bilgileri, kullanıcılara bu CA'yı Güvenilir Sertifika Deposundan kaldırmalarını önermek için kullanmayı planlıyorum
Örnekler:
Belirli bir CA'yı kontrol eden hükümetin Microsoft.com'un kimliğini devralmak istediğini ve CA'nın doğrulama sürecine bir istisna talep ettiğini varsayalım. Bu hükümet daha sonra bu istisnanın gizliliğinin korunmasını da gerektirir. Oluşturulan anahtar çifti daha sonra bir MITM saldırısında kullanılacaktır.
Windows Azure Varsayılan Güven
Windows Azure, aşağıdaki bağlantı bölümünde gösterildiği gibi 275 CA'yı destekler. Belirli CA'nın kullanımına bağlı olarak, bu CA'ların bazıları belirli bir saldırının yüzey alanını artırabilir. Aslında, bazı uygulamaların düzgün çalışması için bu teknik olarak gerekli olabilir.
Amazon Varsayılan Güven
(mevcut değil) Karşılaşırsanız lütfen Amazon, Google ve VMWare'in varsayılan CA listesine bağlantıları paylaşın.
Mozilla
A tüm sertifikaların ve denetim beyanlarının listesi kullanılabilir.
Apple iOS
Güncelleme 5 CA modeliyle ilgili temel sorun (heh), genel uygulamada, herhangi bir CA'nın herhangi bir alan için sertifika verebilmesidir, bu nedenle savunmasızsınız en zayıf halka. Kimin güvenebileceğine gelince, listenin çok uzun olduğundan şüpheliyim, çünkü riskler yüksek ve güvenlik zor. Christopher Soghoian'ın konuyla ilgili, dünyadaki hükümetlerin özel kullanıcı verilerine erişmek için kullandıkları çeşitli yaklaşımları açıklığa kavuşturmasını öneriyorum - ister bulut hizmetlerini işleten şirketlerden doğrudan ister teltap aracılığıyla veya giderek CA zorlama yoluyla giderek daha fazla veya hackler: hafif paranoya: DigiNotar hackine yol açan kuvvetler .
Burada bazı özellikler sağlarım ve bazı potansiyel düzeltmelere bağlantılar ile bitiyorum.
2009'da Etisalat (% 60'ı Birleşik Arap Emirlikleri hükümetine aittir), RIM cihazlarına casus yazılım yerleştiren, e-postanın izlenmesini sağlayan zararsız görünümlü bir BlackBerry yaması yayınladı, bu yüzden güvenilir olarak kabul edilemez. Ancak birçok güvenilir CA listesindedir: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars
Güncelleme 1 Ayrıca Comodo'ya karşı ComodoHacker adlı bir İranlı tarafından iddia edilen başarılı bir saldırı örneğine bakın: Sahte SSL sertifikaları ("case comodogate") - F-Secure Weblog . F-Secure, Mozilla'nın Çin, İsrail, Bermuda, Güney Afrika, Estonya, Romanya, Slovakya, İspanya, Norveç, Kolombiya, Fransa, Tayvan, İngiltere, Hollanda, Türkiye, ABD, Hong Kong, Japonya'daki CA'lar tarafından verilen sertifikaları içerdiğini belirtti. , Macaristan, Almanya ve İsviçre.
Tunus, yaygın olarak güvenilen bir CA'yı çalıştıran başka bir ülkedir ve hükümetlerinin gizliliği istila etme eylemlerinin iyi belgeleri de vardır: Facebook'un Tunus Hack'lerine Nasıl Yanıt Verdiği İç Hikayesi - Alexis Madrigal - Teknoloji - Atlantik
Mozilla, dikkat edilmesi gereken başka bir şüpheli uygulamaya dikkat çekiyor: Bir RA iş ortağının bir aracı yerine doğrudan kökten sertifika vermesine izin veren CA'lar: Comodo Sertifika Sorunu - Mozilla Güvenlik Blogunda Takip .
Yalnız İranlı bir hacker'ın sorumluluk iddiası hakkındaki spekülasyonlar da dahil olmak üzere daha fazla ayrıntıya bakın Web Tarayıcıları ve Comodo, Belki İran'dan Başarılı Bir Sertifika Yetkilisi Saldırısı Açıklıyor | Belki İran'dan Tinker'e Özgürlük
Güncelleme 3 : ComodoHacker tarafından da görünüşte başarılı olan bir başka saldırı da DigiNotar CA'ya karşıydı. Web sitelerinin 2009'dan itibaren güvenliği ihlal edildi, ancak bu DigiNotar'ın 2011 yılında İranlılar tarafından Google, Yahoo !, Mozilla, WordPress ve Tor Projesi: DigiNotar, bir aydan fazla bir süre boyunca siteye izinsiz giriş bilgisini açıklamamıştır Daha fazla bilgi için DigiNotar Hack SSL Web Güvenlik Modelimizin Kritik Başarısızlıklarını Vurgulamaktadır | Tinker Özgürlüğü .
Sanırım, çeşitli CA'ların güvenlik açığı, faydaları gibi oldukça geniş çapta değişir. Bu yüzden stratejinizi yeniden odaklamayı öneririm. Korumak istediğiniz belirli varlıklarla daraltabiliyorsanız, bu varlıkları kullanmak için gerekli olanlar dışındaki tüm CA'ları silin. Aksi takdirde, yalnızca saldırı yüzeyini azaltmak için varlıklarınızı önemseyen veya en az popüler olanlara en savunmasız olduğunu düşündüğünüz CA'ları kaldırmayı düşünün. Ancak, en popüler ve dikkatli CA'lara karşı bile gelişmiş saldırılara karşı savunmasız kalacağınızı kabul edin.
Güncelleme 2 : Tehlikeli CA altyapımızı Tinker Özgürlüğünde düzeltmek için harika bir gönderi var: Daha iyi bir CA altyapısı oluşturmak
Bu yeniliklerden bahsediyor:
Güncelleme 4 Ağustos 2011'deki BT Güvenliği blog yayınlarımızdan biri de DNSSEC'ye geçme konusunu da kapsıyor: Düzeltmeye Risk Tabanlı Bakış Yetkilisi Sorunu Oluşturma "Stack Exchange Security Blog
Güncelleme 6 Birkaç Sertifika Yetkilisi kuralları ihlal ettiği için yakalandı. Buna Fransız siber savunma ajansı (ANSSI) ve Trustwave de dahil, her biri dijital sertifikaların sahteciliği ile bağlantılı .
Güncelleme 7 2014'te Hindistan Sertifika Yetkilileri Kontrolörü (Hindistan CCA) aracılığıyla bir başka "yanlış sertifika" kümesi: Google Çevrimiçi Güvenlik Blog: Dijital sertifika güvenliğini sağlama
Ayrıca, daha önce kötü sertifikaları ve politika ihlallerini keşfetmede yardımcı bir yaklaşım gibi görünen Sertifika Şeffaflığı konusundaki soruya bakın.
Matt Blaze'nin bir zamanlar yazdığı gibi, CA'lar sizi para almak istemeyen herkesten korur. Bu size CA'nın teşviklerinin nerede yattığı ve düzenlemedeki bazı potansiyel riskler hakkında bir şey söylemelidir.
Korkarım ki bu sorunun kısa cevabı görebildiğim kadarıyla bilmek imkansız. Çoğu yaygın tarayıcıda yüklü olan çok sayıda varsayılan CA vardır ve bunların devlet kurumlarına veya diğer kuruluşlara sertifika verme açısından "güvenilir" olmalarının ne kadar olası olduğunu değerlendirmek zordur.
Bir CA güvenilmez olarak bilinirse, muhtemelen tarayıcıların varsayılan yükleme listelerinden kaldırılacaktı (aşağıdaki @xce başına, Diginotar burada iyi bir örnektir ve Digicert)
Gönüllü olarak sertifika veren kuruluşa ek olarak, istekte bulunan üzerinde uygun güvenlik kontrolleri yapmadan sertifika sağlama riski vardır. Defcon'da birkaç yıl önce bu konuyla ilgili izinsiz sertifika alabilmek için çeşitli sunumlar yapıldı.
Bu önemli bir endişe ise, düşünebilmemin tek yolu, gözden geçirdiğiniz ve sağlanan güvenlikten memnun olduğunuz CA'ların beyaz bir listesini oluşturmak olacaktır. Açıkçası bu, genel İnternet'e erişmek için işe yaramayacaktır, çünkü muhtemelen sorunları olan CA'ları kaldırmak istiyorsunuz.
Bilmeniz gerekenin kalbine giden, ancak açıkça sorduğunuz şeyin değil 2 örnek:
Daha sonra elbette, CA'nın kullanılmadığı bile yazılım senaryoları vardır - ör. sunucunun sertifikasını doğrulama zahmetine girmeyen Web Hizmetleri'ni çağıran kalın istemcilerle ....
Demek istediğim, SSL üzerinden MITM hakkında endişeleniyorsanız, daha sık olmamakla birlikte, sizi endişelendirmesi gereken hükümet zorlaması değildir. Genellikle daha kolay ve daha erişilebilir yollar vardır.
Hatta "Güvenilir Sertifikalar" olarak "Güvenilir" olarak adlandırılmaya itiraz ediyorum ... Sadece kim olduğunu bildiğim için sana güvenmem gerektiği anlamına gelmez ... ve bu birisinin kim olduğunu bildiğine güvenmem gerektiği anlamına gelmez başka.
Standart kök sertifikaları güvenilir mağazadan kaldırırsanız, İnternet'teki birçok sitenin beklendiği gibi çalışmadığını unutmayın.
Öte yandan, genel tarama özelliklerine ihtiyaç duymayan, ancak belirli bir sunucuyla (veya sunucular kümesi), [~ # ~] tüm [~ # ~] kök certs'i mutlaka kaldırın (ihtiyacınız olanların bir beyaz listesi hariç).
Ve kendi dahili CA'nızla giderseniz, daha da iyisi ....
Her CA, kendi anahtarlarını nasıl koruduklarını açıklayan ve sertifikaları vermeden önce isteklerini doğrulayan bir Sertifika Uygulama Bildirimi yayınlar. Bu belgenin konumuna ilişkin bir URL genellikle CA tarafından verilen her sertifikaya yerleştirilir. Söz konusu CA'nın aslında bu politika belgesini takip ettiği varsayılarak, sertifika isteyen kuruluşun geçerliliğini belirlemek için gittikleri uzunlukların bir göstergesi olmalıdır. İmzalama anahtarlarını korumak için Donanım Güvenlik Modülleri veya Şifreleme Modülleri kullanarak CA imzalama anahtarlarını koruduklarına dair etki ifadeleri arayın, sertifikaları imzalamak için çok faktörlü kimlik doğrulama ve çekirdek tabanlı yetkilendirme vb. Bu koruma yöntemleri çok daha zor ve pahalı hale getirir. sahte bir üçüncü tarafın imza anahtarlarını çalması için.
HTTPS sistemini siz ve gezegende bu soruları sormayan herkes için kullanılabilir hale getirmek için güvenilir CA'ların büyük listesi (Mac Sistem Kökler Anahtarlık 175'e sahiptir) size kolaylık sağlamak için orada. Elbette, uygulamalarını kişisel olarak denetlemediyseniz, her CA'yı bu listeden çıkarabilirsiniz. Tüm uç noktaları kontrol ettiğiniz ve sınırlı sayıda güvenilir tarafınız olduğu kapalı bir sistem için bu yapılabilir. Subversion sürüm kontrol sistemi güvenilir Kök sertifikaları içermez, ancak her istemciye kendinizinkini ekleyebilirsiniz. Genel olarak web için, kullanılabilir hale getirmenin tek yolu bant dışı güvenilir bir partiye (işletim sisteminizi veya tarayıcınızı sağlayan şirket, ne düşünürseniz düşünün) güvenilir bir liste sunmaktır. dünyadaki hemen hemen tüm SSL özellikli sunuculara bağlanmanızı sağlayan sertifikalar.
Güvenilir listenizdeki tüm sertifikalara gerçekten ihtiyacınız var mı? Muhtemelen değil. Ancak işletim sistemi/tarayıcı satıcınız kiminle iş yapmak istediğinizi tahmin edemez (ve kontrol etmemelidir), bu yüzden hepsini içerir. Büyük listeyle ilgili sorun, tüm yetki alanlarından, her türlü doğrulama yöntemine sahip, tümüyle aynı muamele gören tüm tüylerin CA'larına sahip olmanızdır. Her CA aynı davranmaz: güvenliği ihlal edilmiş bayi giriş kimlik bilgileri ve hatta güvenliği ihlal edilmiş CA anahtarları gördük. Bazı CA'lar için bir kuruluş sertifikası ve ilk doğan bebeğinizin vaatleri gerekirken, diğerleri sadece sertifika istediğiniz etki alanında e-posta alabileceğinizi doğrular. Yine de her CA, tarayıcınız tarafından tamamen aynı şekilde ele alınır.
Aynı Ortak Ad için hileli sertifikalara karşı bir savunma hattı, orijinal sertifikayı istemcide önbelleğe almak olacaktır: farklı bir CA'dan farklı bir sertifika aniden ortaya çıkarsa, bu endişe sebebi olmalıdır. Bugünün tarayıcılarının bu davayı nasıl ele aldığını bilmiyorum ve öğrenmek için çok tembelim.
Bu tür tartışmalar her zaman bana bu Mozilla hatası yeni bir CA'nın dahil edilmesini ister. Oldukça komik, ama oldukça anlayışlı.
Bir Windows PC'de hangi sertifikanın kaldırılacağını araştırırken, öncelikle sistem için gerekli sertifikaları kaldırmamaya dikkat edin. Bunu yapmaya çalışırsanız aşağıdaki hata iletisini alırsınız
Bu, hiçbir zaman bir Windows sisteminden silinmemesi gereken sertifika listesinin bulunduğu URL'dir http://support.Microsoft.com/?id=293781
Daha sonra ara sertifikaları kaldırmayı (kaldırılmasını test etmeyi) düşünmelisiniz, çünkü bunlar yalnızca " yalnızca eski nedenlerden dolayı ".
Kalan tüm sertifikaların kaldırılmasını değerlendirirken, Microsoft Kök Sertifika Programı , CA'nın aşağıdaki denetim standartlarından birini geçmesini gerektirdiğini düşünün:
Certs'i MSFT olmayan bir tarayıcıdan (IE) kaldırıyorsanız bu CA kalite yönergelerini inceleyin .
Kısıtlamalar
Program ayrıca Anahtar Kullanımı için geçerli olan ek denetimlere sahiptir. Anahtar kullanımı aşağıdakilerle sınırlıdır:
Sunucu Kimlik Doğrulaması (SSL) = 184.108.40.206.220.127.116.11.1
İstemci Kimlik Doğrulaması (SSL) = 18.104.22.168.22.214.171.124.2
Güvenli E-posta (SMIME) EKU = 126.96.36.199.188.8.131.52.4
Kod İmzalama EKU = 184.108.40.206.220.127.116.11.3
Zaman damgası EKU = 18.104.22.168.22.214.171.124.8
OCSP EKU = 126.96.36.199.188.8.131.52.9
Şifreleme Dosya Sistemi EKU = 184.108.40.206.4.1.3220.127.116.11
IPSec (Tünel, Kullanıcı) EKU = 18.104.22.168.22.214.171.124.6, 126.96.36.199.188.8.131.52.7
Yasaklanan Anahtar Kullanımları
Aşağıdaki Anahtar kullanımları program tarafından yasaklanmıştır:
Akıllı kartla oturum açma Active Directory dağıtımı gerektiğinden ve kökün Active Directory'deki NTAuth deposuna eklenmesi gerektiğinden, bu yalnızca kurumsal bir senaryodur. Ayrıntılar için aşağıdaki KB makalesine bakın. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245
Dijital haklar Bu EKU kullanılmıyor. Windows Media DRM lisanslar için kendi XML biçimini kullanır ve X.509 kullanmaz.
Nitelikli sertifikalandırma Bu EKU kullanılmıyor ve Windows tarafından yok sayılıyor.
Anahtar kurtarma Enterprise CA senaryosu.
Dosya kurtarma Bu EKU kullanılmıyor ve Windows Şifreleme Dosya Sistemi (EFS) tarafından yok sayılıyor.
Tüm uygulama politikaları “Tüm kullanımları” veremeyiz, çünkü bu yalnızca kurumsal ve diğer kabul edilemez EKU'ları kabul eder.
Dizin hizmeti e-posta çoğaltması Kurumsal senaryo
Sertifika talep aracısı
Kurumsal CA senaryosu
Anahtar kurtarma aracısı Kurumsal CA senaryosu
CA şifreleme sertifikası
Kurumsal CA senaryosu
Kabul Kriterleri
Ayrıca, köke genel bir amaç veya Hükümet CA'sı eklenmeden önce aşağıdaki ölçütlerin karşılanması gerekir:
CA, aşağıda istenen bilgileri sağlamalıdır (bkz. Adım 1. Microsoft'a Başvurun ) ve Programa üyelik için ön onay almalıdır.
CA, test amacıyla CA'nın kök sertifikasından verilen bir test sertifikası sağlamalıdır. İsteğe bağlı olarak, bir CA, Microsoft'a kök sertifikalarından verilen sertifikaların doğrulanabileceği, genel olarak erişilebilir bir sunucunun URL'sini sağlayabilir. (Ayrıntılar için bkz. FAQ)
CA'nın bir Microsoft CA Anlaşması tamamlaması gerekir. Anlaşma ancak başvuru sürecinin 1. Adımı tamamlandıktan ve başvurunuzun ön onayını aldıktan sonra verilecektir.
Kök sertifikalar aşağıdaki Teknik Gereksinimler bölümüne uygun olmalıdır. Özellikle, herhangi bir kök ve tüm veren CA'lar için minimum kripto anahtar boyutunda RSA 2048 bit modülü gerekir. Microsoft artık RSA 1024-bit modüllü bir son kullanma tarihi olan kök sertifikaları kabul etmeyecektir. Yeni köklerin gönderim tarihinden itibaren en az 8 yıl geçerli olmasını, ancak özellikle 2048 bitlik RSA modülüne sahip olmaları durumunda 2030 yılından önce sona ermelerini tercih ediyoruz.
Kök sertifikadan verilen sertifikaların CRL dağıtım noktası uzantısını desteklemesi gerekir. CRL dağıtım noktası, herkesin erişebileceği bir konumu göstermelidir.
CA'nın belgelenmiş bir iptal politikası olması ve CA'nın verdikleri sertifikaları iptal edebilmesi gerekir.
CA, bir denetimi tamamlamalı ve on iki (12) ayda bir Microsoft'a denetim sonuçları sunmalıdır. Denetim, Genişletilmiş Anahtar Kullanımları (EKU) ataması yoluyla Microsoft tarafından etkinleştirilecek tam PKI hiyerarşisini kapsamalıdır. Etkinleştirdiğimiz tüm sertifika kullanımları periyodik olarak denetlenmelidir. Denetim raporu, bir denetimin kapsadığı belirli bir sertifika türü veren alt CA'lar da dahil olmak üzere PKI hiyerarşisinin tüm kapsamını belgelemelidir. Uygun denetimler şunları içerir:
Sertifika Yetkilileri v1.0 veya üzeri için WebTrust , CA'lar denetçisi için lisanslı bir WebTrust tarafından tamamlanır,
ISO 21188: 2006 , CA'lar denetçisi için lisanslı bir WebTrust veya değerlendiricilerin yasalarına ve politikalarına göre çalışan bir denetim otoritesi tarafından tamamlanan “Finansal hizmetler için ortak anahtar altyapı - Uygulamalar ve politika çerçevesi” CA ile aynı yetki alanında.
Bunlar, şu anda hükümet dışı CA'lar için kabul edilen denetimlerdir. Yukarıda listelenen denetimleri değiştirme ve/veya gelecekte diğer karşılaştırılabilir denetimleri kabul etme hakkımız saklıdır.
Teknik Gereksinimler
Yeni kök sertifikalar aşağıdaki teknik gereksinimleri karşılamalıdır:
Kök sertifikalar x.509 v3 sertifikası olmalıdır.
Konu Adı, CA'nın anlamlı bir adını içermelidir (ör., "Kök" veya "CA1" olamaz)
Temel Sınırlamalar uzantısı: cA = true
Anahtar Kullanımı (varsa): keyCertSign ve cRLSign
Kök Anahtar Boyutları gereksinimleri NIST SP 800-57:
RSA greater or equal to 2048-bit modulus ECC greater or equal to P256 modulus
Karma algoritması en az SHA1 olmalıdır. MD2, MD4 veya MD5 karmaları kabul edilmez.
Bir RSA 2048 bit modülüne eşit veya daha büyük bir kök anahtar boyutu için, kök sertifikanın gönderilmesinden en az 8 yıl sonrasına kadar ve 2030'dan daha geç olmamak kaydıyla süresinin dolması gerekir.
Ara CA sertifikaları Kök CA Programının dışında bırakılır (Daha fazla bilgi için Sık Sorulan Sorular bölümüne bakın)
CA, 15 Ocak 2009 tarihinden itibaren geçerli olmak üzere, Program tarafından dağıtılan hiçbir kök sertifikadan MD2, MD4 veya MD5 alt veya son varlık sertifikaları vermeyecektir.
Mevcut (“eski”) 1024 bit RSA kök sertifikaları, Microsoft tarafından sağlananlar dışında, 31 Aralık 2010 tarihli NIST son tarihine kadar Program tarafından dağıtımda kalabilir.
CA, 31 Aralık 2010 tarihli NIST son tarihine kadar Program tarafından dağıtılan kök sertifikalardan 1024 bit RSA sertifikaları verebilir.
ABD hükümetinin birkaç yıl önce yasaları geçirmeye çalıştığına ve onları CA'yı telekulak ve neyin olmadığı için 3. bir partinin geçerli bir sertifikasını almaya zorlama hakkı verdiğine inanıyorum. Bunun kanıtını bulamadım, bu yüzden Rory'nin bahsettiği DefCon görüşmelerinde bir şeyler hatırlıyor olabilirim.
Bazı kötü hükümetlerin makinelerin SSL trafiğini görmek istediğini varsayalım. Varsayılan CA'ların yeni bir sertifika vermeye zorlanması ne kadar mümkün?
Yüklem ve soru ilgisizdir. Bir CA'nın yeni bir sertifika vermek için ne kadar kolay veya sıklıkla zorlanabileceği önemli değildir - daha önce yüklemiş olduğunuz sertifikadan özel anahtara sahip olmadıkları sürece kulak misafiri verilerinizi göremez. IIRC (ancak bunu kontrol etmenizi tavsiye ederim) CSR özel anahtarı içermez - bu yüzden CA bu şekilde alamaz. Makinelerinizin kullandığı tuşları değiştiremezler.
Bununla birlikte, sahte bir CA'nın sahte bir sertifika verebilmesi mümkündür ve bu durumda sitenize bir MITM saldırısı potansiyeli vardır. MD5 biçimi ve Etisalat ile ilgili son sorunlar bunun imkansız olmadığını göstermektedir.
İkinci soruya odaklanmaya çalışıyorum.
“Hangi varsayılan güvenilir kök sertifikaları kaldırmalıyım?” Sorunu temelde kiminle uğraştığınıza bağlıdır.
Bağlandığınız web sitelerini imzalayan tüm CA'lara güvenmeniz gerekir.
Her zaman aynı birkaç siteyi ziyaret eden büyükanne tipi bir kullanıcı için, muhtemelen bir avuç CA yeterlidir, ancak liste yoğun bir internet kullanıcısı için çok hızlı bir şekilde * büyümeyecektir.
Neden çok hızlı değil ? Tersine, bazı CA'lar çok fazla kullanılır (başarısız olmak için çok büyük olanlar da dahil olmak üzere), diğerleri ise neredeyse coğrafi olarak olduğu gibi internette çok az kullanılır.
SSLCop from securitybydefault aracı, güvensiz olduğunuz/ihtiyaç duyma olasılığınız olmayan ülkelerden engellenmesine yardımcı olabilir (örneğin, Brobdingnag hükümetinden bir web sitesine erişmeyi beklemezsiniz; o CA'nın ana kullanıcısı olur): http://www.security-projects.com/?SSLCop
Bununla birlikte, çok fazla CA'ya güvenmezseniz, kullanıcılarınızın ihtiyaç duyduğu web sitelerine erişebilecekleri güvene sahip olamayacaksınız. Yine de, güvenlik uyarısına rağmen), aynı derecede kötü.
12 Haziran 2012 itibariyle Microsoft, güvenilmeyen kök sertifikaları ve Microsoft'a güvenilmez olarak bildirilen diğer tüm sertifikaları devre dışı bırakacak yeni bir güncelleştirici yayımladı.
Güncelleştirme burada mevcuttur ve bu güncelleştirmenin zaten Windows Güncelleştirmeleri aracılığıyla dağıtılmış olup olmadığı veya bant dışı güncelleştirme olup olmadığı belirsizdir.