Bu dokümanda aşağıdaki bölümler yer alır:
Devam eden Google kök CA taşıma işlemine daha ayrıntılı bir genel bakış için Neler oluyor? başlıklı makaleyi inceleyin.
Terminoloji
Aşağıda, bu belge için öğrenmeniz gereken en önemli terimlerin bir listesini derledik. İlgili terminolojiye daha kapsamlı bir genel bakış için lütfen Google Trust Services SSS başlıklı makaleyi inceleyin.
- SSL/TLS Sertifikası
- Sertifika, şifreleme anahtarını bir kimliğe bağlar.
- SSL/TLS sertifikaları, web siteleriyle güvenli bağlantılar kurmak ve kimlik doğrulaması yapmak için kullanılır. Sertifikalar, sertifika yetkilisi olarak bilinen tüzel kişiler tarafından düzenlenir ve kriptografik olarak imzalanır.
- Tarayıcılar, iletilen bilgilerin doğru sunucuya gönderildiğinden ve iletim sırasında şifrelendiğinden emin olmak için güvenilir sertifika yetkilileri tarafından verilen sertifikalardan yararlanır.
- Güvenli Yuva Katmanı (SSL)
- Güvenli Yuva Katmanı, internet iletişimlerini şifrelemek için kullanılan en yaygın şekilde dağıtılan protokoldür. SSL protokolü artık güvenli kabul edilmemektedir ve kullanılmamalıdır.
- Taşıma Katmanı Güvenliği (TLS)
- Taşıma Katmanı Güvenliği, SSL'nin yerini alacak.
- Sertifika Yetkilisi (CA)
- Sertifika yetkilisi, cihazlar ve insanlar için dijital bir pasaport ofisi gibidir. Bir varlığın (ör. web sitesi) iddia ettiği kişi olduğunu doğrulamak için kriptografik olarak korunan belgeler (sertifikalar) verir.
- CA'lar, sertifika vermeden önce sertifikadaki adların, sertifikayı isteyen kişi veya tüzel kişiyle ilişkili olduğunu doğrulamaktan sorumludur.
- Sertifika Yetkilisi terimi, hem Google Trust Services gibi kuruluşları hem de sertifika veren sistemleri ifade edebilir.
- Kök sertifika deposu
- Kök sertifika deposu, bir Uygulama Yazılımı Tedarikçisi tarafından güvenilen bir dizi Sertifika Yetkilisi içerir. Çoğu web tarayıcısı ve işletim sisteminin kendi kök sertifika deposu vardır.
- Sertifika yetkilisinin, kök sertifika deposuna dahil edilebilmesi için Uygulama Yazılımı Tedarikçisi tarafından belirlenen katı koşulları karşılaması gerekir.
- Bu şartlar genellikle CA/Browser Forum şartları gibi sektör standartlarına uygunluğu içerir.
- Kök Sertifika Yetkilisi
- Kök sertifika yetkilisi (veya daha doğrusu sertifikası), sertifika zincirindeki en üst sertifikadır.
- Kök CA sertifikaları genellikle kendinden imzalıdır. Bunlarla ilişkili özel anahtarlar, yüksek düzeyde güvenli tesislerde depolanır ve yetkisiz erişime karşı korumak için çevrimdışı durumda tutulur.
- Ara Sertifika Yetkilisi
- Ara Sertifika Yetkilisi (veya daha doğrusu, sertifikası), sertifika zincirindeki diğer sertifikaları imzalamak için kullanılan bir sertifikadır.
- Ara CA'lar esasen, Kök CA sertifikasının çevrimdışı kalmasına izin verirken online sertifika verilmesini sağlamak için mevcuttur.
- Ara CA'lar, bağımlı CA olarak da bilinir.
- Sertifika Yetkilisi
- Sertifikayı Veren Sertifika Yetkilisi veya daha doğru bir ifadeyle, sertifika, bir sertifika zincirinde en altta yer alan sertifikayı imzalamak için kullanılan sertifikadır.
- En alttaki bu sertifika genellikle abone sertifikası, son varlık sertifikası veya yaprak sertifika olarak adlandırılır. Bu dokümanda sunucu sertifikası terimini de kullanacağız.
- Sertifika zinciri
- Sertifikalar, sertifikayı veren ile bağlantılıdır (şifreleme olarak imzalanır). Sertifika zinciri, bir son sertifika, tüm yayıncı sertifikaları ve bir kök sertifikadan oluşur.
- Çapraz imza
- Uygulama Yazılımı Tedarikçilerinin istemcileri, ürünlerinin güvenilir olması için kök sertifika depolarını yeni CA sertifikalarını içerecek şekilde güncellemelidir. Yeni CA sertifikalarını içeren ürünlerin yaygın olarak kullanılması biraz zaman alır.
- CA sertifikaları, eski istemcilerle uyumluluğu artırmak için daha eski bir CA tarafından "çapraz imzalanabilir". Böylece aynı kimlik (ad ve anahtar çifti) için etkili bir şekilde ikinci bir CA sertifikası oluşturulur.
- İstemciler, kök sertifika depolarında bulunan CA'lara bağlı olarak, güvendikleri köke kadar farklı bir sertifika zinciri oluşturur.
Genel bilgiler
What is happening?
Büyük resim
2017'de Google, HTTPS tarafından kullanılan TLS internet güvenliğinin temeli olan kriptografik imzalar olan kendi kök sertifikalarını yayınlamak ve kullanmak için çok yıllık bir projeye başladı.
İlk aşamadan sonra Google Haritalar Platformu hizmetlerinin TLS güvenliği, tanınmış ve yaygın olarak güvenilen bir kök sertifika yetkilisi (CA) olan GS Root R2 tarafından garanti edilmiştir. GS Root R2, Google'ın kendi kendini düzenleyen Google Trust Services (GTS) kök CA'larına geçişi kolaylaştırmak için bu kuruluşu GMO GlobalSign'dan satın almıştır.
Pratikte tüm TLS istemcileri (web tarayıcıları, akıllı telefonlar ve uygulama sunucuları gibi) bu kök sertifikaya güvenmiştir ve bu nedenle, taşımanın ilk aşamasında Google Haritalar Platformu sunucularıyla güvenli bir bağlantı kurabilmiştir.
Ancak bir CA, tasarım gereği kendi sertifikasının geçerlilik süresinden sonra geçerli olan sertifikalar yayınlayamaz. GS Root R2'nin süresi 15 Aralık 2021'de doluyor. Google, kendi kök CA'sı GTS Root R1 tarafından verilen sertifikayı kullanarak kendi hizmetlerini yeni bir CA olan GTS Root R1 Cross'a taşıyacak.
Modern işletim sistemlerinin ve TLS istemci kitaplıklarının büyük çoğunluğu hâlihazırda GTS kök CA'lara güvense de Google, çoğu eski sistemde sorunsuz bir geçiş sağlamak amacıyla şu anda mevcut en eski ve en güvenilir kök CA'lardan biri olan GlobalSign Root CA - R1 ile GMO GlobalSign'dan çapraz imza aldı.
Bu nedenle, çoğu müşterinin Google Haritalar Platformu istemcileri bu güvenilir kök CA'lardan birini (veya ikisini birden) zaten tanır ve taşıma işleminin ikinci aşamasından hiçbir şekilde etkilenmez.
Bu durum, 2018'de taşımanın ilk aşamasında işlem yapan müşteriler için de geçerlidir. Müşterilerin o sırada güvenilir Google kök CA paketimizdeki tüm sertifikaları yükleyerek talimatlarımızı uyguladığını varsayıyoruz.
Aşağıdakiler geçerliyse sistemlerinizi doğrulamanız gerekir:
- Hizmetleriniz standart olmayan veya eski platformlarda çalışıyorsa ve/veya kendi kök sertifika deponuzu yönetiyorsanız
- Google'ın kök CA taşıma işleminin ilk aşamasında, 2017-2018'de herhangi bir işlem yapmadıysanız veya güvenilir Google kök CA paketindeki tüm sertifikaları yüklemediyseniz
Yukarıdaki durum sizin için geçerliyse taşıma işleminin bu aşamasında Google Haritalar Platformu'nun kesintisiz şekilde kullanılabilmesi için istemcilerinizin önerilen kök sertifikalarla güncellenmesi gerekebilir.
Diğer teknik ayrıntılar için aşağıya bakın. Genel talimatlar için lütfen Kök sertifika depomun güncellenmesi gerekip gerekmediğini doğrulama bölümüne bakın.
Ayrıca, hizmetlerinizi gelecekte yapılacak kök CA değişikliklerine karşı korumak için kök sertifika depolarınızı yukarıda seçilen kök CA paketiyle senkronize etmeye devam etmenizi de öneririz. Ancak bu değişiklikler önceden duyurulacaktır. Gelişmelerden nasıl haberdar olabileceğinizle ilgili daha fazla talimat için Bu taşıma aşamasıyla ilgili güncellemeleri nasıl alabilirim? ve Gelecekteki geçişler hakkında nasıl önceden bildirim alabilirim? bölümlerini inceleyin.
Teknik özet
15 Mart 2021'de Google Güvenlik Blogu'nda duyurulduğu gibi, Google Haritalar Platformu'nun 2018'in başlarından beri kullandığı kök CA olan GS Root R2'nin süresi 15 Aralık 2021'de dolacak. Bu nedenle Google, bu yıl içinde yeni yayınlanan bir CA'ya (GTS Root R1 Cross) geçecektir. Bu, hizmetlerimizin kademeli olarak bu yeni CA tarafından verilen TLS alt sertifikalarına geçeceği anlamına gelir.
Modern TLS istemcilerinin ve sistemlerinin neredeyse tamamı GTS Root R1 sertifikasıyla önceden yapılandırılmıştır veya bu sertifikayı normal yazılım güncellemeleri aracılığıyla almalıdır. GlobalSign Root CA - R1, eski sistemlerde bile kullanılabilir.
Ancak, en azından aşağıdaki noktaların her ikisi de geçerliyse sistemlerinizi doğrulamalısınız:
- Hizmetleriniz standart olmayan veya eski platformlarda çalışıyorsa ve/veya kendi kök sertifika deponuzu yönetiyorsanız
- Google'ın kök CA taşımasının ilk aşamasında 2017-2018'de herhangi bir işlem yapmadıysanız veya güvenilir Google kök CA paketindeki tüm sertifikaları yüklemediyseniz
Kök sertifika depomun güncellemeye ihtiyacı olup olmadığını doğrulama bölümü, sisteminizin etkilenip etkilenmeyeceğini test etmek için genel rehberlik sunar.
Ayrıntılar için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize tutmalıyım? başlıklı soruya bakın.
Bu taşıma aşamasıyla ilgili güncellemeleri nasıl alabilirim?
Güncellemeler için herkese açık 186840968 kimlikli sorunu işaretleyin. Bu SSS, taşıma işlemi sırasında herkese ilgi çekici olabilecek konularla karşılaştığımızda da güncellenir.
Gelecekteki taşıma işlemleriyle ilgili önceden bildirim alabilir miyim?
Google Güvenlik Blogu'nu takip etmenizi öneririz. Ayrıca, blogdaki resmi duyuru doğrultusunda ürüne özel dokümanları en kısa sürede güncellemeye çalışacağız.
Daha fazla sayıda müşteriyi etkilemesi muhtemel değişiklikler hakkında forumda düzenli olarak güncellemeler yayınladığımız için lütfen Google Haritalar Platformu Bildirimleri'ne de abone olun.
Birden çok Google hizmeti kullanıyoruz. Kök CA taşıma işlemi bunların tümünü etkiler mi?
Evet, kök CA taşıma işlemi tüm Google hizmetleri ve API'leri genelinde gerçekleşir ancak zaman çizelgesi hizmete göre değişiklik gösterebilir. Ancak, Google Haritalar Platformu istemci uygulamalarınız tarafından kullanılan kök sertifika depolarının güvenilir Google kök CA paketinde listelenen tüm CA'ları içerdiğini doğruladıktan sonra hizmetleriniz devam eden taşıma işleminden etkilenmez ve bu dosyaları senkronize halde tutmak sizi gelecekteki kök CA değişikliklerine karşı korur.
Daha ayrıntılı bilgi için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize etmeliyim? ve Hangi tür uygulamaların bozulma riski var? konularına göz atın.
Aşağıdaki Kök sertifika depomun güncellenmesinin gerekip gerekmediğini doğrulama bölümünde, sisteminizi test etmeyle ilgili genel talimatlar da sağlanmaktadır.
Kök sertifika depom için güncelleme gerekip gerekmediğini doğrulama
Uygulama ortamınızı aşağıda listelenen test uç noktalarıyla karşılaştırarak test edin:
- GTS Root R1 Cross test uç noktasına TLS bağlantısı kurabiliyorsanız GS Root R2 sona ermesinden etkilenmezsiniz.
- GTS Root R1 test uç noktası ile TLS bağlantısı kurabiliyorsanız uygulamanız muhtemelen 2028'de GTS Root R1 Cross ve GlobalSign Root CA - R1'in geçerlilik süresinin sona ermesinden etkilenmeyecektir.
Sisteminiz genellikle aşağıdaki durumlarda bu kök CA değişikliğiyle uyumlu olur:
- hizmetiniz bakımlı bir ana akım işletim sisteminde çalışıyorsa ve hem işletim sistemini hem de hizmetinizin yama kullandığı kitaplıkları koruduysanız ve kendi kök sertifika deponuzu sürmüyorsanız veya:
- Önceki önerilerimizi uyguladıysanız ve güvenilir Google kök CA paketindeki tüm kök CA'ları yüklediniz.
Bu durumdan etkilenmiş olabilecek müşterilerin, gelecekte hizmet kesintilerinin yaşanmaması için güvenilir Google kök CA paketindeki sertifikaları hemen yüklemesi gerekir.
Ayrıntılar için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize tutmalıyım? başlıklı soruya bakın.
Kök sertifika depomuzu doğrulamak için kullanabileceğim basit bir araç var mı?
İncelemelerinizde curl
ve openssl
adlı iki komut satırı aracından yararlanabilirsiniz. Her ikisi de çoğu platformda kullanılabilir ve kurulumunuzu
test etmek için kapsamlı seçenekler sunar.
curl
değerini alma talimatları için aşağıdaki curl'i alma bölümüne bakın.
Aşağıda gösterilen openssl
komutları 1.1.1 veya sonraki sürümler içindir.
1.1.1'den önceki sürümler desteklenmemektedir. Daha eski bir sürüm kullanıyorsanız bu komutları sürümünüze uygun şekilde yükseltin veya değiştirin. openssl
'ü edinmeyle ilgili talimatlar için aşağıdaki OpenSSL'i edinme bölümüne bakın.
Ayrıca, aşağıda İhtiyacım olan araçları nereden edinebilirim? bölümünde daha fazla faydalı araç bulabilirsiniz.
Somut test talimatları için lütfen Kök sertifika depomun güncellenmesi gerektiğini doğrulama bölümüne bakın.
Varsayılan kök sertifika deponuzu test etme
curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
Güvenilir Google kök CA paketini doğrulama
Güvenilir Google kök CA paketini indirin, ardından aşağıdaki adımları uygulayın:
curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
Google kök CA taşıma işlemi nasıl ve ne zaman devam edecek?
- Ocak 2017'de duyurulan ilk aşama (GS Root R2'ye geçiş), 2017'nin sonlarında başladı ve 2018'in ilk yarısında tamamlandı.
- İkinci aşama (GTS Root R1 Cross'a geçiş) Mart 2021'de duyuruldu ve 15 Aralık 2021'de GS Root R2'nin geçerlilik süresinin sona ermesinden önce önümüzdeki aylarda kullanıma sunulacaktır.
Sonraki taşıma aşamalarının programları, gelecekteki sertifika sürelerinin sona ermesinden çok önce duyurulacaktır.
Ancak kök sertifika deponuzu, güvenilir Google kök CA paketindeki seçili kök CA'larla senkronize halde tutarsanız uygulamalarınızı geleceğe hazırlayabilirsiniz.
Daha fazla bilgi için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize etmeliyim? sorusuna da göz atın.
Her Google hizmeti için genel kullanıma sunma planı
- Aşamalı sunum, tek bir veri merkezinde başlar.
- Kullanıma sunma süreci, küresel çapta kapsama alınana kadar kademeli olarak daha fazla veri merkezine genişletilir.
- Herhangi bir aşamada ciddi sorunlar tespit edilirse sorunlar giderilirken testler geçici olarak geri çekilebilir.
- Önceki iterasyonlardan gelen girişlere bağlı olarak, tüm Google hizmetleri kademeli olarak yeni sertifikalara taşınana kadar diğer Google hizmetleri de kullanıma sunuma dahil edilmiştir.
Kim, ne zaman ve nerede etkilenecek?
Yeni veri merkezlerine geçiş yapıldıkça Google Haritalar Platformu geliştiricilerinin giderek daha fazlası yeni sertifikaları almaya başlayacak. İstemci istekleri coğrafi olarak yakın veri merkezlerindeki sunuculara yönlendirildiğinden, değişiklikler bir dereceye kadar yerelleştirilecektir.
Değişiklikten kimin, ne zaman ve nerede etkileneceğini önceden kesin olarak söyleyemeyeceğimiz için tüm müşterilerimizin, hizmetlerini Google kök CA'ya geçiş aşamalarından çok önce doğrulamasını ve geleceğe hazırlamasını öneriyoruz.
Daha fazla bilgi için Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrulayabilirim? bölümüne bakın.
Dikkat edilecek noktalar
Gerekli kök sertifikayla yapılandırılmamış istemciler, Google Haritalar Platformu'na olan TLS bağlantılarını doğrulayamaz. Bu durumda istemciler genellikle sertifika doğrulamasının başarısız olduğuna dair bir uyarı gönderir.
İstemciler, TLS yapılandırmalarına bağlı olarak Google Haritalar Platformu isteği göndermeye devam edebilir veya isteği göndermeyi reddedebilir.
Bir TLS istemcisinin Google Haritalar Platformu ile iletişim kurması için gereken minimum koşullar nelerdir?
Google Haritalar Platformu sertifikaları DNS Özne Alternatif Adları (SAN'lar) kullanır. Bu nedenle, istemcinin sertifika işleme özelliği, addaki en soldaki etiket olarak tek bir joker karakter (ör. *.googleapis.com
) içerebilecek SAN'ları desteklemelidir.
Diğer koşullar için lütfen GTS SSS bölümündeki TLS istemcisinin Google ile iletişim kurması için önerilen koşullar nelerdir? başlıklı bölüme bakın.
Hangi tür uygulamalar çalışmama riski altında?
Uygulama, geliştiricinin uyguladığı herhangi bir kısıtlama olmadan sistem kök sertifika deposunu kullanır
Google Haritalar Platformu web hizmeti uygulamaları
Yaygın bir işletim sistemi kullanıyorsanız (ör. Ubuntu, Red Hat, Windows 10 veya Server 2019, OS X) kullanıyorsanız, varsayılan kök sertifika deponuzun zaten GTS Root R1 sertifikasını içermesi gerekir.
Artık güncelleme almayan eski bir işletim sistemi sürümü kullanıyorsanız GTS Root R1 sertifikasına sahip olabilirsiniz veya olmayabilirsiniz. Ancak kök sertifika deponuzda büyük olasılıkla en eski ve en yaygın olarak güvenilen kök CA'lardan biri olan GlobalSign Root CA - R1 bulunur.
Google Haritalar Platformu web hizmetlerini doğrudan son kullanıcı cihazından çağıran mobil uygulamalar için Mobil uygulamalarda çalışmama riski var mı? sorusundaki yönergeler geçerlidir.
İstemci tarafı Google Haritalar Platformu uygulamaları
Maps JavaScript API uygulamaları genellikle uygulamayı çalıştıran web tarayıcısının kök sertifikalarını temel alır. Daha ayrıntılı bilgi için JavaScript uygulamaları bozulma riski var mı? bölümüne bakın.
Android için Haritalar SDK'sı, iOS için Haritalar SDK'sı, Android için Yerler SDK'sı veya iOS için Yerler SDK'sından herhangi birini kullanan yerel mobil uygulamalar için Google Haritalar Platformu web hizmetlerini çağıran uygulamalarla aynı kurallar geçerlidir.
Daha fazla bilgi için Mobil uygulamalar bozulma riski var mı? sorusuna bakın.
Uygulama kendi sertifika paketini kullanıyor veya sertifika sabitleme gibi gelişmiş güvenlik özelliklerini kullanıyor
Sertifika paketinizi kendiniz güncellediğinizden emin olmanız gerekir. Kök sertifika depomu güvenilir Google kök CA paketiyle senkronize tutmalı mıyım? sorusuyla ilgili olarak da belirtildiği gibi, güvenilir Google kök CA paketindeki tüm sertifikaları kendi kök sertifika deponuza içe aktarmanızı öneririz.
Uygulamanızın bağlandığı Google alanları için sertifikaları veya ortak anahtarları sabitliyorsanız sertifikaları ve ortak anahtarları, uygulamanızdaki güvenilir varlıklar listesine eklemeniz gerekir.
Sertifika veya ortak anahtar sabitleme hakkında daha fazla bilgi için Daha fazla bilgiye mi ihtiyacınız var? sorusu altında listelenen harici kaynaklara bakın.
Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize tutmalıyım?
Güvenilir Google kök CA paketindeki kök CA'ların özel olarak seçilmiş listesi, yakın gelecekte Google hizmetleri tarafından kullanılabilecek tüm CA'ları içerir.
Bu nedenle, sisteminizi geleceğe hazırlamak isterseniz kök sertifika deponuzun paketteki tüm sertifikaları içerdiğini doğrulamanızı ve bu ikisini senkronize durumda tutmayı alışkanlık haline getirmenizi önemle tavsiye ederiz.
Bu, özellikle hizmetleriniz bakıma alınmayan bir işletim sistemi sürümünde çalışıyorsa, işletim sisteminizi ve kitaplıklarınızı başka nedenlerle güncelleyemiyorsanız veya kendi kök sertifika deponuzu yönetiyorsanız önemlidir.
Gelecekteki kök CA taşıma işlemleri hakkında nasıl güncelleme alacağınızı öğrenmek için Gelecekteki taşıma işlemleri için nasıl önceden bildirim alabilirim? sorusuna bakın. Kök sertifika deponuzu seçilen listeyle düzenli olarak senkronize etmek, CA değişikliklerinden dolayı hizmetlerinizi gelecekte karşılaşılabilecek hizmet kesintilerine karşı korur ve hizmetlerinizi hem GTS Root R1 Cross hem de GlobalSign Root CA - R1 süresinin dolana kadar çalışmaya devam eder.
Ayrıca lütfen Google hizmetlerine bağlanan bir ürün geliştiriyorum. Daha fazla öneri için GTS SSS bölümünde hangi CA sertifikalarına güvenmem gerekiyor? bölümüne göz atabilirsiniz.
Neden son veya ara CA sertifikaları yüklememeliyim?
Bunu yaparsanız yeni bir sertifika kaydettiğimizde veya ara CA'yı değiştirdiğimizde uygulamanızın bozulma riski ortaya çıkar. Bu iki işlemden herhangi biri herhangi bir zamanda ve önceden haber verilmeksizin gerçekleşebilir. Bu durum, maps.googleapis.com
tarafından sunulanlar gibi tekil sunucu sertifikaları ve GTS Root R1 Cross gibi tüm ara CA'larımız için eşit şekilde geçerlidir.
Hizmetlerinizi bu tür saldırılara karşı korumak için yalnızca güvenilir Google kök CA paketindeki kök sertifikaları yüklemeniz ve kendisine bağlı sertifika zincirinin tamamının güvenilirliğini doğrulamak için yalnızca kök sertifikayı kullanmanız gerekir.
Kök sertifika yetkilisi güvenilir olduğu sürece, modern TLS kitaplığı uygulamalarının bu tür güven zincirlerini otomatik olarak doğrulayabilmesi gerekir.
JavaScript uygulamalarının bozulma riski var mı?
GTS kök sertifikaları, çoğu modern tarayıcı tarafından zaten iyi bir şekilde yerleştirilmiş ve güvenilirdir. GMO GlobalSign'dan alınan çapraz imza, eski tarayıcılardaki çoğu son kullanıcı için bile sorunsuz bir geçiş sağlayacaktır. Buna Maps JavaScript API için resmi olarak desteklenen tüm tarayıcılar dahildir.
Her modern tarayıcı, son kullanıcıların tarayıcının güvendiği sertifikaları doğrulamasına ve genellikle bu sertifikaları düzenlemesine izin vermelidir. Tam konumu her tarayıcıda farklı olsa da sertifika listesini genellikle Ayarlar bölümünde bulabilirsiniz.
Mobil uygulamalar bozulma riskiyle karşı karşıya mı?
Cihaz üreticisinden düzenli güncelleme almaya devam eden Android ve Apple iOS cihazların da gelecekte sorunsuz çalışacağı beklenir. Eski Android telefon modellerinin çoğu en azından GlobalSign Root CA - R1 sertifikasını içerir. Ancak güvenilir sertifika listesi cep telefonu üreticisine, cihaz modeline ve Android sürümüne göre değişiklik gösterebilir.
Ancak GTS Root R1 dahil olmak üzere GTS kök CA'ları için destek, Android 10'dan önceki sürümlerde sınırlı olabilir.
Apple, iOS cihazlar için destek sayfalarında her yeni iOS sürümünün güvenilir kök CA'larının listesini tutar. Ancak 5 ve sonraki tüm iOS sürümleri GlobalSign Root CA - R1'i destekler.
GTS Root R1 dahil olmak üzere GTS kök CA'ları, iOS 12.1.3 sürümünden itibaren desteklenmektedir.
Daha fazla bilgi için Mobil telefonumdaki güvenilir kök sertifikalarını nasıl kontrol edebilirim? başlıklı soruya bakın.
Tarayıcım veya işletim sistemim Google Trust Services kök sertifikalarını ne zaman içerecek?
Google, son yıllarda yaygın olarak kullanılan ve güvenilir kök sertifika paketlerini korumak için tüm büyük üçüncü taraflarla yoğun bir şekilde çalışmıştır. Apple ve Microsoft gibi işletim sistemi üreticilerinin yanı sıra Google'ın kendi Android ve ChromeOS ekipleri, Mozilla, Apple, Microsoft gibi tarayıcı geliştiricilerin yanı sıra Google'ın kendi Chrome ekibi, telefon, set üstü kutu, TV, oyun konsolu, yazıcı gibi donanım üreticileri bu örnekler arasındadır.
Bu nedenle, şu anda bakımı yapılan sistemlerin GTS Root R1 dahil olmak üzere Google'ın yeni GTS Root CA'larını desteklemesi ve hatta eski sistemlerin bile önümüzdeki yıllarda Google tarafından verilen sertifikaların çapraz imzalanması için kullanılacak GlobalSign Root CA - R1'i desteklemesi oldukça olasıdır.
Bununla birlikte, üçüncü taraf sertifikalarının dahil edilme zaman çizelgeleri büyük ölçüde Google'ın kontrolü dışında olduğundan, sunabileceğimiz en iyi genel tavsiye, mevcut sistem güncellemelerini düzenli olarak uyguladığınızdan emin olmanızdır.
Mozilla'nın CA Sertifika Programı gibi belirli üçüncü taraflar kendi sertifika dahil etme zaman çizelgelerini belgelemiş olabilir.
Sorun giderme
İhtiyaç duyduğum araçları nereden edinebilirim?
Kıvırma
İşletim sisteminizin dağıtımında curl
yoksa https://curl.haxx.se/ adresinden indirebilirsiniz. Kaynağı indirip aracı kendiniz derleyebilir veya platformunuz için mevcutsa önceden derlenmiş bir ikili dosyayı indirebilirsiniz.
OpenSSL'i edinme
OS dağıtımınız openssl
sağlamıyorsa kaynağı https://www.openssl.org/ adresinden indirebilir ve aracı derleyebilirsiniz. Üçüncü taraflarca derlenen ikili dosyaların listesini https://www.openssl.org/community/binaries.html adresinde bulabilirsiniz.
Ancak bu derlemelerin hiçbiri OpenSSL ekibi tarafından desteklenmez veya herhangi bir şekilde onaylanmaz.
Wireshark, Tshark veya Tcpdump'ı alma
Çoğu Linux dağıtımı wireshark
hizmetini sunarken, komut satırı aracı tshark
ve tcpdump
diğer işletim sistemleri için ilk ikisinin önceden derlenmiş sürümlerini https://www.wireshark.org adresinde bulabilirsiniz.
Tcpdump ve LibPCAP'nin kaynak kodunu https://www.tcpdump.org adresinde bulabilirsiniz.
Bu faydalı araçlarla ilgili belgeler sırasıyla Wireshark Kullanıcı Kılavuzu, Tshark man sayfasında ve Tcpdump man sayfasında bulunabilir.
Java keytool'u alma
keytool
komut satırı aracı, tüm Java Geliştirme Kiti (JDK) veya Java Çalışma Zamanı Ortamı (JRE) sürümüyle birlikte gönderilmelidir. keytool.
almak için bunları yükleyin. Ancak uygulamanız Java kullanılarak oluşturulmadığı sürece kök sertifika doğrulaması için keytool
kullanılması gerekmez.
Üretimde kesinti olduğunda yapılması gerekenler
İlk yapmanız gereken, güvenilir Google kök CA paketindeki gerekli kök sertifikaları, uygulamanızın kullandığı kök sertifikalara yüklemektir.
- Yerel kök sertifika deponuzu yükseltmek için sistem yöneticilerinizle birlikte çalışın.
- Sisteminiz için geçerli ipuçları için bu SSS'ye göz atın.
- Platforma veya sisteme özgü daha fazla yardıma ihtiyacınız olursa sistem sağlayıcınızın sunduğu teknik destek kanallarına ulaşın.
- Genel yardım için Google Haritalar Platformu destek ekibiyle iletişime geçme bölümünde açıklandığı şekilde destek ekibimizle iletişime geçin. Not: Platforma özgü sorunlarla ilgili olarak yalnızca en iyi şekilde yardım sağlanır.
- Taşımayla ilgili daha fazla güncelleme için herkese açık 186840968 kimlikli sorunu işaretleyin.
Google Haritalar Platformu Destek Ekibi ile iletişime geçme
İlk sorun giderme
Genel sorun giderme talimatları için Kök sertifika depomun güncellenmesi gerekip gerekmediğini doğrulama bölümüne bakın.
Kök sertifikaları içe veya dışa aktarmanız gerekiyorsa Güvenilir sertifikalarınızı yönetme bölümü değerli bilgiler de sağlayabilir.
Sorun çözülmediyse ve Google Haritalar Platformu destek ekibine ulaşmaya karar verirseniz aşağıdaki bilgileri de sağlamaya hazır olun:
- Etkilenen sunucularınız nerede bulunuyor?
- Hizmetiniz hangi Google IP adreslerini arıyor?
- Hangi API'ler bu sorundan etkileniyor?
- Sorun tam olarak ne zaman başladı?
Aşağıdaki komutların çıkışları:
curl -vvI https://maps.googleapis.com; \ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \ curl -vvI https://good.gtsr1.demosite.pki.goog/; \ openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \ curl -vvI https://good.gtsr1x.demosite.pki.goog/; \ openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
Gerekli araçları alma talimatları için İhtiyacım olan araçları nereden alabilirim? başlıklı soruya bakın.
Destek yazışması oluşturma
Lütfen Google Haritalar Platformu Destek ve Kaynakları bölümündeki Destek kaydı oluşturma talimatlarını uygulayın.
Destek kaydı oluştururken İlk sorun giderme bölümünde listelenen verilere ek olarak lütfen aşağıdakileri de sağlayın:
- Herkese açık IP adresleriniz nedir?
- DNS sunucunuzun herkese açık IP adresi nedir?
- Mümkünse, tüm paketi kesmeden yakalamak için yeterince büyük bir anlık görüntü uzunluğu kullanan (ör.
tcpdump
ürününün eski sürümlerinde-s0
kullanarak) mümkünse bir tcpdump veya Wireshark paketinin,https://maps.googleapis.com/
karşısında PCAP biçiminde başarısız TLS anlaşmasının yakalanması. - Mümkünse hizmetinizden, TLS bağlantısı başarısızlığının tam nedenini gösteren günlük alıntıları (tercihen tam sunucu sertifikası zinciri bilgileriyle birlikte)
Gerekli araçları alma talimatları için İhtiyacım olan araçları nereden alabilirim? başlıklı soruya bakın.
186840968 numaralı herkese açık sorun hakkında yayın yapma
Herkese açık 186840968 numaralı sorunla ilgili yorum gönderirken lütfen İlk sorun giderme bölümünde listelenen bilgileri ekleyin.
DNS'min herkese açık adresini nasıl öğrenebilirim?
Linux'ta aşağıdaki komutu çalıştırabilirsiniz:
dig -t txt o-o.myaddr.l.google.com
Windows'da nslookup'ı etkileşimli modda kullanabilirsiniz:
C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com
curl çıkışını yorumlama
curl
öğesini -vvI
işaretleriyle çalıştırmak çok yararlı bilgiler sağlar. Çıktıyı yorumlamayla ilgili birkaç talimatı aşağıda bulabilirsiniz:
- "
*
" ile başlayan satırlar, TLS pazarlığıyla ilgili çıkışın yanı sıra bağlantıyı sonlandırma bilgilerini gösterir. - "
>
" ile başlayan satırlar,curl
tarafından gönderilen giden HTTP isteğini gösterir. - "
<
" ile başlayan satırlar, sunucudan aldığı HTTP yanıtını gösterir. - Protokol HTTPS ise "
>
" veya "<
" satırlarının bulunması başarılı bir TLS el sıkışmasını gösterir.
Kullanılan TLS kitaplığı ve kök sertifika paketi
curl
uygulamasını -vvI
işaretleriyle çalıştırmak, kullanılan kök sertifika deposunu da yazdırır. Ancak tam çıkış, burada gösterildiği gibi sisteme göre değişiklik gösterebilir.
curl
'nin NSS'ye bağlı olduğu bir Red Hat Linux makinesinden alınan çıkış şu satırları içerebilir:
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
Bir Ubuntu veya Debian Linux makinesinden gelen çıkış şu satırları içerebilir:
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
--cacert
işaretçisi kullanılarak verilen Google kök sertifikası PEM dosyasını kullanan bir Ubuntu veya Debian Linux makinesinden alınan çıkış şu satırları içerebilir:
* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
CApath: /etc/ssl/certs
Kullanıcı aracısı
Giden istekler, curl
ve sisteminizle ilgili yararlı bilgiler sağlayabilecek User-Agent başlığını içerir.
Red Hat Linux makinesinden bir örnek:
> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>
Başarısız TLS el sıkışması
Bu kod örneğindekiler gibi satırlar, bağlantının güvenilmeyen bir sunucu sertifikası nedeniyle TLS el sıkışması ortasında sonlandırıldığını gösterir. >
veya <
ile başlayan hata ayıklama çıkışının olmaması da başarısız bağlantı denemesinin güçlü göstergeleridir:
*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**
Başarılı TLS el sıkışması
Başarılı bir TLS el sıkışması, bu kod örneğindekilere benzer görünümlü satırların varlığıyla gösterilir. Şifrelenmiş bağlantı için kullanılan şifre paketi ve kabul edilen sunucu sertifikasının ayrıntıları da listelenir. Ayrıca, >
veya <
ile başlayan satırların varlığı, HTTP yükü trafiğinin TLS şifrelenmiş bağlantı üzerinden başarıyla iletildiğini gösterir:
* Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
* start date: Mar 23 08:24:47 2021 GMT
* expire date: Jun 15 08:24:46 2021 GMT
* subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
* issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…
Alınan sunucu sertifikalarını insanlar tarafından okunabilecek şekilde yazdırma
Çıktının PEM biçiminde olduğunu varsayarak (ör. openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null
'ten gelen çıktı), aşağıdaki adımları uygulayarak sunulan sertifikayı yazdırabilirsiniz:
Başlık ve altbilgi dahil olmak üzere Base64 kodlu sertifikanın tamamını kopyalayın:
-----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----
Ardından şunları yapın:
openssl x509 -inform pem -noout -text ````
Daha sonra, kopyalama arabelleğinizin içeriğini terminale yapıştırın.
Return tuşuna basın.
Örnek giriş ve çıkış için PEM sertifikalarını kullanıcı tarafından okunabilir biçimde yazdırma bölümüne bakın.
OpenSSL'de çapraz imzalı Google sertifikaları nasıl görünür?
…
---
Certificate chain
0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1
---
…
Güvenilir sertifikalarınızı yönetme
Güvenilir kök sertifikalarını cep telefonumda nasıl kontrol edebilirim?
Android'de güvenilen sertifikalar
Mobil uygulamalar bozulma riski altında mı? sorusunda belirtildiği gibi, Android 4.0 sürümünden beri cep telefonu kullanıcılarının Ayarlar bölümündeki güvenilir sertifika listesini doğrulamalarına izin verilmektedir. Bu tabloda tam Ayarlar menü yolu gösterilmektedir:
Android sürümü | Menü yolu |
---|---|
1, x, 2, x, 3,x | Yok |
4.x, 5.x, 6.x, 7.x | Ayarlar > Güvenlik > Güvenilir kimlik bilgileri |
8, x, 9 | Ayarlar > Güvenlik ve Konum > Şifreleme ve kimlik bilgileri > Güvenilir kimlik bilgileri |
10+ | Ayarlar > Güvenlik > Gelişmiş > Şifreleme ve kimlik bilgileri > Güvenilir kimlik bilgileri |
Bu tabloda, şu anda mevcut Android sanal cihaz (AVD) sistem görüntüleri kullanılarak yapılan manuel doğrulamaya dayalı olarak Android sürümüne göre en önemli kök sertifikalarının olası kullanılabilirliği gösterilmektedir. Sistem görüntülerinin artık kullanılamadığı durumlarda AOSP ca-certificates Git deposu sürüm geçmişine başvurulur:
Android sürümü | GTS Root R1 | GlobalSign Kök CA - R1 | GlobalSign Root R2 (15 Aralık 2021'e kadar geçerlidir) |
---|---|---|---|
2,3, 3,2, 4,x, 5,x, 6,x, 7,x, 8,x, 9 | |||
10+ |
Android sistem kök sertifikaları deposu, genellikle donanım yazılımı güncellemesi veya cihazın rootlanması olmadan güncellenemez. Bununla birlikte, hâlâ yaygın olarak kullanılan çoğu Android sürümünde mevcut güvenilir kök sertifika grubunun, mevcut cihazların çoğunun etkili kullanım ömrünün ötesinde, birkaç yıl boyunca kesintisiz hizmet sağlaması muhtemeldir.
Android 7.0'dan itibaren uygulama geliştiricilere, yalnızca kendi uygulamaları tarafından güvenilen güvenilir sertifikalar eklemek için güvenli bir yöntem sunar. Bu işlem, Güvenlik ve Gizlilik için Android En İyi Uygulamaları Ağ Güvenliği Yapılandırması eğitim dokümanında açıklandığı gibi, sertifikalar uygulamayla paket haline getirilerek ve özel bir ağ güvenliği yapılandırması oluşturularak gerçekleştirilir.
Ancak üçüncü taraf uygulama geliştiriciler, Google Play Hizmetleri APK'sından gelen trafiğin ağ güvenliği yapılandırmasını etkileyemeyecekleri için bu tür çabalar muhtemelen yalnızca kısmi bir geçici çözüm sunacaktır.
Daha eski eski cihazlarda kullanabileceğiniz tek seçenek, kullanıcılar tarafından eklenen CA'ları kullanmak olacaktır. Bu CA'lar, son kullanıcı cihazına uygulanan bir kurumsal grup politikası tarafından veya son kullanıcıların kendileri tarafından yüklenmiştir.
iOS Trust Store
Apple, varsayılan güvenilir kök sertifika grubunu doğrudan cep telefonu kullanıcısına göstermese de şirket, Apple Destek makalelerinde iOS 5 ve sonraki sürümler için güvenilir kök CA gruplarının bağlantılarını paylaşmaktadır:
- iOS 12.1.3, macOS 10.14.3, watchOS 5.1.3 ve tvOS 12.1.2'deki kullanılabilir güvenilir kök sertifikalarının listesi
- iOS 5 ve iOS 6: Kullanılabilir güvenilir kök sertifikaların listesi.
Ancak iOS cihaza yüklenen ek sertifikalar Ayarlar > Genel > Profil bölümünde görünür. Ek sertifika yüklenmemişse Profil menü öğesi gösterilmeyebilir.
Bu tabloda, yukarıdaki kaynaklara göre iOS sürümüne göre en önemli kök sertifikalarının kullanılabilirliği gösterilmektedir:
iOS sürümü | GTS Root R1 | GlobalSign Kök CA - R1 | GlobalSign Root R2 (15 Aralık 2021'e kadar geçerli) |
---|---|---|---|
5, 6, 7, 8, 9, 10, 11, 12.0 | |||
12.1.3 ve sonraki sürümler |
Sistem kök sertifikalarım nerede saklanıyor ve bunu nasıl güncelleyebilirim?
Varsayılan kök sertifika deposunun konumu, işletim sistemine ve kullanılan SSL/TLS kitaplığına göre değişir. Ancak çoğu Linux dağıtımında varsayılan kök sertifikalar aşağıdaki yöntemlerden birinin altında bulunabilir:
/usr/local/share/ca-certificates
: Debian, Ubuntu, eski RHEL ve CentOS sürümleri/etc/pki/ca-trust/source/anchors
ve/usr/share/pki/ca-trust-source
: Fedora, daha yeni RHEL ve CentOS sürümleri/var/lib/ca-certificates
: OpenSUSE
Diğer sertifika yolları şunları içerebilir:
/etc/ssl/certs
: Debian, Ubuntu/etc/pki/tls/certs
: RHEL, CentOS
Bu dizinlerdeki sertifikalardan bazıları muhtemelen diğer dizinlerdeki dosyalara yönelik sembolik bağlantılardır.
OpenSSL kök sertifika deposu
OpenSSL kullanan uygulamalarda, varsayılan kök sertifika deposu da dahil olmak üzere yüklü bileşenlerinin yapılandırılmış konumunu aşağıdaki komutu kullanarak kontrol edebilirsiniz:
openssl version -d
Bu komut, kitaplığın ve yapılandırmalarının bulunduğu üst düzey dizine karşılık gelen OPENSSLDIR
çıktısını verir:
OPENSSLDIR: "/usr/lib/ssl"
Kök sertifika deposu, certs
alt dizininde bulunur.
ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21 2020 /usr/lib/ssl/certs -> /etc/ssl/certs
ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01 ca-certificates.crt
…
lrwxrwxrwx 1 root root 50 Apr 15 16:57 GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…
OpenSSL, yukarıdaki örnekte olduğu gibi varsayılan sistem kök sertifika deposuna dayanıyorsa sistem kök sertifika paketinin güncel olduğundan emin olmak için Sistem kök sertifikalarım nerede depolanıyor ve bunu nasıl güncelleyebilirim? adlı üst düzey bölümüne göz atın.
openssl
'yi edinme talimatları için OpenSSL'i edinme bölümüne bakın.
Java kök sertifika deposu
Java uygulamaları, kendi kök sertifika depolarını kullanabilir. Bu depo, Linux sistemlerinde genellikle /etc/pki/java/cacerts
veya /usr/share/ca-certificates-java
konumundadır ve Java keytool
komut satırı aracı kullanılarak yönetilebilir.
Java sertifika deponuza tek bir sertifika aktarmak için aşağıdaki komutu verin:
keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks
cert.pem
değerini, önerilen her kök sertifikaya karşılık gelen sertifika dosyasıyla, alias
değerini benzersiz ancak anlamlı bir sertifika takma adıyla ve certs.jks
değerini ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirmeniz yeterlidir.
Daha fazla bilgi için aşağıdaki Oracle ve Stack Overflow makalelerini inceleyebilirsiniz:
- Java Platform, Standart Sürüm Araçları Referansı: keytool
- Varsayılan java yüklemesinin cacerts dosyasının konumunu nasıl öğrenebilirim?
- Varsayılan olarak tüm Java uygulamalarının kullanabileceği bir kendinden imzalı sertifikayı Java anahtar deposuna nasıl düzgün bir şekilde aktarabilirim?
Mozilla NSS kök sertifika deposu
Mozilla NSS kullanan uygulamalar da varsayılan olarak, genellikle /etc/pki/nssdb
adresinde bulunan, sistem genelinde bir sertifika veritabanını veya ${HOME}/.pki/nssdb
altındaki kullanıcıya özel bir varsayılan depoyu kullanabilir.
NSS veritabanınızı güncellemek için certutil
aracını kullanın.
Tek bir sertifika dosyasını NSS veritabanınıza aktarmak için aşağıdaki komutu girin:
certutil -A -t "C,," -i cert.pem -n cert-name -d certdir
cert.pem
değerini, önerilen her kök sertifikaya karşılık gelen sertifika dosyasıyla, cert-name
değerini anlamlı bir sertifika takma adıyla ve certdir
değerini ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir.
Daha fazla bilgi için lütfen resmi NSS Tools certutil kılavuzuna ve işletim sistemi belgelerinize bakın.
Microsoft .NET kök sertifikaları deposu
Windows .NET geliştiricileri, kök sertifika depolarını güncellemek için aşağıdaki Microsoft makalelerinden en az birini faydalı bulabilir:
Sertifika dosyası biçimleri
PEM dosyası nedir?
Privacy-Enhanced Mail (PEM), RFC 7468'de yasal standart olarak resmileştirilen kriptografik sertifikaları, anahtarları vb. depolamak ve göndermek için de facto standart bir metin dosyası biçimidir.
Dosya biçiminin kendisi insan tarafından okunabilse de Base64 kodlamalı ikili sertifika veri bilgileri değildir. Bununla birlikte, PEM spesifikasyonu, metin kodlamalı sertifika gövdesinden önce veya sonra açıklayıcı metin yayınlanmasına izin verir ve birçok araç, bir sertifikadaki en alakalı veri öğelerinin açık metin özetini sağlamak için bu özelliği kullanır.
openssl
gibi araçlar, sertifikanın tamamını insan tarafından okunabilir bir biçime dönüştürmek için de kullanılabilir. Daha fazla bilgi için PEM sertifikalarını kullanıcı tarafından okunabilir biçimde yazdırma bölümüne bakın.
".crt" dosyası nedir?
Sertifikaların PEM biçiminde dışa aktarılmasına izin veren araçlar, dosyanın metin kodlaması kullandığını belirtmek için yaygın olarak ".crt" dosya uzantısını kullanır.
DER dosyası nedir?
Ayırt Edici Kodlama Kuralları (DER), kodlama sertifikaları için standartlaştırılmış bir ikili program biçimidir. PEM dosyalarındaki sertifikalar genellikle Base64 olarak kodlanmış DER sertifikalarıdır.
".cer" dosyası nedir?
".cer" son eki içeren dışa aktarılan bir dosya, PEM kodlu bir sertifika içerebilir ancak genellikle ikili, genellikle DER kodlu bir sertifika içerir. Gelenek gereği, ".cer" dosyaları genellikle yalnızca tek bir sertifika içerir.
Sistemim roots.pem'deki tüm sertifikaları içe aktarmayı reddediyor
Bazı sistemler (ör. Java keytool
, birden fazla sertifika içerse bile PEM dosyasından yalnızca tek bir sertifika içe aktarabilir. Dosyanın ilk olarak nasıl bölünebileceğini görmek için roots.pem'den sertifikaları tek tek nasıl çıkarabilirim? sorusuna bakın.
roots.pem dosyasından tek tek sertifikaları nasıl ayıklayabilirim?
Aşağıdaki basit bash komut dosyasını kullanarak roots.pem
öğesini bileşen sertifikalarına bölebilirsiniz:
csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done
Bu işlemin sonucunda, burada listelenenlere benzer bir dizi bağımsız PEM dosyası oluşturulur:
ls -l *.pem
-rw-r----- 1 <user> <group> 2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group> 1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group> 1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group> 2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group> 1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group> 1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group> 1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group> 1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group> 1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group> 1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group> 2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group> 1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group> 1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group> 1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group> 1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group> 2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group> 1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group> 2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group> 2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group> 1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group> 1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group> 1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group> 1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group> 1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group> 1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group> 2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group> 1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group> 1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group> 2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group> 1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group> 2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group> 2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group> 1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group> 1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group> 1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group> 1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group> 1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group> 1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group> 2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem
Daha sonra 02265526.pem
gibi tek PEM dosyaları ayrı olarak içe aktarılabilir veya sertifika deponuzun kabul ettiği bir dosya biçimine de dönüştürülebilir.
PEM dosyası ile sistemim tarafından desteklenen bir biçim arasında dönüştürme
OpenSSL araç seti komut satırı aracıopenssl
, yaygın olarak kullanılan tüm sertifika dosyası biçimleri arasında dosya dönüştürmek için kullanılabilir. PEM dosyasını en yaygın sertifika dosyası biçimlerine dönüştürme talimatları aşağıda verilmiştir.
Kullanılabilir seçeneklerin tam listesi için resmi OpenSSL Komut Satırı Yardımcı Programları dokümanlarına bakın.
openssl
ile ilgili talimatlar için OpenSSL'yi Öğrenme bölümüne bakın.
Bir PEM dosyasını DER biçimine nasıl dönüştürebilirim?
openssl
kullanarak bir dosyayı PEM'den DER'ye dönüştürmek için aşağıdaki komutu yayınlayabilirsiniz:
openssl x509 -in roots.pem -outform der -out roots.der
PEM dosyasını PKCS #7'ye nasıl dönüştürebilirim?
Bir dosyayı PEM'den PKCS'ye dönüştürmek için openssl
kullanarak aşağıdaki komutu yayınlayabilirsiniz:
openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Bir PEM dosyasını PKCS #12'ye (PFX) nasıl dönüştürebilirim?
openssl
kullanarak bir dosyayı PEM'den PKCS #12'ye dönüştürmek için aşağıdaki komutu verebilirsiniz:
openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys
PKCS #12 arşivi oluştururken bir dosya şifresi sağlamanız gerekir. PKCS #12 dosyasını sisteminize hemen aktarmayacaksanız şifreyi güvenli bir yerde saklayın.
Kök sertifika deponuzdaki sertifikaları listeleme, yazdırma ve dışa aktarma
Java Anahtar Deposu'ndan bir sertifikayı PEM dosyası olarak nasıl dışa aktarabilirim?
keytool
yardımıyla, sertifika deponuzdaki tüm sertifikaları ve sertifikaları dışa aktarmak için kullanabileceğiniz takma adı listelemek üzere aşağıdaki komutu yayınlayabilirsiniz:
keytool -v -list -keystore certs.jks
certs.jks
dosyasını, ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirmeniz yeterlidir. Bu komut, dışa aktarmak istiyorsanız ihtiyacınız olacak her sertifikanın takma adını da gösterir.
Bir sertifikayı PEM biçiminde dışa aktarmak için aşağıdaki komutu kullanın:
keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem
Bunun için certs.jks
değerini, ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirin ve dışa aktarmak istediğiniz sertifikaya karşılık gelen bir alias
ve alias.pem
sağlayın.
Daha fazla bilgi için lütfen Java Platform, Standard Edition Tools Reference: keytool (Java Platformu, Standart Sürüm Araçları Referansı: keytool) kılavuzunu inceleyin.
NSS kök sertifikalarındaki sertifikaları PEM dosyası olarak nasıl dışa aktarırım?
certutil
yardımıyla, sertifika deponuzdaki tüm sertifikaları ve her birini dışa aktarmak için kullanabileceğiniz takma adı listelemek üzere aşağıdaki komutu düzenleyebilirsiniz:
certutil -L -d certdir
certdir
değerini, ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir. Bu komut, her sertifikanın takma adını da gösterir. Sertifikayı dışa aktarmak isterseniz bu takma adını kullanmanız gerekir.
Tek bir sertifikayı PEM biçiminde dışa aktarmak için aşağıdaki komutu verin:
certutil -L -n cert-name -a -d certdir > cert.pem
certdir
öğesini, ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz ve dışa aktarmak istediğiniz sertifikaya karşılık gelen bir cert-name
ve cert.pem
sağlamanız yeterlidir.
Daha fazla bilgi için lütfen resmi NSS Tools certutil kılavuzuna ve işletim sistemi belgelerinize bakın.
PEM sertifikalarını insanlar tarafından okunabilecek şekilde yazdırma
Aşağıdaki örneklerde, aşağıdaki içeriklere sahip GTS_Root_R1.pem
adlı bir dosyanız olduğunu varsayıyoruz:
# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
OpenSSL kullanarak sertifika dosyalarını yazdırma
Komutu verme
openssl x509 -in GTS_Root_R1.pem -text
şuna benzer bir çıkış verir:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
Signature Algorithm: sha384WithRSAEncryption
Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
Validity
Not Before: Jun 22 00:00:00 2016 GMT
Not After : Jun 22 00:00:00 2036 GMT
Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
…
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
Signature Algorithm: sha384WithRSAEncryption
…
openssl
ile ilgili talimatlar için OpenSSL'yi Öğrenme bölümüne bakın.
Java Keytool'u kullanarak sertifikaları yazdırma
Aşağıdaki komutu verme
keytool -printcert -file GTS_Root_R1.pem
şuna benzer bir sonuç vermelidir:
Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48 27 85 2F 52 66 2C EF F0 ..+&q.+H'./Rf,..
0010: 89 13 71 3E ..q>
]
]
keytool
ile ilgili talimatlar için Java keytool'u alma bölümüne bakın.
Kök sertifika depoma hangi sertifikaların yüklü olduğunu nasıl görebilirim?
Bu durum, işletim sistemine ve SSL/TLS kitaplığına göre değişir. Ancak kök sertifika deposuna sertifika içe ve dışa aktarma olanağı tanıyan araçlar genellikle yüklü sertifikaları listeleme seçeneği de sunar.
Ayrıca, güvenilir kök sertifikaları PEM dosyalarına başarıyla dışa aktardıysanız veya kök sertifika deponuzda zaten depolanan PEM dosyaları varsa dosyaları düz metin dosyası biçiminde olduğundan herhangi bir metin düzenleyicide açmayı deneyebilirsiniz.
PEM dosyası, ilişkili sertifika yetkilisinin okunabilir bilgilerini sağlayarak düzgün bir şekilde etiketlenebilir (güvenilir Google kök CA paketinden örnek olarak):
# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
Dosya, yalnızca sertifika bölümünü de içerebilir. Bu tür durumlarda, GTS_Root_R1.pem
gibi dosya adı, sertifikanın hangi CA'ya ait olduğunu belirtebilir. -----BEGIN CERTIFICATE-----
ile -----END CERTIFICATE-----
jetonları arasındaki sertifika dizesinin de her CA için benzersiz olacağı garanti edilir.
Bununla birlikte, yukarıdaki araçlara sahip olmasanız bile, güvenilir Google kök CA paketindeki her sertifika doğru şekilde etiketlendiğinden, kök sertifika deponuzdaki kök CA'ları, Issuer
tarihine kadar veya PEM dosya sertifikası dizelerini karşılaştırarak güvenilir bir şekilde eşleştirebilirsiniz.
Web tarayıcıları, kendi kök sertifika depolarını veya işletim tarafından sağlanan varsayılan sertifika deposunu kullanabilir. Ancak tüm modern tarayıcılar, güvendikleri kök CA grubunu yönetmenize veya en azından görüntülemenize olanak tanımalıdır. Daha fazla ayrıntı için JavaScript uygulamaları bozulma riski var mı? sorusuna bakın.
Cep telefonuna özgü talimatlar için Cep telefonumda güvenilir kök sertifikaları nasıl kontrol edebilirim? başlıklı ayrı soruya bakın.
Ek
Daha fazla bilgiye mi ihtiyacınız var?
Her zaman öncelikle işletim sisteminizin dokümanlarını, uygulamanızın programlama dilinin dokümanlarını ve uygulamanızın kullandığı harici kitaplıkların dokümanlarını kullanın.
Bu SSS dahil diğer herhangi bir bilgi kaynağı eski veya başka bir şekilde yanlış olabilir ve yetkili olarak kabul edilmemelidir. Bununla birlikte, Stack Exchange soru-cevap topluluklarının çoğunda, AdamW on Linux and more gibi sitelerde ve confirm blog gibi diğer kaynaklarda faydalı bilgiler bulabilirsiniz.
Lütfen Google Trust Services ile ilgili SSS bölümünü de inceleyin.
Sertifika sabitleme gibi ileri düzey konular hakkında daha fazla bilgi edinmek için Open Web Application Security Project (OWASP) Sertifika ve Herkese Açık Anahtar Sabitleme makalesini ve Sabitleme Kılavuzu'nu inceleyebilirsiniz. Android'e özel talimatlar için lütfen resmi Güvenlik ve Gizlilik İçin Android En İyi Uygulamaları HTTPS ve SSL ile Güvenlik eğitim belgesine bakın. Android'de sertifika ve ortak anahtar sabitleme hakkında bilgi edinmek için Matthew Dolan'ın Android Güvenlik: SSL Sabitleme başlıklı blog yayınını inceleyebilirsiniz.
Android Güvenlik ve Gizlilik İçin En İyi Uygulamalar Ağ Güvenliği Yapılandırması eğitim belgesi ve JeroenHD'nin Android 7 Nougat ve sertifika yetkilileri blog yayını, Android'de ek güvenilir sertifikaları yönetme hakkında daha fazla bilgi sağlar.
AOSP'nin güvendiği kök CA'ların kapsamlı listesi için ca-certificates Git deposuna bakın. Resmi olmayan Android çatallarına dayalı sürümler (ör. LineageOS) için OS tedarikçisi tarafından sağlanan uygun depoları inceleyin.