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

Bu belgede aşağıdaki bölümler yer alır:

Daha ayrıntılı bir genel bakış için Bu ne hakkında? başlıklı makaleyi inceleyin.

Terminoloji

Aşağıda, bu belgeyle ilgili olarak bilmeniz gereken en önemli terimlerin listesini bulabilirsiniz. İlgili terminolojiye dair daha kapsamlı bir genel bakış için Google Trust Services SSS bölümüne bakın.

TLS/SSL sertifikası
Sertifika, bir şifreleme anahtarını kimliğe bağlar.
TLS/SSL sertifikaları, web sitelerinde kimlik doğrulaması yapmak ve güvenli bağlantılar kurmak için kullanılır. Sertifikalar, Sertifika Yetkilileri olarak bilinen kuruluşlar tarafından düzenlenir ve kriptografik olarak imzalanır.
Tarayıcılar, iletilen bilgilerin doğru sunucuya gönderildiğini ve iletim sırasında şifrelendiğini bilmek için güvenilir sertifika yetkilileri tarafından verilen sertifikaları kullanır.
Güvenli Yuva Katmanı (SSL)
Güvenli Yuva Katmanı, internet iletişimlerini şifrelemek için en yaygın kullanılan protokoldü. SSL protokolü artık güvenli kabul edilmemektedir ve Google hizmetlerinde desteklenmemektedir.
Taşıma Katmanı Güvenliği (TLS)
Taşıma Katmanı Güvenliği, SSL'in yerini almıştır.
Sertifika Yetkilisi (CA)
Sertifika yetkilisi, cihazlar ve kişiler için dijital bir 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) düzenler.
CA'lar, sertifika vermeden önce sertifikadaki adların, sertifikayı isteyen kişi veya tüzel kişilikle bağlantılı olduğunu doğrulamakla sorumludur.
Sertifika yetkilisi terimi hem Google Trust Services gibi kuruluşları hem de sertifika veren sistemleri ifade edebilir.
Ortak Anahtar Altyapısı (PKI)
Ortak anahtar altyapısı, bir sertifika yetkilisinin sertifika isteyen kişinin kimliğini doğrulamasını, bu doğrulamayı onaylayan bir sertifika oluşturmasını ve internet kullanıcılarının sertifikaya güvenmesini sağlayan bir dizi teknoloji, politika ve prosedürdür.
Ortak anahtar kriptografisi, bunu mümkün kılan teknolojidir.
PKI, dahili ağlarda da kullanılır ancak en yaygın kullanım alanı web'de şifrelenmiş iletişimi etkinleştirmektir. Web tarayıcıları, kök sertifika depolarında bulunan CA'lar tarafından verilen sertifikalara güvenir.
Ortak anahtar kriptografisi
Ortak anahtar şifreleme, anahtar çiftlerinin kullanıldığı bir şifreleme biçimidir. Anahtarlardan biri herkese açık olarak kabul edilir ve geniş çapta dağıtılabilir. Diğeri ise özel olarak kabul edilir ve gizli tutulmalıdır.
Ortak anahtarla şifrelenen verilerin şifresi, ilgili özel anahtarla çözülebilir ve bunun tersi de geçerlidir.
Bu, iki tarafın birbirini doğrulayabildiği ve gizli bilgilerin önceden paylaşılmasına gerek kalmadan şifrelenmiş verileri paylaşabildiği TLS gibi protokollerin temel yapı taşları olan dijital imzalar ve ortak anahtar şifreleme kavramlarını mümkün kılar.
Kök sertifika deposu (veya güven deposu)
Kök sertifika deposu, bir Uygulama Yazılımı Tedarikçisi tarafından güvenilen bir dizi Sertifika Yetkilisi içerir. Çoğu web tarayıcısı ve işletim sisteminin kendi kök sertifika deposu vardır.
Kök sertifika deposuna dahil edilebilmek için Sertifika Yetkilisi, Uygulama Yazılımı Tedarikçisi tarafından belirlenen katı koşulları karşılamalıdır.
Bunlar genellikle CA/Browser Forum şartları gibi sektör standartlarına uygunluğu içerir.
Kök Sertifika Yetkilisi
Bir kök sertifika yetkilisi (veya daha doğru bir ifadeyle sertifikası), sertifika zincirindeki en üstteki sertifikadır.
Kök CA sertifikaları genellikle kendinden imzalıdır. Bunlarla ilişkili özel anahtarlar, yüksek güvenlikli tesislerde saklanır ve yetkisiz erişime karşı korunmak için çevrimdışı durumda tutulur.
Ara Sertifika Yetkilisi
Bir ara sertifika yetkilisi (veya daha doğru bir ifadeyle sertifikası), sertifika zincirindeki diğer sertifikaları imzalamak için kullanılan bir sertifikadır.
Ara CA'lar, öncelikle kök CA sertifikasının çevrimdışı kalmasına izin verirken çevrimiçi sertifika verilmesini sağlamak için kullanılır.
Ara CA'lar, bağımlı CA'lar olarak da bilinir.
Veren Sertifika Yetkilisi
Bir veren sertifika yetkilisi veya daha doğrusu sertifikası, bir sertifika zincirindeki en alttaki sertifikayı imzalamak için kullanılan sertifikadır.
En alttaki bu sertifikaya genellikle abone sertifikası, son varlık sertifikası veya yaprak sertifikası adı verilir. Bu belgede sunucu sertifikası terimi de kullanılacaktır.
Sertifika zinciri
Sertifikalar, veren kuruluşlarına bağlanır (kriptografik olarak imzalanır). Sertifika zinciri; yaprak sertifikası, tüm veren sertifikaları ve kök sertifikadan oluşur.
Çapraz imzalama
Uygulama Yazılımı Tedarikçileri'nin müşterileri, ürünleri tarafından güvenilmesi için kök sertifika depolarını yeni CA sertifikalarını içerecek şekilde güncellemelidir. Yeni CA sertifikalarını içeren ürünlerin yaygın olarak kullanılması biraz zaman alır.
CA sertifikaları, eski istemcilerle uyumluluğu artırmak için başka bir eski ve yerleşik CA tarafından "çapraz imzalanabilir". Bu işlem, aynı kimlik (ad ve anahtar çifti) için ikinci bir CA sertifikası oluşturur.
Kök sertifika depolarında bulunan CA'lara bağlı olarak istemciler, güvendikleri bir köke kadar farklı bir sertifika zinciri oluşturur.

Genel bilgiler

Bu neyle ilgili?

Özet: https://pki.goog/faq/#connecting-to-google adresindeki yönergeleri uygulamazsanız gelecekte sertifikayla ilgili kesintiler yaşama olasılığınız yüksektir.

Büyük resim

2017'de Google, HTTPS tarafından kullanılan TLS internet güvenliğinin temelini oluşturan şifreleme imzaları olan kendi kök sertifikalarını yayınlamak ve kullanmak için çok yıllık bir proje başlattı.

İlk aşamadan sonra Google Maps Platform hizmetlerinin TLS güvenliği, Google'ın kendi kendine yayınladığı Google Trust Services (GTS) kök CA'larına geçişi kolaylaştırmak için GMO GlobalSign'dan satın aldığı, çok iyi bilinen ve yaygın olarak güvenilen bir kök sertifika yetkilisi (CA) olan GS Root R2 tarafından sağlanmıştır.

Neredeyse tüm TLS istemcileri (ör. web tarayıcıları, akıllı telefonlar ve uygulama sunucuları) bu kök sertifikasına güvendiğinden taşıma işleminin ilk aşamasında Google Haritalar Platformu sunucularıyla güvenli bir bağlantı kurabildi.

Ancak bir CA, tasarım gereği kendi sertifikasının geçerlilik bitiş zamanını aşan sertifikalar VERMEMELİDİR. GS Root R2'nin süresi 15 Aralık 2021'de dolduğundan Google, kendi hizmetlerini yeni bir CA'ya (GTS Root R1 Cross) taşıdı. Bu işlemde, Google'ın kendi kök CA'sı GTS Root R1 tarafından verilen bir sertifika kullanıldı.

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üveniyor olsa da çoğu eski sistemde sorunsuz bir geçiş sağlamak için Google, mevcut en eski ve en güvenilir kök CA'lardan biri olan GlobalSign Root CA - R1'i kullanarak GMO GlobalSign'dan çapraz imza aldı.

Bu nedenle, çoğu müşterinin Google Haritalar Platformu istemcileri bu güvenilir kök CA'lardan birini veya her ikisini de tanıyor olmalıdır ve taşıma işleminin ikinci aşamasından tamamen etkilenmemiş olmalıdır.

Bu durum, 2018'deki taşıma işleminin ilk aşamasında işlem yapan müşteriler için de geçerlidir. Bu müşterilerin o sırada talimatlarımıza uyarak tüm sertifikaları güvenilir Google kök CA paketimizden yüklediği varsayılır. Bu müşteriler, söz konusu dosyada güncelleme olup olmadığını kontrol etmeli ve güven deposunu en az 6 ayda bir güncellemelidir.

Google Haritalar Platformu hizmetlerine bağlanırken sorun yaşıyorsanız aşağıdaki durumlar geçerli olduğunda sistemlerinizi doğrulamanız gerekir:

  • Hizmetleriniz standart dışı veya eski platformlarda çalışıyorsa ya da kendi kök sertifika deponuzu yönetiyorsanız
  • 2017-2018'de, Google'ın kök CA taşıma işleminin ilk aşamasında işlem yapmadıysanız veya güvenilir Google kök CA paketindeki sertifikaların tamamını yüklemediyseniz

Yukarıdaki durum geçerliyse müşterilerinizin, taşıma işleminin bu aşamasında Google Haritalar Platformu'nun kesintisiz kullanımını sağlamak için önerilen kök sertifikalarla güncellenmesi gerekebilir.

Daha fazla teknik ayrıntı için aşağıya bakın. Genel talimatlar için Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrularım? bölümüne bakın.

Ayrıca, hizmetlerinizi gelecekteki kök CA değişikliklerine karşı korumak için kök sertifika depolarınızı yukarıdaki seçilmiş kök CA paketiyle senkronize etmeye devam etmenizi öneririz. Ancak bu değişiklikler önceden duyurulacaktır. Gelişmelerden nasıl haberdar olacağınızla ilgili daha fazla bilgi için Bu taşıma aşamasıyla ilgili güncellemeleri nasıl alabilirim? ve Gelecekteki taşımalarla ilgili önceden nasıl bildirim alabilirim? bölümlerine bakın.

Teknik özet

15 Mart 2021'de Google Güvenlik Blogu'nda duyurulduğu üzere, Google Haritalar Platformu'nun 2018'in başlarından beri kullandığı kök CA olan GS Root R2'nin geçerlilik süresi 15 Aralık 2021'de doldu. Bu nedenle Google, yeni yayınlanan GTS Root R1 Cross CA'ya taşınacaktır.

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

Ancak aşağıdaki iki nokta da geçerliyse sistemlerinizi en azından doğrulamanız gerekir:

  • Hizmetleriniz standart olmayan veya eski platformlarda çalışıyorsa ya da kendi kök sertifikası deponuzu yönetiyorsanız
  • 2017-2018'de, Google'ın kök CA taşıma işleminin ilk aşamasında işlem yapmadıysanız veya güvenilir Google kök CA paketindeki sertifikaların tamamını yüklemediyseniz

Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrulayabilirim? başlıklı makalede, sisteminizin etkilenip etkilenmeyeceğini test etme konusunda rehberlik sağlanmaktadır.

Ayrıntılı bilgi için Kök sertifika depomu neden güvenilen Google kök CA paketiyle senkronize etmeliyim? başlıklı soruyu inceleyin.

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

Güncellemeler için herkese açık 186840968 numaralı sorunu yıldızlayın. Bu SSS, taşıma işlemi boyunca genel ilgi çekebilecek konularla karşılaştığımızda da güncellenir.

Gelecekteki taşımalarla ilgili önceden nasıl bildirim alabilirim?

Yeni kök sertifikalar https://pki.goog/updates/ adresinde duyurulur. Güncellemelerle ilgili bildirim almak için abone olabileceğiniz bir RSS özet akışı da vardır. Yalnızca yeni kökler duyurulur. Kök sertifikalar arasında geçiş yapan sertifika zinciri değişiklikleri duyurulmaz ve herhangi bir zamanda gerçekleşebilir. Tek bir köke veya ara sertifikaya sabitlememelisiniz ve Google'a güvenilir bağlantılar sağlamak istiyorsanız https://pki.goog/faq/#connecting-to-google adresinde belirtilen Google köklerinin tamamına güvenmelisiniz.

Google Güvenlik Blogu'nu takip etmenizi öneririz. Ayrıca, blogdaki herkese açık duyurunun ardından ürüne özel belgeleri en kısa sürede güncellemek için çalışacağız.

Ayrıca, daha fazla sayıda müşteriyi etkilemesi muhtemel değişikliklerle ilgili güncellemeleri forumda düzenli olarak yayınladığımız için Google Haritalar Platformu Bildirimleri'ne de abone olun.

Birden fazla Google hizmeti kullanıyoruz. Kök CA taşıma işlemi bunların hepsini etkiler mi?

Evet, kök CA taşıma işlemi tüm Google hizmetlerinde ve API'lerinde gerçekleşecek ancak zaman çizelgesi hizmete göre değişebilir. Ancak, Google Haritalar Platformu istemci uygulamalarınız tarafından kullanılan kök sertifika depolarının güvenilir Google kök CA paketi'nde listelenen tüm CA'ları içerdiğini doğruladıktan sonra hizmetleriniz devam eden taşıma işleminden etkilenmez. Bu depoları senkronize tutmak (en az 6 ayda bir) sizi gelecekteki kök CA değişikliklerine karşı da korur.

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

Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrulayabilirim? Aşağıda, sisteminizi test etmeyle ilgili genel talimatlar da verilmiştir.

Kök sertifikası depomun güncellenmesi gerekip gerekmediğini nasıl kontrol ederim?

Uygulama ortamınızı https://pki.goog/repository/ adresinin "Root CAs" (Kök CA'lar) bölümündeki tüm köklere göre test edin.

Sisteminiz genellikle aşağıdaki durumlarda kök CA değişiklikleriyle uyumlu olur:

  • Hizmetiniz, bakımı yapılan ana akım bir işletim sisteminde çalışıyorsa ve hem işletim sistemini hem de hizmetinizin kullandığı kitaplıkları yamalı tuttuysanız ve kendi kök sertifikası deponuzu tutmuyorsanız, veya:
  • Önceki önerilerimize uyduğunuzu ve güvenilir Google kök CA paketi'ndeki tüm kök CA'ları yüklediğinizi, güven deposunuzu düzenli olarak güncellediğinizi onaylayın.

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

Ayrıntılı bilgi için Kök sertifika depomu neden güvenilen Google kök CA paketiyle senkronize etmeliyim? başlıklı soruyu inceleyin.

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

İncelemelerinizde curl ve openssl adlı iki komut satırı aracını faydalı bulabilirsiniz. Her ikisi de çoğu platformda kullanılabilir ve kurulumunuzu test etmek için kapsamlı seçenekler sunar.

curl'yı edinmeyle ilgili 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. Daha eski bir sürümü kullanıyorsanız bu komutları sürümünüze göre yükseltin veya değiştirin. openssl edinmeyle ilgili talimatlar için aşağıdaki OpenSSL'yi edinme bölümüne bakın.

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

Somut test talimatları için Kök sertifikaları depomun güncellenmesi gerekip gerekmediğini nasıl doğrularım? başlıklı makaleyi inceleyin.

Varsayılan kök sertifika deponuzu test etme

Bu örnek, GTS R1 içindir. Test, tüm GTS köklerine karşı yapılmalıdır.

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

Güvenilir Google kök CA paketini doğrulama

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

2017 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 geçiş) Mart 2021'de duyurulmuştu ve GS Root R2'nin 15 Aralık 2021'de sona ermesinden önceki aylarda kullanıma sunulmuştu.

Yeni köklerin planları, gelecekteki sertifika geçerlilik bitimlerinden çok önce duyurulur ancak mevcut kökler arasındaki geçişler duyurulmaz.

Kök sertifika deponuzu güvenilir Google kök CA paketi'ndeki kök CA'ların seçilmiş listesiyle senkronize ederek uygulamalarınızı geleceğe hazırlayın.

Daha fazla bilgi için Neden kök sertifika depomu güvenilir Google kök CA paketiyle senkronize tutmalıyım? başlıklı soruyu da inceleyin.

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

  1. Aşamalı sunum tek bir veri merkezinde başlar.
  2. Bu lansman, küresel kapsama ulaşılana kadar kademeli olarak daha fazla veri merkezine genişletilir.
  3. Herhangi bir aşamada ciddi sorunlar tespit edilirse bu sorunlar giderilene kadar testler geçici olarak geri alınabilir.
  4. Önceki yinelemelerden alınan geri bildirimlere göre, tüm Google hizmetleri yeni sertifikalara geçene kadar dağıtıma başka Google hizmetleri de dahil edilir.

Kimler, ne zaman ve nerede etkilenecek?

Yeni veri merkezleri taşındıkça Google Haritalar Platformu geliştiricilerinin sayısı artacak ve bu geliştiriciler yeni sertifikaları almaya başlayacak. İstemci istekleri coğrafi olarak yakındaki veri merkezlerindeki sunuculara yönlendirildiğinden değişiklikler bir ölçüde yerelleştirilecektir.

Etkilenecek kişileri, zamanı ve yeri önceden kesin olarak söyleyemediğimiz için tüm müşterilerimizin hizmetlerini olası Google kök CA taşıma aşamalarından çok önce doğrulamalarını ve geleceğe hazırlamalarını öneririz.

Ek bilgiler için Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrularım? başlıklı makaleyi inceleyin.

Dikkat etmeniz gerekenler

Gerekli kök sertifikayla yapılandırılmamış istemciler, Google Haritalar Platformu ile 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ırmalarına bağlı olarak istemciler Google Haritalar Platformu isteği göndermeye devam edebilir veya isteğe devam etmeyi reddedebilir.

TLS istemcisinin Google Haritalar Platformu ile iletişim kurması için gereken minimum koşullar nelerdir?

Google Haritalar Platformu sertifikaları DNS Özne Alternatif Adları (SAN'lar) kullanır. Bu nedenle, istemcinin sertifika işleme özelliği, adın en soldaki etiketi olarak tek bir joker karakter içerebilen SAN'ları destekleyebilmelidir (ör. *.googleapis.com).

Eski TLS 1.0 ve 1.1 sürümleri hâlâ destekleniyor olsa da bunları kullanmamanızı ve mümkünse TLS 1.3'ü kullanmanızı öneririz.

Diğer şartlar ve öneriler için GTS SSS bölümündeki TLS istemcisinin Google ile iletişim kurması için önerilen şartlar nelerdir? ve Neden birçok Google hizmeti TLS 1.0 ve TLS 1.1 kullanılarak yapılan bağlantılara hâlâ izin veriyor? bölümlerine bakın.

Hangi tür uygulamaların bozulma riski vardır?

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

Google Haritalar Platformu web hizmeti uygulamaları

Hâlâ bakımı yapılan ve düzenli güncellemeler alan yaygın bir işletim sistemi kullanıyorsanız varsayılan kök sertifika deponuzda GTS Root sertifikaları zaten bulunuyor olmalıdır.

Artık güncelleme almayan eski bir işletim sistemi sürümü kullanıyorsanız GTS Root sertifikalarına sahip olabilirsiniz veya olmayabilirsiniz. Ancak kök sertifika deponuzda, gerektiğinde GTS köklerini çapraz olarak imzalamak için kullanılan en eski ve en yaygın olarak güvenilen kök CA'lardan biri olan GlobalSign Root CA - R1 bulunma olasılığı yüksektir.

Google Haritalar Platformu web hizmetlerini doğrudan son kullanıcı cihazından çağıran mobil uygulamalar için Mobil uygulamaların bozulma riski var mı? sorusundaki yönergeler geçerlidir.

İstemci tarafındaki Google Haritalar Platformu uygulamaları

Maps JavaScript API uygulamaları genellikle uygulamayı çalıştıran web tarayıcısının kök sertifikalarına bağlıdır. Daha fazla bilgi için JavaScript uygulamaları bozulma riskiyle karşı karşıya 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ını kullanan mobil uygulamalar için Google Haritalar Platformu web hizmetlerini çağıran uygulamalarda geçerli olan kurallar geçerlidir.

Daha fazla bilgi için Mobil uygulamaların bozulma riski var mı? başlıklı soruya bakın.

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

Sertifika paketinizi kendiniz güncellemeniz gerekir. Kök sertifika depomu neden güvenilir Google kök CA paketiyle senkronize tutmalıyım? başlıklı soruda belirtildiği gibi, güvenilir Google kök CA paketindeki tüm sertifikaları kendi kök sertifika deponuza aktarmanızı ve sertifika deponuzu düzenli olarak güncellemenizi öneririz.

Google, uygulamanızın bağlandığı Google alanları için sertifikaların veya ortak anahtarların sabitlenmesini önermez. Pimlerseniz kırılma riskiniz artar.

Sertifika veya genel anahtar sabitleme hakkında daha fazla bilgi için Daha fazla bilgiye mi ihtiyacınız var? sorusunun altında listelenen harici kaynaklara bakın.

Neden kök sertifika depomu güvenilir Google kök CA paketiyle senkronize tutmalıyım?

Güvenilir Google kök CA paketi içindeki kök CA'ların seçilmiş listesinde, Google hizmetleri tarafından öngörülebilir gelecekte makul bir şekilde kullanılabilecek tüm CA'lar yer alır.

Bu nedenle, sisteminizin gelecekte de sorunsuz çalışmasını istiyorsanız kök sertifikası deponuzda paketteki tüm sertifikaların bulunduğunu doğrulamanızı ve en az 6 ayda bir bu ikisini senkronize etmenizi kesinlikle öneririz.

Bu, özellikle hizmetleriniz bakımı yapılmayan bir işletim sistemi sürümünde çalışıyorsa, başka nedenlerle işletim sisteminizi ve kitaplıklarınızı yamalı tutamıyorsanız veya kendi kök sertifikaları deponuzu yönetiyorsanız önemlidir.

Gelecekteki kök CA taşıma işlemleriyle ilgili güncellemeleri nasıl alacağınızı öğrenmek için Gelecekteki taşıma işlemleriyle ilgili önceden nasıl bildirim alabilirim? başlıklı soruya bakın. Kök sertifika deponuzu düzenli olarak seçilmiş listeyle senkronize etmek, hizmetlerinizi CA değişiklikleri nedeniyle gelecekte yaşanabilecek hizmet kesintilerine karşı korur ve hem GTS Root R1 Cross hem de GlobalSign Root CA - R1'in geçerlilik süresi dolduktan sonra da hizmetlerinizin çalışmaya devam etmesini sağlar.

Ayrıca, Google hizmetlerine bağlanan bir ürün geliştiriyorum. Hangi CA sertifikalarına güvenmem gerekir? Daha fazla öneri için GTS SSS bölümünü inceleyin.

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

Bunu yapmanız, yeni bir sertifika kaydettiğimiz veya ara CA'ları değiştirdiğimiz herhangi bir noktada uygulamanızın bozulma riskini artırır. Bu değişikliklerden herhangi biri, herhangi bir zamanda ve önceden haber verilmeksizin gerçekleşebilir. Bu değişiklikler, maps.googleapis.com tarafından sunulanlar gibi bireysel sunucu sertifikalarının yanı sıra GTS Root R1 Cross gibi ara CA'larımız için de geçerlidir.

Hizmetlerinizi bu saldırılardan korumak için güvenilir Google kök CA paketi'nden yalnızca kök sertifikaları yüklemeli ve kendisine bağlı tüm sertifika zincirinin güvenilirliğini doğrulamak için yalnızca kök sertifikaya güvenmelisiniz.

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

JavaScript uygulamaları bozulma riski taşıyor mu?

GTS kök sertifikaları, çoğu modern tarayıcıya zaten iyi bir şekilde yerleştirilmiş ve bu tarayıcılar tarafından güvenilmektedir. GlobalSign'ın çapraz imzası, eski tarayıcılardaki çoğu son kullanıcı için bile sorunsuz bir geçiş sağlayacaktır. Bu, Maps JavaScript API'nin resmi olarak desteklenen tüm tarayıcılarını içerir.

Her modern tarayıcı, son kullanıcıların tarayıcının hangi sertifikalara güvendiğini doğrulamasını ve genellikle düzenlemesini sağlamalıdır. Tam konum her tarayıcıda farklı olsa da sertifika listesi genellikle Ayarlar bölümünde yer alır.

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

Cihaz üreticisinden düzenli güncellemeler almaya devam eden Android ve Apple iOS cihazların da geleceğe hazır olması beklenir. Güvenilen sertifikaların listesi, telefon üreticisine, cihaz modeline ve Android sürümüne göre değişebilse de çoğu eski Android telefon modelinde en azından GlobalSign Root CA - R1 sertifikası bulunur.

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

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

GTS Root R1 de dahil olmak üzere GTS kök CA'ları, iOS 12.1.3 sürümünden beri desteklenmektedir.

Daha fazla bilgi için Mobil telefonumdaki güvenilir kök sertifikaları nasıl kontrol edebilirim? başlıklı soruyu inceleyin.

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üvenilen kök sertifika paketlerini koruyan tüm büyük üçüncü taraflarla kapsamlı bir şekilde çalışmıştır. Örnekler arasında Apple ve Microsoft gibi işletim sistemi üreticilerinin yanı sıra Google'ın kendi Android ve ChromeOS ekipleri; Mozilla, Apple, Microsoft gibi tarayıcı geliştiricilerinin yanı sıra Google'ın kendi Chrome ekibi; telefon, set üstü kutu, TV, oyun konsolu, yazıcı gibi donanım üreticileri yer alır.

Bu nedenle, etkin olarak bakımı yapılan tüm sistemlerin GTS'nin kök CA'larını desteklemesi çok olasıdır. Hatta eski sistemlerin bile, önümüzdeki yıllarda Google tarafından verilen birçok sertifikayı çapraz olarak imzalamak için kullanılacak olan GlobalSign Root CA - R1'i desteklemesi büyük olasılıktır.

Ancak üçü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 uygulamanızdır.

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

Sorun giderme

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

curl'ü edinme

İş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 varsa önceden derlenmiş bir ikili dosya indirebilirsiniz.

OpenSSL'i edinme

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

Wireshark, Tshark veya Tcpdump'ı edinme

Ç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'in kaynak kodunu https://www.tcpdump.org adresinde bulabilirsiniz.

Bu faydalı araçlarla ilgili dokümanları sırasıyla Wireshark Kullanıcı Kılavuzu, Tshark man sayfasında ve Tcpdump man sayfasında bulabilirsiniz.

Java keytool'u edinme

keytool komut satırı aracı, her Java Development Kit (JDK) veya Java Runtime Environment (JRE) sürümüyle birlikte gönderilmelidir. keytool. almak için bunları yükleyin. Ancak uygulamanız Java kullanılarak oluşturulmadığı sürece kök sertifika doğrulaması için keytool kullanılması gerekli değildir.

Üretim kesintisi durumunda yapılması gerekenler

Sizin için birincil işlem, güvenilir Google kök CA paketinden gerekli kök sertifikaları uygulamanızın kullandığı kök sertifika 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 ipuçları hakkında bilgi edinmek üzere bu SSS'ye göz atın.
  3. Platform veya sisteme özgü 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 desteğine ulaşma bölümünde açıklandığı şekilde destek ekibimizle iletişime geçin. Not: Platforma özgü sorunlarla ilgili olarak yalnızca en iyi çaba gösterilerek rehberlik sağlanır.

  5. Taşıma ile ilgili daha fazla güncelleme için herkese açık 186840968 numaralı sorunu takip edin.

    Google Haritalar Platformu Destek Ekibi ile iletişime geçme

İlk sorun giderme

Genel sorun giderme talimatları için Kök sertifika depomun güncellenmesi gerekip gerekmediğini nasıl doğrularım? 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ünde de faydalı bilgiler bulabilirsiniz.

Sorun çözülmezse ve Google Haritalar Platformu Destek Ekibi ile iletişime geçmeye karar verirseniz lütfen 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. Bu sorundan hangi API'ler 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.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

Gerekli araçları edinmeyle ilgili talimatlar için İhtiyacım olan araçları nereden edinebilirim? sorusuna bakın.

Destek yazışması oluşturma

Google Haritalar Platformu Desteği ve Kaynakları bölümündeki Destek kaydı oluşturma talimatlarını uygulayın.

Destek kaydı açarken İlk sorun giderme bölümünde listelenen verilere ek olarak aşağıdakileri de sağlayın:

  • Herkese açık IP adresleriniz nelerdir?
  • DNS sunucunuzun herkese açık IP adresi nedir?
  • Mümkünse, başarısız olan TLS anlaşmasının https://maps.googleapis.com/ ile ilgili tcpdump veya Wireshark paket yakalama işlemi, PCAP biçiminde ve paketin tamamını kesmeden yakalamak için yeterince büyük bir anlık görüntü uzunluğu kullanılarak (ör. tcpdump'nin önceki sürümlerinde -s0 kullanılarak) gerçekleştirilmelidir.
  • Mümkünse hizmetinizden, tam sunucu sertifikası zinciri bilgileriyle birlikte TLS bağlantısının başarısız olmasının tam nedenini gösteren günlük alıntıları.

Gerekli araçları edinmeyle ilgili talimatlar için İhtiyacım olan araçları nereden edinebilirim? sorusuna bakın.

Herkese açık sorun 186840968 ile ilgili gönderi

Herkese açık 186840968 numaralı soruna yorum gönderirken İlk sorun giderme bölümünde listelenen bilgileri ekleyin.

DNS'min 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'u etkileşimli modda kullanabilirsiniz: 

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Curl çıkışını yorumlama

curl komutunu -vvI işaretleriyle çalıştırmak çok faydalı bilgiler sağlar. Çıktıyı yorumlamayla ilgili birkaç talimatı aşağıda bulabilirsiniz:

  • "*" ile başlayan satırlar, TLS anlaşmasından elde edilen çıktının yanı sıra bağlantı sonlandırma bilgilerini gösterir.
  • ">" ile başlayan satırlar, gönderilen giden HTTP isteğini gösterir.curl
  • "<" ile başlayan satırlar, sunucudan alınan HTTP yanıtını gösterir.
  • Protokol HTTPS ise ">" veya "<" satırlarının bulunması, başarılı bir TLS el sıkışması olduğunu gösterir.

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

curl komutunu -vvI işaretleriyle çalıştırmak, kullanılan kök sertifika deposunu da yazdırır ancak tam çıktı, burada gösterildiği gibi sisteme göre değişebilir.

NSS'ye karşı curl bağlantısı oluşturulmuş bir Red Hat Linux makinesinin çıkışında şu satırlar yer alabilir:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Ubuntu veya Debian Linux makinesinden alınan çıkış şu satırları içerebilir:

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

--cacert işaretiyle verilen Google kök sertifikası PEM dosyası kullanılarak Ubuntu veya Debian Linux makinesinden alınan çıkışta şu satırlar yer alabilir:

* 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 faydalı bilgiler sağlayabilecek User-Agent başlığını içerir.

Red Hat Linux makinesinden bir örnek:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

TLS el sıkışması başarısız oldu

Bu kod örneğindeki gibi satırlar, güvenilmeyen bir sunucu sertifikası nedeniyle bağlantının TLS el sıkışması sırasında sonlandırıldığını gösterir. > veya < ile başlayan hata ayıklama çıktısının olmaması da başarısız bağlantı girişiminin 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ğindeki satırlara benzer satırların varlığıyla gösterilir. Şifrelenmiş bağlantı için kullanılan şifreleme paketi ve kabul edilen sunucu sertifikasıyla ilgili ayrıntılar listelenmelidir. Ayrıca, > 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ını okunabilir biçimde yazdırma

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

  • Base64 kodlu sertifikanın tamamını (başlık ve altbilgi dahil) kopyalayın:

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • Ardından şunları yapın:

    openssl x509 -inform pem -noout -text
````

  • Ardından, kopyalama arabelleğinizin içeriğini terminale yapıştırın.

  • Return tuşuna basın.

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

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

{# disableFinding(LINE_OVER_80)}

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

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

---
…

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

Mobil telefonumdaki güvenilir kök sertifikaları nasıl kontrol edebilirim?

Android güvenilen sertifikaları

Mobil uygulamalar bozulma riskiyle karşı karşıya mı? sorusunun yanıtında belirtildiği gibi, Android, 4.0 sürümünden itibaren telefon kullanıcılarının Ayarlar bölümünde güvenilen sertifikaların 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üvenilen kimlik bilgileri
8.x, 9 Ayarlar > Güvenlik ve Konum > Şifreleme ve kimlik bilgileri > Güvenilen kimlik bilgileri
10+ Ayarlar > Güvenlik > Gelişmiş > Şifreleme ve kimlik bilgileri > Güvenilen kimlik bilgileri

Bu tabloda, mevcut Android Sanal Cihaz (AVD) sistem görüntüleri kullanılarak yapılan manuel doğrulama temel alınarak Android sürümüne göre en kritik kök sertifikaların olası kullanılabilirliği gösterilmektedir. Sistem görüntüleri artık kullanılamadığında AOSP ca-certificates Git deposu sürüm geçmişine geri dönülmüştür:

Android sürümü GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (15 Aralık 2021'e kadar geçerlidir)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Android sistem kök sertifikaları deposunu donanım yazılımı güncellemesi yapmadan veya cihazı rootlamadan 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 sertifikaları kümesinin, çoğu mevcut cihazın etkin kullanım ömrünün ötesinde, önümüzdeki yıllar boyunca kesintisiz hizmet sunması muhtemeldir.

Android, 7.0 sürümünden itibaren uygulama geliştiricilere yalnızca kendi uygulamaları tarafından güvenilen güvenilir sertifikalar eklemek için güvenli bir yöntem sunar. Bu işlem, sertifikaları uygulamayla birlikte paketleyerek ve Android'de Güvenlik ve Gizlilikle İlgili 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şturarak yapılır.

Ancak üçüncü taraf uygulama geliştiriciler, Google Play Hizmetleri APK'sından kaynaklanan trafiğin ağ güvenliği yapılandırmasını etkileyemeyeceğinden bu tür çabalar muhtemelen yalnızca kısmi bir geçici çözüm sunacaktır.

Eski cihazlarda, tek seçeneğiniz son kullanıcı cihazına uygulanan bir kurumsal grup politikasıyla veya son kullanıcılar tarafından yüklenen, kullanıcı tarafından eklenen CA'ları kullanmaktır.

iOS Trust Store

Apple, güvenilir kök sertifikalarının varsayılan kümesini doğrudan cep telefonu kullanıcısına göstermez. Şirket, iOS 5 ve sonraki sürümler için güvenilir kök CA kümelerine yönelik bağlantıları Apple Destek makalelerinde sağlar:

Ancak iOS cihaza yüklenen ek sertifikalar Ayarlar > Genel > Profil bölümünde görünür. Başka sertifika yüklenmemişse Profil menü öğesi gösterilmeyebilir.

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

iOS sürümü GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (15 Aralık 2021'e kadar geçerlidir)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Sistem kök sertifikaları depom nerede ve 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 yollardan birinde 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 sertifikaların bazıları, diğer dizinlerdeki dosyalara yönelik sembolik bağlantılar olabilir.

OpenSSL kök sertifikaları deposu

OpenSSL kullanan uygulamalar için aşağıdaki komutu kullanarak varsayılan kök sertifika deposu da dahil olmak üzere yüklü bileşenlerinin yapılandırılmış konumunu kontrol edebilirsiniz:

openssl version -d

Komut, kitaplığın ve yapılandırmalarının bulunduğu en üst düzey dizine karşılık gelen OPENSSLDIR değerini yazdırır:

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 sertifikaları deposunu kullanıyorsa sistem kök sertifika paketinin güncel olduğundan emin olmak için üst düzey bölüm olan Sistem kök sertifikaları depom nerede ve nasıl güncelleyebilirim? bölümünü inceleyin.

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

Java kök sertifika deposu

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

Java sertifika deponuza tek bir sertifika aktarmak için aşağıdaki komutu verin:

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

cert.pem yerine önerilen her kök sertifikaya karşılık gelen sertifika dosyasını, alias yerine benzersiz ancak anlamlı bir sertifika takma adını, certs.jks yerine ise ortamınızda kullanılan sertifika veritabanı dosyasını yazmanız yeterlidir.

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

Mozilla NSS kök sertifika deposu

Mozilla NSS kullanan uygulamalar, varsayılan olarak genellikle /etc/pki/nssdb altında bulunan sistem genelinde bir sertifika veritabanını veya ${HOME}/.pki/nssdb altında bulunan kullanıcıya özel bir varsayılan depoyu da 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 kısmını önerilen her kök sertifikaya karşılık gelen sertifika dosyasıyla, cert-name kısmını anlamlı bir sertifika takma adıyla ve certdir kısmını ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir.

Daha fazla bilgi için resmi NSS Tools certutil kılavuzunun yanı sıra işletim sisteminizin belgelerine bakın.

Microsoft .NET kök sertifikaları deposu

Windows .NET geliştiricileri, kök sertifika depolarını güncellemek için en azından aşağıdaki Microsoft makalelerini faydalı bulabilir:

Sertifika dosya biçimleri

PEM dosyası nedir?

Privacy-Enhanced Mail (PEM), kriptografik sertifikaları, anahtarları vb. depolamak ve göndermek için fiili bir standart metin dosyası biçimidir. RFC 7468'de yasal bir standart olarak resmileştirilmiştir.

Dosya biçimi kullanıcılar tarafından okunabilir olsa da Base64 kodlu ikili sertifika verileri bilgisi okunamaz. Ancak PEM spesifikasyonu, kodlanmış sertifika gövdesinin metninden önce veya sonra açıklayıcı metin yayınlanmasına izin verir ve birçok araç, sertifikadaki en alakalı veri öğelerinin açık metin özetini sağlamak için bu özelliği kullanır.

openssl gibi araçlar, sertifikanın tamamını insan tarafından okunabilir biçimde çözmek için de kullanılabilir. Daha fazla bilgi için PEM sertifikalarını okunabilir biçimde yazdırma bölümüne bakın.

".crt" dosyası nedir?

Sertifikaların PEM biçiminde dışa aktarılmasına olanak tanıyan araçlar, dosyanın metin kodlaması kullandığını belirtmek için genellikle ".crt" dosya uzantısını kullanır.

DER dosyası nedir?

Distinguished Encoding Rules (DER), sertifikaları kodlamak için kullanılan standartlaştırılmış bir ikili biçimdir. PEM dosyalarındaki sertifikalar genellikle Base64 kodlu DER sertifikalarıdır.

".cer" dosyası nedir?

".cer" sonekiyle dışa aktarılan bir dosya, PEM kodlu bir sertifika içerebilir ancak daha çok ikili, genellikle DER kodlu bir sertifika içerir. Geleneksel olarak ".cer" dosyaları genellikle yalnızca tek bir sertifika içerir.

Sistemim, roots.pem dosyasındaki tüm sertifikaları içe aktarmayı reddediyor

Bazı sistemler (ör. Java keytool, birden fazla sertifika içerse bile PEM dosyasından yalnızca tek bir sertifika içe aktarabilir. Dosyanın nasıl bölünebileceğini görmek için roots.pem dosyasından tek tek sertifikaları nasıl çıkarırım? sorusuna bakın.

roots.pem dosyasından tek tek sertifikaları nasıl çıkarabilirim?

Aşağıdaki bash komut dosyasını kullanarak roots.pem öğesini bileşen sertifikalarına ayırabilirsiniz:

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şlem, burada listelenenlere benzer sayıda ayrı PEM dosyası oluşturur:

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

02265526.pem gibi ayrı PEM dosyaları daha sonra ayrı ayrı 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

OpenSSL araç seti komut satırı aracı openssl, dosyaları yaygın olarak kullanılan tüm sertifika dosya biçimleri arasında dönüştürmek için kullanılabilir. PEM dosyasından en sık kullanılan sertifika dosyası biçimlerine dönüştürme talimatları aşağıda verilmiştir.

Kullanılabilir seçeneklerin tam listesi için resmi OpenSSL Command Line Utilities belgelerine göz atın.

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

PEM dosyasını DER biçimine nasıl dönüştürürüm?

openssl kullanarak bir dosyayı PEM'den DER'ye dönüştürmek için aşağıdaki komutu verebilirsiniz:

openssl x509 -in roots.pem -outform der -out roots.der
PEM dosyasını PKCS #7'ye nasıl dönüştürürüm?

openssl kullanarak bir dosyayı PEM'den PKCS #7'ye dönüştürmek için aşağıdaki komutu verebilirsiniz:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
PEM dosyasını PKCS #12 (PFX) dosyasına nasıl dönüştürebilirim?

openssl kullanarak bir dosyayı PEM'den PKCS #12'ye dönüştürmek için aşağıdaki komutu verebilirsiniz:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

PKCS #12 arşivi oluştururken dosya şifresi sağlamanız gerekir. PKCS #12 dosyasını hemen sisteminize aktarmıyorsanı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 deposundan sertifikayı PEM dosyası olarak nasıl dışa aktarırım?

keytool kullanarak, sertifika mağazanızdaki tüm sertifikaları ve her birini dışa aktarmak için kullanabileceğiniz diğer adları listelemek üzere aşağıdaki komutu verebilirsiniz:

keytool -v -list -keystore certs.jks

certs.jks yerine ortamınızda kullanılan sertifika veritabanı dosyasını koymanız yeterlidir. Bu komut, her sertifikanın diğer adını da gösterir. Bu ad, sertifikayı dışa aktarmak istediğinizde gereklidir.

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

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

certs.jks yerine ortamınızda kullanılan sertifika veritabanı dosyasını koymanız 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 Java Platform, Standard Edition Tools Reference: keytool{: .external} kılavuzuna bakın.

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

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

certutil -L -d certdir

certdir kısmını ortamınızda kullanılan sertifika veritabanı yoluyla değiştirmeniz yeterlidir. Bu komut, her sertifikanın takma adını da gösterir. Sertifikayı dışa aktarmak istiyorsanız bu takma ada ihtiyacınız olur.

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

certutil -L -n cert-name -a -d certdir > cert.pem

certdir kısmını 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 resmi NSS Tools certutil kılavuzunun yanı sıra işletim sisteminizin belgelerine bakın.

PEM sertifikalarını okunabilir biçimde yazdırma

Aşağıdaki örneklerde, GTS_Root_R1.pem dosyasının aşağıdaki içeriklere 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

Komutu verme

openssl x509 -in GTS_Root_R1.pem -text

şuna benzer bir çıkış 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'yi edinme talimatları için OpenSSL'yi edinme bölümüne bakın.

Java keytool kullanarak sertifika yazdırma

Aşağıdaki komutu verme

keytool -printcert -file GTS_Root_R1.pem

şuna benzer bir çıkış 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 edinme talimatları için Java Keytool'u edinme bölümüne bakın.

Kök sertifikaları depoma hangi sertifikaların yüklendiğini nasıl görebilirim?

Bu, işletim sistemine ve SSL/TLS kitaplığına göre değişir. Ancak, sertifikaların kök sertifika deposuna ve deposundan içe/dışa aktarılmasına olanak tanıyan araçlar genellikle yüklü sertifikaları listeleme seçeneği de sunar.

Ayrıca, güvenilen kök sertifikaları PEM dosyalarına başarıyla aktardıysanız veya kök sertifikaları deponuzda zaten depolanmış PEM dosyaları varsa dosyaları herhangi bir metin düzenleyicide açmayı deneyebilirsiniz. Bu, düz metin dosyası biçimidir.

PEM dosyası, ilişkili sertifika yetkilisinin insan tarafından okunabilir bilgilerini sağlayacak şekilde düzgün bir şekilde etiketlenmiş olabilir (güvenilir Google kök CA paketinden örnek):

# 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, GTS_Root_R1.pem gibi dosya adı, sertifikanın hangi CA'ya ait olduğunu açıklayabilir. -----BEGIN CERTIFICATE----- ve -----END CERTIFICATE----- jetonları arasındaki sertifika dizesi de her CA için benzersizdir.

Ancak yukarıdaki araçlara sahip olmasanız bile güvenilir Google kök CA paketindeki her sertifika düzgün şekilde etiketlendiğinden paketteki kök CA'ları Issuer veya PEM dosyası sertifika dizelerini karşılaştırarak kök sertifika deponuzdaki kök CA'larla güvenilir bir şekilde eşleştirebilirsiniz.

Web tarayıcıları kendi kök sertifika depolarını kullanabilir veya işletim sistemi tarafından sağlanan varsayılanı kullanabilir. Ancak tüm modern tarayıcılar, güvendikleri kök CA'ları yönetmenize veya en azından görüntülemenize olanak tanır. Daha fazla bilgi için JavaScript uygulamaları bozulma riskiyle karşı karşıya mı? başlıklı soruya bakın.

Cep telefonuna özel talimatlar için Cep telefonumdaki güvenilir kök sertifikaları nasıl kontrol edebilirim? başlıklı ayrı soruyu inceleyin.

Ek

Daha fazla bilgiye mi ihtiyacınız var?

Her zaman öncelikle işletim sisteminizin belgelerine, uygulama programlama dilinizin belgelerine ve uygulamanızın kullandığı harici kitaplıkların belgelerine güvenin.

Bu SSS de dahil olmak üzere diğer tüm bilgi kaynakları güncel olmayabilir veya başka bir şekilde yanlış olabilir ve yetkili kaynak olarak kabul edilmemelidir. Ancak, Stack Exchange Soru-Cevap topluluklarının birçoğunda faydalı bilgiler bulabilirsiniz.

Ayrıca Google Trust Services SSS bölümüne de göz atın.

Şifreleme, PKI, sertifikalar ve sertifika zincirleri hakkında kısa bir giriş için Paul Turner'ın PKI Bootcamp YouTube oynatma listesine göz atabilirsiniz.

Sertifika sabitleme gibi ileri düzey konular hakkında daha fazla bilgi için Open Web Application Security Project (OWASP) Certificate and Public Key Pinning (Sertifika ve Genel Anahtar Sabitleme) makalesini ve Pinning Cheat Sheet'i (Sabitleme Kopya Kağıdı) inceleyebilirsiniz. Android'e özel talimatlar için resmi Android'de Güvenlik ve Gizlilikle İlgili En İyi Uygulamalar HTTPS ve SSL ile Güvenlik eğitim dokümanına bakın. Android'de sertifika ve ortak anahtar sabitleme ile ilgili tartışmalar için Matthew Dolan'ın Android Security: SSL Pinning (Android Güvenliği: SSL Sabitleme) başlıklı blog yayınını inceleyebilirsiniz.

Android'de Güvenlik ve Gizlilikle İlgili En İyi Uygulamalar Ağ Güvenliği Yapılandırması eğitim dokümanında, Android'de ek güvenilir sertifikaları yönetme hakkında daha fazla bilgi verilmektedir.

AOSP tarafından güvenilen kök CA'ların kapsamlı listesi için ca-certificates Git deposuna bakın. Resmi olmayan Android çatallarına dayalı sürümler (ör. LineageOS) için OS satıcısı tarafından sağlanan uygun depolara bakın.