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şlemiyle ilgili daha ayrıntılı bir genel bakış için Neler oluyor? sayfasını inceleyin.

Terminoloji

Bu belge için bilmeniz gereken en önemli terimlerin bir listesini aşağıda bulabilirsiniz. İlgili terminolojiye daha kapsamlı bir genel bakış için lütfen Google Trust Services SSS bölümüne bakın.

SSL/TLS Sertifikası
Sertifika, şifreleme anahtarını kimliğe bağlar.
SSL/TLS sertifikaları, web sitelerinin kimliğini doğrulamak ve 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 sertifikalardan yararlanır.
Güvenli Yuva Katmanı (SSL)
Güvenli Yuva Katmanı, internet iletişimlerini şifrelemek için kullanılan ve en yaygın olarak 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 almıştır.
Sertifika Yetkilisi (CA)
Sertifika Yetkilisi, cihazlar ve kişiler için dijital pasaport ofisi gibidir. Bir tüzel kişinin (ör. web sitesi) iddia ettiği kişi olduğunu kanıtlamak için kriptografik olarak korunan belgeler (sertifikalar) yayınlar.
Sertifika verilmeden önce, sertifikadaki adların, sertifikayı isteyen kişi veya tüzel kişiye ait olduğunu doğrulamaktan CA'lar 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çisinin güvendiği bir dizi Sertifika Yetkilisi içerir. Çoğu web tarayıcısının ve işletim sisteminin kendi kök sertifika deposu vardır.
Bir kök sertifika deposuna eklenmek için Sertifika Yetkilisi'nin Uygulama Yazılımı Tedarikçisi tarafından belirtilen katı şartları yerine getirmesi gerekir.
Genellikle bu gereksinimler arasında CA/Tarayıcı Forumu gereksinimleri gibi endüstri standartlarına uygunluk da bulunur.
Kök Sertifika Yetkilisi
Kök Sertifika Yetkilisi (veya daha doğru bir şekilde ifade etmek gerekirse sertifikası), sertifika zincirindeki en üst sertifikadır.
Kök CA sertifikaları genellikle kendinden imzalıdır. Bunlarla ilişkili özel anahtarlar son derece güvenli tesislerde saklanır ve yetkisiz erişime karşı korumak için çevrimdışı durumda tutulur.
Ara Sertifika Yetkilisi
Ara Sertifika Yetkilisi (veya daha doğru bir şekilde ifade etmek gerekirse sertifikası), bir sertifika zincirindeki diğer sertifikaları imzalamak için kullanılan bir sertifikadır.
Ara CA'lar esasen online sertifika vermeyi etkinleştirir ve kök CA sertifikasının çevrimdışı kalmasına izin verir.
Orta düzey CA'lar, ikincil CA'lar olarak da bilinir.
Sertifika Veren Sertifika Yetkilisi
Sertifikayı Veren Sertifika Yetkilisi veya daha doğru bir şekilde ifade etmek gerekirse sertifikası, bir sertifika zincirinde en alttaki sertifikayı imzalamak için kullanılan sertifikadır.
En altta yer alan bu sertifika genellikle abone sertifikası, son varlık sertifikası veya yaprak sertifikası olarak adlandırılır. Bu dokümanda ayrıca sunucu sertifikası terimini de kullanacağız.
Sertifika zinciri
Sertifikalar, veren kuruluşla bağlantılıdır (şifre, imzalayan tarafından). Sertifika zinciri bir yaprak sertifikadan, sertifikayı verenin tüm sertifikalarından ve bir kök sertifikadan oluşur.
Çapraz imzalama
Uygulama Yazılımı Tedarikçileri'nin müşterileri, ürünlerinin güvenilir olması 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.
Eski istemcilerle uyumluluğu artırmak için CA sertifikaları, yerleşik başka bir CA tarafından "çapraz imzalanabilir". Bu işlem, aynı kimlik (ad ve anahtar çifti) için etkili bir şekilde ikinci bir CA sertifikası oluşturur.
Kök sertifika depolarında yer alan CA'lara bağlı olarak istemciler, güvendikleri bir köke kadar farklı bir sertifika zinciri oluşturur.

Genel bilgiler

What is happening?

Büyük resim

Google, 2017 yılında HTTPS tarafından kullanılan TLS internet güvenliğinin temelini oluşturan 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. Google, kendi kendine verilen Google Trust Services (GTS) kök CA'larına geçişi kolaylaştırmak için bu hizmeti GMO GlobalSign'dan almıştır.

Neredeyse tüm TLS istemcileri (ör. web tarayıcıları, akıllı telefonlar ve uygulama sunucuları) bu kök sertifikaya güvenmiştir ve bu nedenle taşımanın ilk aşamasında Google Haritalar Platformu sunucularıyla güvenli bağlantı kurabilmiştir.

Bununla birlikte bir CA, yapısı 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 dolduğu için Google, kendi kök CA'sı GTS Root R1 tarafından verilen bir sertifikayı kullanarak kendi hizmetlerini yeni bir CA olan GTS Root R1 Cross'a taşıyacaktır.

Modern işletim sistemlerinin ve TLS istemci kitaplıklarının büyük çoğunluğu GTS kök CA'larına zaten güvense de Google, çoğu eski sistem için sorunsuz bir geçiş sağlamak amacıyla şu anda en eski ve en güvenilir kök CA'lardan biri olan GlobalSign Root CA - R1'i kullanarak GMO GlobalSign'dan bir çapraz imza edinmiştir.

Bu nedenle çoğu müşterinin Google Haritalar Platformu müşterileri, güvenilir kök CA'lardan birini (veya ikisini birden) zaten tanıyacak ve geçişin ikinci aşamasından hiçbir şekilde etkilenmeyecektir.

Bu durum, talimatlarımızı uyguladığı ve güvenilir Google kök CA paketimizdeki tüm sertifikaları yükleyerek 2018'deki taşıma sürecinin ilk aşamasında işlem yapan müşteriler için de geçerlidir.

Aşağıdakiler geçerliyse sistemlerinizi doğrulamanız gerekir:

  • hizmetlerinizin standart olmayan veya eski platformlarda çalışması ve/veya kendi kök sertifika depolama alanınızın
  • 2017-2018 yıllarında, Google'ın kök CA taşıma sürecinin ilk aşamasında herhangi bir işlem gerçekleştirmediyseniz veya güvenilir Google kök CA paketinden sertifika grubunun tamamını yüklemediyseniz

Yukarıdaki koşullar geçerliyse, taşımanın bu aşamasında Google Haritalar Platformu'nu kesintisiz olarak kullanabilmek için müşterilerinizin önerilen kök sertifikalarla güncellenmesi gerekebilir.

Daha fazla teknik ayrıntı 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 gelecekteki kök CA değişikliklerine karşı kanıtlamak için kök sertifika depolarınızı yukarıda seçilen kök CA paketiyle senkronize halde tutmaya devam etmenizi ö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 alabilirim? ve Gelecekteki taşıma işlemleriyle ilgili nasıl önceden bildirim alabilirim? bölümlerine göz atın.

Teknik özet

15 Mart 2021'de Google Güvenlik Blogu'nda GS Root R2 duyurulduğu üzere 2018'in başından bu yana kullanılan kök CA Google Haritalar Platformu'nun süresi 15 Aralık 2021'de dolacaktır. Bu nedenle Google, bu yıl boyunca yeni bir CA GTS Root R1 Cross'a geçiş yapacaktır. Bu, hizmetlerimizin bu yeni CA'nın yayınladığı TLS yaprak sertifikalarına kademeli olarak geçirileceği anlamına gelmektedir.

Neredeyse tüm modern TLS istemcileri ve sistemleri, GTS Root R1 sertifikasıyla önceden yapılandırılmıştır veya bu sertifikanın normal yazılım güncellemeleri aracılığıyla alınması gerekir. GlobalSign Root CA - R1 ise eski eski sistemlerde bile kullanılabilir.

Ancak aşağıdaki noktaların her ikisi de geçerliyse sistemlerinizi en azından doğrulamanız gerekir:

  • hizmetleriniz standart olmayan veya eski platformlarda çalışıyorsa ve/veya kendi kök sertifika deponuz
  • 2017-2018 yıllarında, Google'ın kök CA taşıma sürecinin ilk aşamasında herhangi bir işlem gerçekleştirmediyseniz veya güvenilir Google kök CA paketinden sertifika grubunun tamamını yüklemediyseniz

Kök sertifika depomun güncellenmesi gerekip gerekmediğini doğrulama bölümü, sisteminizin etkilenip etkilenmeyeceğini test etme konusunda genel bir yol gösterici bilgiler sağlar.

Tüm ayrıntılar için Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize halde tutmalıyım? sorusuna bakın.

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

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

Gelecekteki taşıma işlemleri için nasıl önceden bildirim alabilirim?

Google Güvenlik Blogu'nu takip etmenizi öneririz. Blogda yaptığımız duyurunun ardından ürüne özel dokümanları da en kısa sürede güncellemeye çalışacağız.

Daha fazla müşteriyi etkilemesi muhtemel değişiklikler hakkında forumda düzenli olarak güncelleme yayınlıyoruz. Lütfen Google Haritalar Platformu Bildirimleri'ne 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'lerde gerçekleşecek olsa da zaman çizelgesi hizmete göre değişiklik gösterebilir. Bununla birlikte, 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 bunların senkronize halde tutulması sizi gelecekteki kök CA değişikliklerine karşı da korur.

Daha fazla bilgi için Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize tutmalıyım? ve Hangi tür uygulamaların bozulma riski var? konularına göz atın.

Ayrıca, aşağıdaki Kök sertifika depomun güncellenmesinin gerekip gerekmediğini doğrulama bölümünde, sisteminizi test etmeye yönelik genel talimatlar sağlanmaktadır.

Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrularım?

Uygulama ortamınızı aşağıda listelenen test uç noktalarıyla 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 kullandığı kitaplıkları sakladıysanız ve kendi kök sertifika deponuza sahip değilseniz veya:
  • Önceki önerilerimizi uyguladınız ve tüm kök CA'ları güvenilir Google kök CA paketinden yüklediniz.
olumsuz etkilenebilir.

Muhtemelen etkilenen müşteriler, gelecekte hizmet kesintisi yaşamamak için güvenilir Google kök CA paketinden sertifikaları hemen yüklemelidir.

Tüm ayrıntılar için Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize halde tutmalıyım? sorusuna bakın.

Kök sertifika depomuzu doğrulamak için kullanabileceğim basit bir araç var mı?

İncelemelerinizde iki komut satırı aracı olan curl ve openssl işinize yarar. Her ikisi de çoğu platformda kullanılabilir ve kurulumunuzu test etmek için kapsamlı seçenekler sunar.

curl'ı alma talimatları için aşağıdaki Curl edinme 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. Eski bir sürüm kullanıyorsanız bu komutları kendi sürümünüz için gereken şekilde yükseltin veya değiştirin. openssl'yi edinmeyle ilgili talimatlar için aşağıdaki OpenSSL'yi Alma bölümüne bakın.

Ayrıca aşağıdaki İhtiyacım olan araçları nereden alabilirim? bölümünde daha fazla kullanışlı araç bulabilirsiniz.

Somut test talimatları için lütfen Kök sertifika depomun güncellenmesi gerekip gerekmediğ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 paketi doğrulanıyor

Güvenilir Google kök CA paketini indirin ve 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 eder?

  1. Ocak 2017'de duyurulan ilk aşama (GS Root R2'ye taşınma) 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 süresi 15 Aralık 2021'de sona ermeden önce gerçekleştirilecek.

Daha sonraki nihai taşıma aşamalarının zaman çizelgeleri, gelecekteki sertifika kullanımlarının geçerlilik bitiş tarihinden çok önceden duyurulacaktır.

Bununla birlikte, kök sertifikalarınızın depolanmasını, güvenilir Google kök CA paketinde yer alan kök CA'lar listesiyle senkronize ederseniz uygulamalarınızı geleceğe hazırlayabilirsiniz.

Daha fazla bilgi için Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize halde tutmalıyım? sorusuna da bakın.

Her bir Google hizmeti için genel kullanıma sunma planı

  1. Aşamalı sunum tek bir veri merkezinde başlar.
  2. Kullanıma sunma, küresel bir kapsama ulaşana kadar kademeli olarak daha fazla veri merkezine genişletilir.
  3. Herhangi bir aşamada ciddi sorunlar tespit edilirse, sorunlar ele alınırken testler geçici olarak geri alınabilir.
  4. Önceki iterasyonlardan gelen girdilere göre, tüm Google hizmetleri kademeli olarak yeni sertifikalara geçene kadar daha fazla Google hizmeti kullanıma sunmaya dahil edilecektir.

Kim, ne zaman ve nerede etkilenecek?

Yeni veri merkezleri taşındıkça Google Haritalar Platformu geliştiricilerinin sayısı da 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 bir şekilde yerelleştirilecek.

Kimin, ne zaman ve nerede etkileneceğini önceden kesin olarak söyleyemediğimizden, tüm müşterilerimizin, olası Google kök CA geçiş aşamalarından çok önce hizmetlerini doğrulamasını ve ileriye yönelik hazırlıklarını yapmasını öneririz.

Ek yardım için Kök sertifika depomun güncellenmesi gerekip gerekmediğ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ı verir.

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

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

Google Haritalar Platformu sertifikaları, DNS Konu Alternatif Adları (SAN) kullanır. Bu nedenle, bir istemcinin sertifika işlemesi, adında en soldaki etiket olarak tek bir joker karakter içerebilecek *.googleapis.com gibi SAN'leri destekleyebilmelidir.

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

Hangi uygulama türleri bozulma riskiyle karşı karşıyadır?

Uygulama, geliştiricinin uyguladığı kısıtlamalar olmadan sistem kök sertifika deposunu kullanır

Google Haritalar Platformu web hizmeti uygulamaları

Örneğin, ana akım bir işletim sistemi kullanıyorsanız 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 OS sürümünü kullanıyorsanız GTS Root R1 sertifikanız olabilir veya olmayabilir. Ancak kök sertifika deponuz büyük olasılıkla, en eski ve en çok güvenilen kök CA'lardan biri olan GlobalSign Root CA - R1'i içerecektir.

Google Haritalar Platformu web hizmetlerini doğrudan son kullanıcı cihazından arayan mobil uygulamalar için Mobil uygulamalar bozulma riski var mı? sorusunda belirtilen kurallar 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ı kullanır. Daha fazla ayrıntı için JavaScript uygulamalarının 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 uygulamalar için de aynı kurallar geçerlidir.

Daha fazla ayrıntı için Mobil uygulamaların bozulma riski var mı? sorusuna bakın.

Uygulama kendi sertifika paketini veya sertifika sabitleme gibi gelişmiş güvenlik özelliklerini kullanır

Sertifika paketinizi kendiniz güncellediğinizden emin olmanız gerekir. Şu soruda açıklandığı gibi: Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize halde tutmalıyım? 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 sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize halde tutmalıyım?

Güvenilir Google kök CA paketindeki seçili kök CA'lar listesi, yakın gelecekte Google hizmetleri tarafından kullanılabilecek tüm CA'ları içerir.

Bu nedenle, sisteminizi geleceğe hazırlamak istiyorsanız kök sertifika deponuzda paketteki tüm sertifikaların bulunduğunu doğrulamanızı ve bu ikisini senkronize durumda tutma alışkanlığı edinmenizi kesinlikle öneririz.

Bu, özellikle hizmetleriniz bakımsız bir işletim sistemi sürümü üzerinde çalışıyorsa, işletim sisteminize ve kitaplıklarınıza yama uygulanmış durumda tutamamanızın ya da kendi kök sertifika depolamanızın bakımını yapamamanızın başka nedenleri varsa önemlidir.

Gelecekteki kök CA taşıma işlemleri hakkında güncellemeleri nasıl alacağınızı öğrenmek için Gelecekteki taşıma işlemleri için nasıl önceden bildirim alabilirim? sorusuna bakın. Kök sertifika depolarınızı seçilen listeyle senkronize bir şekilde tutmak, hizmetlerinizi gelecekte CA değişikliklerinden kaynaklanabilecek hizmet kesintilerine karşı korur ve hem GTS Root R1 Cross hem de GlobalSign Root CA - R1 kullanım süresinin sona ermesinden sonra da hizmetlerinizin çalışmaya devam etmesini sağlar.

Ayrıca, lütfen şu soruya bakın: Google hizmetlerine bağlanan bir ürün geliştiriyorum. Hangi CA sertifikalarına güvenmem gerekir? konusunda daha fazla öneri için GTS SSS sayfasına bakın.

Neden hiçbir yaprak veya ara CA sertifikası yüklememeliyim?

Aksi takdirde, yeni bir sertifika kaydettiğimiz veya ara CA'ları değiştirdiğimiz herhangi bir noktada uygulamanızı ihlal etme riskiyle karşı karşıya kalabilirsiniz. Bunlardan herhangi biri, önceden bildirilmeksizin herhangi bir zamanda gerçekleşebilir ve maps.googleapis.com tarafından sunulanlar gibi bağımsız sunucu sertifikalarına ve GTS Root R1 Cross gibi ara CA'larımızın herhangi birine eşit şekilde uygulanır.

Hizmetlerinizi buna karşı korumak için yalnızca güvenilir Google kök CA paketinden kök sertifikalar yüklemelisiniz. Ayrıca, kendisine bağlı sertifika zincirinin tamamının güvenilirliğini doğrulamak için yalnızca kök sertifikaya güvenmeniz gerekir.

Tüm modern TLS kitaplığı uygulamaları, kök sertifika yetkilisine güvenildiği sürece bu tür güven zincirlerini otomatik olarak doğrulayabilmelidir.

JavaScript uygulamaları bozulma riskiyle karşı karşıya mıdır?

GTS kök sertifikaları, birçok modern tarayıcı tarafından zaten yerleştirilmiş ve güvenilir şekilde yerleştirilmiştir. GMO GlobalSign'ın çapraz imza özelliği, eski tarayıcılar kullanan çoğu son kullanıcı için bile sorunsuz bir taşıma süreci sağlar. 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 bunları düzenlemesine izin vermelidir. Tam konum her tarayıcıda farklılık gösterse de sertifikaların listesi genellikle Ayarlar'ın altında bir yerde bulunur.

Mobil uygulamaların bozulma riski var mı?

Cihaz üreticisinden düzenli güncellemeler almaya devam eden Android ve Apple iOS cihazların da geleceğe hazır olması bekleniyor. Eski Android telefon modellerinin çoğunda en azından GlobalSign Root CA - R1 sertifikası bulunmaktadır. Ancak güvenilir sertifikaların listesi cihaz ü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ına yönelik destek, 10'dan önceki Android sürümlerinde sınırlı olabilir.

Apple, iOS cihazlar için destek sayfalarında en yeni iOS sürümlerinin her biri için güvenilir kök CA'ların listesini tutar. Ancak tüm iOS 5 ve sonraki sürümler GlobalSign Root CA - R1'i destekler.

GTS Root R1 dahil 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.

Google Trust Services kök sertifikalarını tarayıcım veya işletim sistemim ne zaman dahil edecek?

Google son yıllarda, yaygın olarak kullanılan ve güvenilir kök sertifika paketlerine sahip olan tüm büyük üçüncü taraflarla kapsamlı bir şekilde çalışmıştır. Apple ve Microsoft gibi işletim sistemi üreticileri ile Google'ın kendi Android ve Chrome OS ekipleri, Mozilla, Apple ve Microsoft gibi tarayıcı geliştiricileri ve Google'ın kendi Chrome ekibi, telefon, set üstü kutu, TV, oyun konsolu ve yazıcı gibi donanım üreticileri buna örnek gösterilebilir.

Bu nedenle, şu anda yönetilen tüm sistemlerin Google'ın yeni GTS Kök CA'larını (GTS Root R1 dahil) zaten desteklemesi ve hatta eski sistemlerin önümüzdeki yıllarda Google tarafından verilen sertifikaların çapraz imzalanması için kullanılacak olan GlobalSign Root CA - R1'i destekleme olasılığı yüksektir.

Ancak üçüncü taraf sertifika ekleme zaman çizelgeleri büyük ölçüde Google'ın kontrolünde olmadığından, sunabileceğimiz en iyi genel tavsiye, mevcut sistem güncellemelerini düzenli olarak uyguladığınızdan emin olmanızdır.

Mozilla CA Sertifika Programı gibi belirli üçüncü taraflar, kendi sertifika dahil etme zaman çizelgelerini belgelemiş olabilir.

Sorun giderme

İhtiyacım olan araçları nereden edinebilirim?

Curl alma

İşletim sisteminiz curl hizmeti sunmuyorsa https://curl.haxx.se/ adresinden indirebilirsiniz. Kaynağı indirip aracı kendiniz derleyebilir veya platformunuz için mevcutsa önceden derlenmiş bir ikili programı indirebilirsiniz.

OpenSSL Alma

İşletim sisteminiz openssl hizmeti sunmuyorsa kaynağı https://www.openssl.org/ adresinden indirip aracı derleyebilirsiniz. Üçüncü taraflarca oluşturulan ikili programların listesine https://www.openssl.org/community/binaries.html adresinden ulaşabilirsiniz. Ancak bu derlemelerin hiçbiri OpenSSL ekibi tarafından desteklenmez veya herhangi bir şekilde desteklenmez.

Wireshark, Tshark veya Tcpdump alma

Çoğu Linux dağıtımı wireshark, komut satırı aracı tshark ve tcpdump sunsa da diğer işletim sistemleri için ilk ikisinin önceden derlenmiş sürümlerini https://www.wireshark.org adresinde bulabilirsiniz.

Tcpdump ve LibPCAP için kaynak kodu https://www.tcpdump.org adresinde bulunabilir.

Bu yararlı araçlarla ilgili belgeler sırasıyla Wireshark Kullanıcı Kılavuzu'nda, Tshark man sayfasında ve Tcpdump man sayfasında bulunabilir.

Java tuş aracını alma

keytool komut satırı aracı, her Java Geliştirme Kiti (JDK) veya Java Runtime Environment (JRE) sürümüyle 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ı pek olası değildir.

Üretim kesintisi durumunda yapılması gerekenler

İlk yapmanız gereken işlem, gerekli kök sertifikaları güvenilir Google kök CA paketinden uygulamanızın kullandığı kök sertifikalar deposuna yüklemektir.

  1. Yerel kök sertifika deponuzu yükseltmek için sistem yöneticilerinizle birlikte çalışın.
  2. Sisteminiz için geçerli işaretçiler için bu SSS'ye bakın.
  3. Platforma veya sisteme özel daha fazla yardıma ihtiyacınız olursa sistem sağlayıcınızın sunduğu teknik destek kanallarıyla iletişime geçin.
  4. Genel yardım için Google Haritalar Platformu destek ekibiyle iletişime geçme bölümünde açıklandığı gibi destek ekibimizle iletişime geçin. Not: Platforma özgü sorunlar için rehberlik yalnızca en iyi çaba esasına göre sağlanır.
  5. Taşımayla ilgili daha fazla güncelleme için herkese açık soruna 186840968 yıldız ekleyin.

Google Haritalar Platformu Destek Ekibi'ne ulaşma

İlk sorun giderme

Genel sorun giderme talimatları için Kök sertifika depomun güncellenmesinin gerekip gerekmediğini doğrulama bölümüne bakın.

Kök sertifikaları içe veya dışa aktarmanız gerekirse Güvenilir sertifikalarınızı yönetme bölümü de değerli bilgiler sağlayabilir.

Sorun çözülmezse 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 çağırıyor?
  3. Hangi API'ler bu sorundan etkileniyor?
  4. Sorun tam olarak ne zaman başladı?
  5. 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.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çları edinme talimatları için İhtiyacım olan araçları nereden bulabilirim? sorusuna bakın.

Destek yazışması oluşturma

Lütfen Google Haritalar Platformu Desteği 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ğıdaki bilgileri de sağlayın:

  • Genel IP adresleriniz nedir?
  • DNS sunucunuzun genel IP adresi nedir?
  • Mümkünse https://maps.googleapis.com/ ile ilgili PCAP biçiminde başarısız TLS anlaşmasının tcpdump veya Wireshark paket yakalama işlemi.Bunun için paketin tamamını kesmeden yakalamak için yeterince büyük bir anlık görüntü uzunluğu kullanılır (ör. tcpdump'in eski sürümlerinde -s0 kullanılır).
  • Mümkünse hizmetinizden yapılan alıntıları, tercihen tam sunucu sertifika zinciri bilgileriyle birlikte, TLS bağlantısı hatasının tam nedenini gösteren alıntıları günlüğe kaydeder.

Gerekli araçları edinme talimatları için İhtiyacım olan araçları nereden bulabilirim? sorusuna bakın.

186840968 numaralı herkese açık sorun hakkında yayınlanıyor

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

DNS'min genel 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 çıktısı nasıl yorumlanır?

curl işlevinin -vvI işaretleriyle çalıştırılması çok faydalı bilgiler sağlar. Sonucu yorumlamaya yönelik birkaç talimat aşağıda verilmiştir:

  • "*" ile başlayan satırlar, TLS iletişimi çıkışını ve bağlantı sonlandırma bilgilerini gösterir.
  • ">" ile başlayan satırlar, curl tarafından gönderilen giden HTTP isteğini görüntüler.
  • "<" 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ğu anlamına gelir.

TLS kitaplığı ve kök sertifika paketi kullanıldı

curl, -vvI işaretleriyle çalıştırıldığında, kullanılan kök sertifika deposunun çıktısı da alınır. Ancak çıktı, burada gösterildiği gibi sisteme göre değişiklik gösterebilir.

NSS'ye bağlı curl içeren bir Red Hat Linux makinesinden yapılan çı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 yapılan çıkış şu satırları içerebilir:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

Google kök sertifikası PEM dosyasını kullanarak bir Ubuntu veya Debian Linux makinesinden yapılan ve --cacert işaretiyle verilen çı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ğindekilere benzer 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ğlantı girişiminin başarısız olduğunun 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ı listelenmelidir. Buna ek olarak, > veya < ile başlayan satırların varlığı, yük HTTP trafiğinin TLS şifreli 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ı, insan tarafından okunabilecek biçimde nasıl yazdırılır?

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

  • Üstbilgi ve altbilgi dahil olmak üzere Base 64 kodlu sertifikanın tamamını kopyalayın:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • Daha sonra şunları yapın:

    openssl x509 -inform pem -noout -text
    ````
    
  • Sonra kopyalama arabelleğinizin içeriğini terminale yapıştırın.

  • Return tuşuna basın.

Örneğin giriş ve çıkışlar için PEM sertifikaları insan tarafından okunabilecek şekilde nasıl yazdırılır? 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ı

Şu soruda belirtildiği gibi Mobil uygulamalar bozulma riskiyle karşı karşıya mıdır?, Android, 4.0 sürümünden beri mobil cihaz kullanıcılarının Ayarlar bölümündeki güvenilir sertifikalar listesini doğrulamasına izin vermektedir. 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, mevcut Android Sanal Cihaz (AVD) sistem görüntüleri kullanılarak yapılan manuel doğrulamaya dayalı olarak, Android sürümü başına olası kullanılabilirlik durumu gösterilmektedir. Bu durum, AOSP ca-sertifikaları'nda yer alır ve sistem görüntülerinin artık kullanılamadığı Git deposu sürüm geçmişini içerir:

Android sürümü GTS Kök R1 GlobalSign Root 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+

Donanım yazılımı güncellemesi veya cihazı rootlamadan Android sistem kök sertifika deposunu güncellemek genellikle mümkün değildir. Ancak hâlâ yaygın olarak kullanılan çoğu Android sürümünde, mevcut güvenilir kök sertifika setinin, mevcut çoğu cihazın etkili kullanım ömrünün ötesinde birkaç yıl boyunca kesintisiz hizmet sağlama olasılığı yüksektir.

Sürüm 7.0'dan 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, sertifikaların uygulamayla paketlenmesi ve Güvenlik ve Gizlilikle İlgili Android En İyi Uygulamaları Ağ Güvenliği Yapılandırması eğitim dokümanında açıklandığı gibi özel bir ağ güvenliği yapılandırması oluşturularak gerçekleştirilir.

Ancak üçü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 muhtemelen yalnızca kısmi bir çözüm sağlayacaktır.

Eski cihazlarda kullanabileceğiniz tek seçenek, son kullanıcının cihazına uygulanan bir kurumsal grup politikası veya son kullanıcıların kendisi tarafından yüklenen, kullanıcılar tarafından eklenen CA'lara güvenmektir.

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, şirketin iOS 5 ve sonraki sürümler için Apple Destek makalelerindeki güvenilir kök CA gruplarının bağlantıları vardır:

Ancak, iOS cihazına yüklenen ek sertifikalar Ayarlar > Genel > Profil altından görünür. Başka sertifika yüklü değilse Profil menü öğesi görüntülenmeyebilir.

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

iOS sürümü GTS Kök R1 GlobalSign Root 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 depolanı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şiklik gösterir. Ancak çoğu Linux dağıtımında varsayılan kök sertifikalar aşağıdaki yollardan birinin altında bulunabilir:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, daha 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ı, diğer dizinlerdeki dosyaların sembolik bağlantıları olabilir.

OpenSSL kök sertifika deposu

OpenSSL kullanan uygulamalarda, varsayılan kök sertifikalar 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 en ü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 üst düzey Sistem kök sertifikalarım nerede depolanıyor ve bunu nasıl güncelleyebilirim? bölümüne bakın.

openssl dosyasını alma talimatları için OpenSSL'yi Alma bölümüne bakın.

Java kök sertifika deposu

Java uygulamaları kendi kök sertifika deposunu kullanabilir. Linux sistemlerinde genellikle /etc/pki/java/cacerts veya /usr/share/ca-certificates-java adresinde bulunur. Bu depolama alanı, Java keytool komut satırı aracı kullanılarak yönetilebilir.

Tek bir sertifikayı Java sertifikası depolama alanına 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 bir kök sertifikaya karşılık gelen sertifika dosyasıyla, alias ifadesini benzersiz ancak anlamlı bir sertifika takma adıyla ve certs.jks değerini ise ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirmeniz yeterlidir.

Daha fazla bilgi için lütfen aşağıdaki Oracle ve Stack Overflow makalelerine bakın:

Mozilla NSS kök sertifikaları deposu

Mozilla NSS kullanan uygulamalar, varsayılan olarak /etc/pki/nssdb altında bulunan sistem genelinde bir sertifika veritabanı veya ${HOME}/.pki/nssdb altında kullanıcıya özel bir varsayılan depolama alanı da kullanabilir.

NSS veritabanınızı güncellemek için certutil aracını kullanın.

Tek bir sertifika dosyasını NSS veritabanınıza içe aktarmak için aşağıdaki komutu verin:

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

cert.pem değerini önerilen her bir kök sertifikaya karşılık gelen sertifika dosyasıyla, cert-name yerine anlamlı bir sertifika takma adıyla ve certdir yerine ortamınızda kullanılan sertifika veritabanı yolunu eklemeniz 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üncellerken en azından aşağıdaki Microsoft makalelerini faydalı bulabilir:

Sertifika dosya biçimleri

PEM dosyası nedir?

Gizlilikle İyileştirilmiş Posta (PEM), RFC 7468'de önemsiz bir standart olarak biçimlendirilen, kriptografik sertifikalar, anahtarlar vb. depolamak ve göndermek için kullanılan fiili standart bir metin dosyası biçimidir.

Dosya biçiminin kendisi kullanıcılar tarafından okunabilir olsa da, Base64 olarak kodlanmış ikili sertifika veri bilgileri okunamaz. Bununla birlikte, PEM spesifikasyonu metin kodlamalı sertifika gövdesinden önce veya sonra açıklayıcı metnin yayınlanmasına izin verir ve birçok araç, bir sertifikadaki en alakalı veri öğelerinin düz metin özetini sağlamak için bu özelliği kullanır.

openssl gibi araçlar, sertifikanın tamamının kodunu kullanıcılar tarafından okunabilecek şekilde çözmek için de kullanılabilir. Daha fazla bilgi için PEM sertifikaları insan tarafından okunabilecek şekilde nasıl yazdırılır? bölümüne bakın.

".crt" dosyası nedir?

Sertifikaların PEM biçiminde dışa aktarılmasına izin veren araçlar, yaygın olarak dosyada metin kodlaması kullanıldığını belirtmek için ".crt" dosya uzantısını kullanır.

DER dosyası nedir?

Ayırt Edici Kodlama Kuralları (DER), sertifikaları kodlamak için kullanılan standart bir ikili program biçimidir. PEM dosyalarındaki sertifikalar genelde Base64 kodlamalı 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 ikili olan ve genellikle DER kodlu bir sertifikadır. Kurala göre, ".cer" dosyaları genellikle yalnızca tek bir sertifika içerir.

Sistemim roots.pem kaynağından tüm sertifikaları içe aktarmayı reddediyor

Bazı sistemler, ör. Java keytool, birden fazla PEM dosyası içerse bile sadece 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.

Köks.pem'den sertifikaları nasıl tek tek çı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

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 bağımsız PEM dosyaları ayrı olarak içe aktarılabilir veya sertifika deponuzun kabul ettiği bir dosya biçimine dönüştürülebilir.

PEM dosyası ile sistemim tarafından desteklenen bir biçim arasında dönüştürme nasıl yapılır?

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 yaygın kullanılan sertifika dosyası biçimlerine dönüştürme talimatları aşağıda listelenmiştir.

Kullanılabilen seçeneklerin tam listesi için resmi OpenSSL Komut Satırı Yardımcı Programları belgelerine bakın.

openssl dosyasını alma talimatları için OpenSSL'yi Alma 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'e 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?

openssl kullanarak bir dosyayı PEM'den PKCS #7'ye dönüştürmek için 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 dosya şifresi sağlamanız gerekir. PKCS 12 dosyasını sisteminize hemen aktarmazsanız şifreyi güvenli bir yerde sakladığınızdan emin olun.

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 aracını kullanarak, sertifika deponuzdaki tüm sertifikaları ve her birini dışa aktarmak için kullanabileceğiniz takma adları listelemek üzere aşağıdaki komutu yayınlayabilirsiniz:

keytool -v -list -keystore certs.jks

certs.jks değerini ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirmeniz yeterlidir. Bu komut, her bir sertifikanın takma adını da gösterir ve dışa aktarırsanı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:

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

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

Daha fazla bilgi için lütfen Java Platform, Standard Edition Tools Reference: keytool kılavuzuna bakın.

NSS kök sertifika deposundaki sertifikaları PEM dosyası olarak nasıl dışa aktarabilirim?

certutil hizmetini kullanarak, sertifika deponuzdaki tüm sertifikaları ve her birini dışa aktarmak için kullanabileceğiniz takma adı listelemek üzere aşağıdaki komutu yayınlayabilirsiniz:

certutil -L -d certdir

certdir değerini ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir. Bu komut aynı zamanda her bir sertifikanın takma adını da gösterir ve dışa aktarırsanız bu takma ada ihtiyacınız olur.

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 değerini ortamınızda kullanılan sertifika veritabanı yoluyla değiştirin ve dışa aktarmak istediğiniz sertifikaya karşılık gelen cert-name ve cert.pem değerlerini sağlayın.

Daha fazla bilgi için lütfen resmi NSS Tools certutil kılavuzuna ve işletim sistemi belgelerinize bakın.

PEM sertifikalarını insan tarafından okunabilecek biçimde yazdırma

Aşağıdaki örneklerde, GTS_Root_R1.pem dosyanızın aşağıdaki içeriklere sahip olduğunu varsayalım:

# 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 çıktı 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 dosyasını alma talimatları için OpenSSL'yi Alma bölümüne bakın.

Sertifikaları Java keytool kullanarak yazdırma

Aşağıdaki komutu verme

keytool -printcert -file GTS_Root_R1.pem

şuna benzer bir çıktı verir:

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'yi alma talimatları için Java keytool'u edinme bölümüne bakın.

Kök sertifika depomda hangi sertifikaların yüklü olduğunu nasıl görebilirim?

Bu, işletim sistemine ve SSL/TLS kitaplığına göre değişiklik gösterir. Ancak sertifikaları kök sertifika deposuna ve buradan içe ve dışa aktarmaya olanak 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 olan herhangi bir metin düzenleyicide açmayı deneyebilirsiniz.

PEM dosyası, ilişkili sertifika yetkilisine ait okunabilir bilgileri sağlayacak şekilde uygun ş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 gibi durumlarda dosyanın adı (ör. GTS_Root_R1.pem), sertifikanın hangi CA'ya ait olduğunu belirtebilir. -----BEGIN CERTIFICATE----- ve -----END CERTIFICATE----- jetonları arasındaki sertifika dizesinin her CA için benzersiz olacağı da garanti edilir.

Bununla birlikte, yukarıdaki araçlar eksik olsa bile, güvenilir Google kök CA paketindeki her sertifika düzgün bir şekilde etiketlendiği için, kök sertifika deponuzdaki kök CA'lara Issuer ile ya da PEM dosya sertifikası dizelerini karşılaştırarak paketteki kök CA'ları güvenilir bir şekilde eşleyebilirsiniz.

Web tarayıcıları kendi kök sertifika deposunu kullanabilir veya işletim sistemi 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ının bozulma riski var mı? sorusuna bakın.

Cep telefonuna özel talimatlar için, ayrı bir soru olan Cep telefonumda güvenilir kök sertifikaları nasıl kontrol edebilirim? bölümüne göz atın.

Ek

Daha fazla bilgiye mi ihtiyacınız var?

Her zaman birincil olarak işletim sistemi belgelerinizi, uygulama programlama dillerinizin belgelerini ve uygulamanızın kullandığı tüm harici kitaplıklardaki belgeleri temel alın.

Bu SSS dahil diğer bilgi kaynakları eski veya başka bir şekilde yanlış olabilir ve güvenilir olarak kabul edilmemelidir. Ancak Stack Exchange Soru-Cevap topluluklarının yanı sıra Linux'ta AdamW ve daha fazlası, confirm blog gibi sitelerde de faydalı bilgiler bulabilirsiniz.

Lütfen Google Trust Services 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 Ortak Anahtar Sabitleme makalesini ve Sabitleme ile İlgili Yardımcı Kısa Bilgiler'i (yalnızca İngilizce) bilgilendirici 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 konusuyla ilgili tartışma için Matthew Dolan'ın Android Security: SSL Pinning (Android Güvenliği: SSL Sabitleme) adlı blog yayınını yararlı bulabilirsiniz.

Güvenlik ve Gizlilik için Android En İyi Uygulamaları Ağ Güvenliği Yapılandırması eğitim belgesi ve JeroenHD 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 kod depolarına bakın.