Google Haritalar Platformu Kök CA Taşıma Hakkında SSS

Bu doküman aşağıdaki bölümleri içerir:

Devam eden Google kök CA taşıma işlemi hakkında daha ayrıntılı bir genel bakış için Neler oluyor? sayfasını 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 Güven Hizmetleri Hakkında SSS sayfasına bakın.

SSL/TLS Sertifikası
Sertifika, şifreleme anahtarını bir kimliğe bağlar.
SSL/TLS sertifikaları, kimlik doğrulaması yapmak ve web siteleriyle güvenli bağlantılar kurmak için kullanılır. Sertifikalar, Sertifika Yetkilileri olarak bilinen tüzel kişiler tarafından verilir ve kriptografik olarak imzalanır.
Tarayıcılar, iletilen bilgilerin doğru sunucuya gönderildiğini ve aktarım sırasında şifrelendiğini bilmek için güvenilir Sertifika Yetkilileri tarafından verilen sertifikalara güvenir.
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 olarak 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 bürosu gibidir. Bir varlığın (ör. web sitesi) olduğunu iddia ettiği kişi olduğunu onaylamak için kriptografik olarak korunan belgeler (sertifikalar) düzenler.
CA'lar, sertifika vermeden önce Sertifika'daki adların istekte bulunan kişi veya tüzel kişiyle bağlantılı 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 deposunda, bir Uygulama Yazılımı Tedarikçisi'nin güvendiği bir dizi Sertifika Yetkilisi bulunur. Çoğu web tarayıcısının ve işletim sisteminin kendi kök sertifika deposu vardır.
Bir kök sertifika deposuna dahil edilmek için Sertifika Yetkilisi, Uygulama Yazılımı Tedarikçisi tarafından belirtilen katı şartları karşılamalıdır.
Bunlar genellikle CA/Tarayıcı Forumu gereksinimleri gibi endüstri standartlarına uygunlukla ilgilidir.
Kök Sertifika Yetkilisi
Kök Sertifika Yetkilisi (veya daha doğrusu sertifikası), bir 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ı), bir 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'lar olarak da bilinir.
Sertifikayı Veren 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 sertifikaya genellikle abone sertifikası, son varlık sertifikası veya yaprak sertifikası denir. 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 yaprak sertifikadan, tüm sertifikayı veren sertifikalarından ve bir kök sertifikadan oluşur.
Çapraz imza
Uygulama Yazılımı Tedarikçileri'nin müşterileri, ürünlerinin güvenilir kabul edilmesi için kök sertifika depolarını yeni CA sertifikaları 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 ve oluşturulan başka 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 GMO GlobalSign'dan satın alınmış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 sona erdiğinde Google, Google'ın 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 müşterileri bu güvenilir kök CA'lardan birini (veya her ikisini birden) zaten tanır ve taşımanın 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 platformlar çalıştırıyor ve/veya kendi kök sertifika depolarını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

Yukarıdaki durum geçerliyse taşımanın bu aşamasında Google Haritalar Platformu'nun kesintisiz şekilde kullanımını sağlayabilmek için müşterilerinizin ö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 gerektiğ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 bunlar ö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 alırım? 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 (GS Root R2) duyurulduğu gibi, Google Haritalar Platformu'nun 2018 başından beri kullandığı kök CA, 15 Aralık 2021'de sona erecek. Bu nedenle Google, bu yıl içinde yeni yayınlanan bir CA GTS Root R1 Cross'a geçiş yapacaktır. Bu, hizmetlerimizin bu yeni CA tarafından yayınlanan TLS yaprak sertifikalarına kademeli olarak geçeceği anlamına gelir.

Neredeyse tüm modern TLS istemcileri ve sistemleri, GTS Root R1 sertifikasıyla önceden yapılandırılmıştır veya bu sertifikayı normal yazılım güncellemeleriyle almalıdır. GlobalSign Root CA - R1 ise daha eski eski sistemlerde bile bulunabilir.

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ışıyor ve/veya kendi kök sertifika depolarını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.

Tüm ayrıntılar için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize etmeliyim? sorusuna göz atın.

Bu taşıma aşamasıyla ilgili güncellemeleri nasıl alabilirim?

Güncellemeler için 186840968 numaralı herkese açık soruna yıldız ekleyin. Bu SSS, taşıma süreci boyunca, genel olarak ilgilendirebilecek konularla karşılaştığımızda da güncellenir.

Gelecekteki taşıma işlemleri hakkında nasıl önceden bildirim alabilirim?

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 hepsini 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:

Aşağıdaki durumlarda sisteminiz genellikle 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 etkilenebilecek müşteriler, gelecekte hizmet kesintilerini önlemek için sertifikaları güvenilir Google kök CA paketinden hemen yüklemelidir.

Tüm ayrıntılar için Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize etmeliyim? sorusuna göz atı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 ile ilgili talimatlar için aşağıdaki Büyütme 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. Önceki bir sürümü kullanıyorsanız bu komutları sürümünüz için gerektiği şekilde yükseltin veya değiştirin. openssl'i edinmeyle ilgili talimatlar için aşağıdaki OpenSSL'yi Edinme bölümüne bakın.

Ayrıca, aşağıdaki İhtiyaç duyduğum araçları nereden edinebilirim? bölümünde başka yararlı araçlar da 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.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.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

Google kök CA taşıma işlemi nasıl ve ne zaman devam edecek?

  1. 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ı.
  2. İkinci aşama (GTS Root R1 Cross'a taşıma) Mart 2021'de duyuruldu ve önümüzdeki aylarda, GS Root R2'nin 15 Aralık 2021'deki süresinin dolmasından önce kullanıma sunulacak.

İlerideki nihai taşıma aşamalarının planları, sertifika geçerlilik sürelerinin sona ermesinden çok önceden 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ı

  1. Aşamalı sunum, tek bir veri merkezinde başlar.
  2. Kullanıma sunma süreci, küresel çapta kapsama alınana kadar kademeli olarak daha fazla veri merkezine genişletilir.
  3. Herhangi bir aşamada ciddi sorunlar tespit edilirse sorunlar giderilirken testler geçici olarak geri çekilebilir.
  4. Ö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 merkezleri taşındıkça gittikçe artan sayıda Google Haritalar Platformu geliştiricisi yeni sertifikaları almaya başlayacaktır. İstemci istekleri, coğrafi olarak yakındaki veri merkezlerindeki sunuculara yönlendirilme eğiliminde olduğundan, değişiklikler biraz yerelleştirilmiş olacaktır.

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.

Ek bilgi için Kök sertifika depomun güncellenmesi gerektiğini doğrulama 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.

TLS yapılandırmasına bağlı olarak istemciler Google Haritalar Platformu isteği göndermeye devam edebilir veya isteği yerine getirmeyi reddedebilir.

TLS istemcisinin Google Haritalar Platformu ile iletişim kurabilmesi için minimum gereksinimler nelerdir?

Google Haritalar Platformu sertifikaları, DNS Özne Alternatif Adları (SAN'ler) kullanır. Bu nedenle, müşterinin sertifika işlemesinin, adında en soldaki etiket olarak tek bir joker karakter (*.googleapis.com gibi) bulunabilen SAN'leri destekleyebilmesi gerekir.

Diğer koşullar için lütfen GTS SSS sayfasının TLS istemcisinin Google ile iletişim kurması için önerilen koşullar nelerdir? bölümüne bakın.

Ne tür uygulamaların bozulma riski var?

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 (ö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. Bununla birlikte, kök sertifika deponuzda büyük olasılıkla GlobalSign Root CA - R1 bulunur. Bu, en eski ve en yaygın şekilde güvenilen kök CA'lardan biridir.

Google Haritalar Platformu web hizmetlerini doğrudan son kullanıcı cihazından çağıran mobil uygulamalar için Mobil uygulamalar bozulma 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 fazla ayrıntı 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 uygulamalarda, 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ır veya sertifika sabitleme gibi gelişmiş güvenlik özelliklerini kullanır

Sertifika paketinizi kendiniz güncellediğinizden emin olmanız gerekir. Soru altında açıklandığı gibi,Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize etmeliyim? güvenilir Google kök CA paketindeki tüm sertifikaları kendi kök sertifika deponuza 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 etmeliyim?

Güvenilir Google kök CA paketindeki kök CA'lardan oluşan özel olarak seçilmiş listede, yakın gelecekte Google hizmetleri tarafından kullanılabilecek tüm CA'lar yer alır.

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 durum özellikle hizmetleriniz bakımsız bir işletim sistemi sürümünde çalışıyorsa, başka nedenlerden dolayı işletim sisteminize ve kitaplıklarınıza yama uygulanamıyorsa ya da kendi kök sertifika deponuzu kullanıyorsanı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 hizmetlerinizin hem GTS Root R1 Cross hem de GlobalSign Root CA - R1 geçerlilik süresi sona erene kadar çalışmaya devam etmesini sağlar.

Ayrıca, şu soruya bakın: 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 herhangi bir yaprak veya ara CA sertifikası yüklemeliyim?

Bunu yapmak, yeni bir sertifika kaydı yaptığımız veya ara CA'ları değiştirdiğimiz herhangi bir noktada uygulamanızın bozulması riskini doğurur. Bu ikisinden herhangi biri, önceden haber verilmeksizin herhangi bir zamanda gerçekleşebilir ve maps.googleapis.com tarafından sunulanlar gibi bağımsız sunucu sertifikaları ile GTS Root R1 Cross gibi ara CA'larımızın herhangi biri için eşit şekilde geçerlidir.

Hizmetlerinizi buna karşı korumak için yalnızca güvenilir Google kök CA paketinden kök sertifikalar yüklemeniz ve bu pakete bağlı sertifika zincirinin tamamının güvenilirliğini doğrulamak amacıyla yalnızca kök sertifikadan yararlanmanı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 konum her tarayıcı için farklılık gösterse de sertifikaların listesi genellikle Ayarlar altında bir yerde bulunabilir.

Mobil uygulamalar bozulma riskiyle karşı karşıya mı?

Üreticiden düzenli olarak güncelleme alan Android ve Apple iOS cihazların da geleceğe hazır olmaları beklenir. Eski Android telefon modellerinin çoğu en azından GlobalSign Root CA - R1 sertifikasını içerir. Ancak güvenilir sertifikaların listesi mobil cihaz üreticisi, cihaz modeli ve Android sürümüne göre değişiklik gösterebilir.

Ancak GTS Root R1 de dahil olmak üzere GTS kök CA'ları için destek, 10 öncesi Android sürümlerinde sınırlı olabilir.

Apple, iOS cihazlar için destek sayfalarında, her yeni iOS sürümü için güvenilir kök CA'ların bir listesini tutar. Ancak tüm iOS 5 ve sonraki 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 Cep telefonumda güvenilir kök sertifikaları nasıl kontrol edebilirim? sorusuna 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 paketlerine sahip tüm büyük üçüncü taraflarla yoğun bir şekilde çalışmıştır. Apple ve Microsoft gibi işletim sistemi üreticileri, Google'ın kendi Android ve Chrome OS ekipleri; Mozilla, Apple, Microsoft gibi tarayıcı geliştiricileri, aynı zamanda Google'ın kendi Chrome ekibi; telefon, set üstü kutu, TV, oyun konsolu, yazıcı gibi donanım üreticileri de buna örnek olarak verilebilir.

Bu nedenle, bakımda olan herhangi bir sistemin, GTS Root R1 dahil olmak üzere Google'ın yeni GTS Kök CA'larını desteklemesi çok olasıdır. Eski sistemlerin bile, önümüzdeki yıllarda Google tarafından verilen sertifikaların çapraz imzalanması için kullanılacak olan GlobalSign Root CA - R1'i desteklemesi çok 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 sistemi dağıtımınız curl sağlamıyorsa https://curl.haxx.se/ adresinden indirebilirsiniz. Kaynağı indirip aracı kendiniz derleyebilir veya platformunuz için mevcutsa önceden derlenmiş bir ikili program indirebilirsiniz.

OpenSSL'yi alma

OS dağıtımınız openssl sağlamıyorsa kaynağı https://www.openssl.org/ adresinden indirebilir ve aracı derleyebilirsiniz. Üçüncü taraflarca oluşturulan ikili programların listesini https://www.openssl.org/community/binaries.html adresinde bulabilirsiniz. Ancak bu derlemelerin hiçbiri OpenSSL ekibi tarafından desteklenmez veya belirli bir şekilde desteklenmez.

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 ile derlenmediği sürece kök sertifika doğrulaması için keytool kullanmak pek olası değildir.

Üretim kesintisinde 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.

  1. Yerel kök sertifika deponuzu yükseltmek için sistem yöneticilerinizle birlikte çalışın.
  2. Sisteminiz için geçerli olan işaretçiler için bu SSS'yi inceleyin.
  3. 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.
  4. 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ü sorunlarda yalnızca en iyi şekilde yol gösterilir.
  5. Taşımayla ilgili daha fazla güncelleme için herkese açık soruna (186840968) bakın.

Google Haritalar Platformu destek ekibiyle iletişime geçme

İlk sorun giderme

Genel sorun giderme talimatları için Kök sertifika depomun güncellenmesi gerektiğ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:

  1. Etkilenen sunucularınız nerede bulunuyor?
  2. Hizmetiniz hangi Google IP adreslerini arıyor?
  3. Hangi API'ler bu sorundan etkileniyor?
  4. Sorun tam olarak ne zaman başladı?
  5. Aşağıdaki komutların çıktıları:

    curl -vvI https://maps.googleapis.com; \
    openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr1.demo.pki.goog/; \
    openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr1x.demo.pki.goog/; \
    openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;
    

Gerekli araçlara erişme talimatları için İhtiyacım olan araçları nereden edinebilirim? sorusuna 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 kullanarak (ö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 alınan günlük alıntıları, TLS bağlantı hatasının nedenini (tercihen tam sunucu sertifikası zinciri bilgileriyle birlikte) gösterir.

Gerekli araçlara erişme talimatları için İhtiyacım olan araçları nereden edinebilirim? sorusuna bakın.

186840968 numaralı herkese açık sorunda yayınlanıyor

Herkese açık bir sorun hakkında (186840968) yorum yayınlarken lütfen İlk sorun giderme bölümünde listelenen bilgileri ekleyin.

DNS'imin herkese açık adresini nasıl belirleyebilirim?

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. Aşağıda, çıkışı yorumlamaya ilişkin birkaç talimat verilmiştir:

  • "*" ile başlayan satırlar, bağlantı sonlandırma bilgilerinin yanı sıra TLS anlaşmasındaki çıkışı da 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 varlığı, başarılı bir TLS el sıkışması olduğunu gösterir.

Kullanılan TLS kitaplığı ve kök sertifika paketi

curl öğesini -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.

NSS'ye bağlı curl ile Red Hat Linux makinesinden gelen çı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şaretini kullanarak verilen Google kök sertifikası PEM dosyasını kullanarak Ubuntu veya Debian Linux makinesinden gelen çı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 sisteminiz hakkında yararlı bilgiler sağlayabilecek User-Agent üstbilgisini 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ünen 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 listelenmelidir. Ayrıca > veya < ile başlayan satırların varlığı, yük HTTP trafiğinin TLS ile şifrelenmiş bağlantı üzerinden başarılı bir şekilde 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

Çıkışın PEM biçimli olduğunu varsayarsak (ör. openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null çıkışında) aşağıdaki adımları uygulayarak sunulan sertifikayı yazdırabilirsiniz:

  • Üstbilgi ve altbilgi dahil, Base 64 olarak kodlanmış sertifikanın tamamını kopyalayın:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • Daha sonra ş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.

Örneğin giriş ve çıkış için PEM sertifikalarını insanlar tarafından okunabilir biçimde yazdırma bölümüne bakın.

Çapraz imzalı Google sertifikaları OpenSSL'de nasıl görünür?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.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.demo.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

Güvenilir sertifikalarınızı yönetme

Cep telefonumda güvenilir kök sertifikaları nasıl kontrol edebilirim?

Android güvenilir sertifikaları

Soru altında belirtildiği gibi Mobil uygulamalar bozulma riski var mı?, Android'in 4.0 sürümünden itibaren, cihaz kullanıcılarının Ayarlar altındaki güvenilir sertifikaların listesini doğrulaması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 kullanılabilir olan Android Sanal Cihaz (AVD) sistem görüntülerinin kullanıldığı manuel doğrulama ve sistem görüntülerinin artık kullanılamadığı AOSP ca-certificates Git deposu sürüm geçmişi temelinde, Android sürümü başına en önemli kök sertifikaların olası kullanılabilirliği gösterilmektedir:

Android sürümü GTS Kök R1 GlobalSign Kök CA - R1 GlobalSign Root R2 (15 Aralık 2021'e kadar geçerli)
2,3, 3,2, 4,x, 5,x, 6,x, 7,x, 8,x, 9
10+

Android sistem kök sertifika deposunun güncellenmesi genellikle donanım yazılımı güncellemesi veya cihazı rootlama işlemi olmadan mümkün olmaz. 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.

7.0 sürümünden itibaren Android, uygulama geliştiricilerine yalnızca uygulamaları tarafından güvenilen güvenilir sertifikaları eklemeleri için güvenli bir yöntem sunmaktadır. Bu işlem, Android Güvenlik ve Gizlilik İçin Android En İyi Uygulamaları Ağ Güvenliği Yapılandırması eğitim dokümanında açıklandığı şekilde sertifikalar uygulamayla paket haline getirilerek ve özel bir ağ güvenliği yapılandırması oluşturularak gerçekleştirilir.

Bununla birlikte, üçüncü taraf uygulama geliştiricileri Google Play Hizmetleri APK'sından gelen trafiğin ağ güvenliği yapılandırmasını etkileyemeyeceğinden, bu tür çalışmalar büyük olasılıkla yalnızca kısmi bir geçici çözüm sağlayacaktı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 Güven Mağazası

Apple, varsayılan güvenilir kök sertifika grubunu mobil cihaz kullanıcısına doğrudan göstermese de şirket, Apple Destek makalelerinden iOS 5 ve sonraki sürümler için güvenilir kök CA gruplarının bağlantılarını bulundurmaktadır:

Ancak iOS cihaza yüklenen ek sertifikalar Ayarlar > Genel > Profil altında görünür olmalıdır. Ek sertifika yüklenmediyse Profil menü öğesi gösterilmeyebilir.

Bu tabloda, yukarıdaki kaynaklara göre iOS sürümü başına en önemli kök sertifikaların kullanılabilirliği gösterilmektedir:

iOS sürümü GTS Kök 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+

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 dosyaların sembolik bağlantılarıdı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 ile ilgili talimatlar için OpenSSL'yi Öğrenme bölümüne bakın.

Java kök sertifikaları deposu

Java uygulamaları kendi kök sertifika deposunu kullanabilir. Linux sistemlerinde, bu genellikle Java keytool komut satırı aracıyla yönetilebilen /etc/pki/java/cacerts veya /usr/share/ca-certificates-java konumunda bulunur.

Tek bir sertifikayı Java sertifika deponuza aktarmak için şu komutu verin:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

cert.pem kısmını önerilen her kök sertifikaya karşılık gelen sertifika dosyasıyla, alias değerini benzersiz ama anlamlı bir sertifika takma adıyla ve certs.jks değerini de 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:

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 verin:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

cert.pem öğesini, ö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 de 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, en azından aşağıdaki Microsoft makalelerinden kök sertifika depolarını güncelleme konusunda faydalı olabilir:

Sertifika dosya biçimleri

PEM dosyası nedir?

Gizlilik Açısından Geliştirilmiş Posta (PEM), kriptografik sertifikaların, anahtarların vb. saklanması ve gönderilmesi için kullanılan standart bir metin dosyası biçimidir. RFC 7468'de bu standart olarak düzenlenmiştir.

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.

Sertifikanın tamamını kullanıcıların okuyabileceği bir şekilde çözmek için openssl gibi araçlar da kullanılabilir. Daha fazla bilgi için PEM sertifikalarını insan tarafından okunabilecek şekilde 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 ekine sahip dışa aktarılan bir dosya, PEM kodlu bir sertifika içerebilir, ancak daha çok, genellikle DER kodlamalı bir ikili programdır. Kurala göre ".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, bir PEM dosyasından birden fazla sertifika içerse bile yalnızca tek bir sertifikayı 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'den sertifikaları tek tek nasıl çıkarabilirim?

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.

Bir PEM dosyası ile sistemim tarafından desteklenen bir biçim arasında dönüştürme

OpenSSL Araç Seti komut satırı aracı openssl, dosyaları yaygın olarak kullanılan tüm sertifika dosyası biçimleri arasında dönüştürmek için kullanılabilir. Bir PEM dosyasından en sık kullanılan sertifika dosyası biçimlerine dönüştürme talimatları aşağıda listelenmiş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
Bir 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 yayınlayabilirsiniz:

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 Mağazası'ndaki bir sertifikayı PEM dosyası olarak nasıl dışa aktarırım?

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.

Tek bir sertifikayı PEM biçiminde dışa aktarmak için aşağıdaki komutu verin:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

certs.jks öğesini, ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirmeniz ve dışa aktarmak istediğiniz sertifikaya karşılık gelen bir alias ve alias.pem sağlamanız yeterlidir.

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ılavuzuna bakın.

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 öğesini, ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir. Bu komut, her sertifikanın takma adını da gösterir ve dışa aktarmak istiyorsanız bu takma ada ihtiyacınız olacaktır.

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, GTS_Root_R1.pem dosyasının aşağıdaki içeriğe sahip 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

Komut verme

openssl x509 -in GTS_Root_R1.pem -text

şuna benzer bir sonuç vermelidir:

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 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, işletim sistemine ve SSL/TLS kitaplığına göre değişir. Ancak sertifikaların kök sertifika deposundan içe ve dışa aktarılmasına izin veren 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 izin vermelidir. 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 sistemi belgelerinize, uygulama programlama dillerinizin dokümanlarına ve uygulamanızın kullandığı harici kitaplıklardaki belgelere güvenin.

Bu SSS dahil diğer herhangi bir bilgi kaynağı eski veya başka bir şekilde yanlış olabilir ve yetkili olarak kabul edilmemelidir. Ancak Stack Exchange Soru-Cevap topluluklarının birçoğunun yanı sıra Linux'ta AdamW ve onaylama blogu gibi siteler hakkında daha da faydalı bilgiler bulabilirsiniz.

Lütfen Google Güven Hizmetleri ile ilgili SSS bölümünü de inceleyin.

Sertifika sabitleme gibi ileri düzey konular hakkında daha ayrıntılı bilgi için Open Web Application Security Project (OWASP) Certificate and Public Key Pinning makalesini ve Sabitleme Yardımcı Notlarını bilgi amaçlı bulabilirsiniz. Android'e özgü talimatlar için lütfen resmi Android En İyi Güvenlik ve Gizlilik Uygulamaları HTTPS ve SSL ile Güvenlik eğitim dokümanına bakın. Android'de sertifika ve ortak anahtar sabitleme arasındaki farklar için, Matthew Dolan'ın Android Güvenliği: SSL Sabitleme blog yayınını faydalı bulabilirsiniz.

Güvenlik ve Gizlilik İçin Android En İyi Uygulamaları Ağ Güvenliği Yapılandırması eğitim dokümanı ve JeroenHD'nin blog yayını Android 7 Nougat ve sertifika yetkilileri, 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 çatallara (ör. LineageOS) dayalı sürümler için işletim sistemi tedarikçisinin sağladığı uygun depolara bakın.