Depolanan prosedürlerden Google Haritalar Platformu hizmetlerini çağıran yerleştirilmiş cihazlar, kurumsal uygulama ve entegrasyon ara katman yazılımları veya ilişkisel veritabanları gibi özel niş sistemler kullanan müşteriler veya güncelliğini yitirmiş eski tarayıcılara ya da artık bakımda olmayan işletim sistemlerine bağımlı olan kullanıcılar, özellikle de ilk işlem sırasında herhangi bir işlem yapmadıklarında kök CA taşıma işleminin ikinci aşamasından olumsuz etkilenebilirler.
Etkilenen hizmet kesintisi yaşanmaması için bu durumdan etkilenen müşteriler, güvenilir Google kök CA paketi 'ndeki sertifikaları hemen yüklemelidir.
Önemli: Hizmetleriniz hemen etkilenmese de kök sertifikalarınızı yukarıdaki kök CA paketiyle senkronize durumda tutmanızı kesinlikle öneririz.
Tüm ayrıntılar için Kök sertifikalarımın güvenilir Google kök CA paketi ile senkronize edilmesini neden istemeliyim? sorusuna bakın.
İncelemelerinizde curl
ve openssl
adlı iki komut satırı aracını faydalı bulabilirsiniz. Bunların her ikisi de çoğu platformda kullanılabilir ve ayarlarınızı test etmek için kapsamlı seçenekler sunar.
curl
uygulamasını alma talimatları için aşağıdaki Curl alma bölümüne bakın.
Aşağıda gösterilen openssl
komutları, sürüm 1.1.1 veya üstü ile ilgilidir.
1.1.1 öncesi sürümler desteklenmemektedir. Daha eski bir sürüm kullanıyorsanız
bu komutları sürümünüz için gerektiği şekilde yeni sürüme geçirin veya değiştirin. openssl
uygulamasını kullanma talimatları için aşağıdaki OpenSSL'yi alma bölümüne bakın.
Aşağıdaki İhtiyacım olan araçları nereden bulabilirim? bölümünde daha fazla yardımcı araç bulabilirsiniz.
Somut test talimatları için lütfen Kök sertifikalarım mağazamın güncellenmesi gerektiğini doğrulama bölümünü inceleyin.
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, ardından aşağıdaki adımları uygulayın:
curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;
Google kök CA taşıma işlemi nasıl ve ne zaman devam edecek?
Ocak 2017'de duyurulan GS Root R2'ye taşınma, 2017'nin sonlarında başlayıp 2018'in ilk yarısında sona ermiştir.
İkinci aşama (GTS Root R1 Cross'a taşınmayla) Mart 2021'de duyurulmuştur ve önümüzdeki aylarda 15 Aralık 2021'de GS Root R2'nin süresi dolmadan önce kullanıma sunulacaktır.
İleriki bir sonraki taşıma aşamalarının zamanları, gelecekteki sertifika sürelerinin sona ermesinden çok önce duyurulur.
Bununla birlikte, kök sertifikalarınızı, güvenilir Google kök CA paketindeki kök CA'larla derlenen bir liste halinde senkronize ederseniz uygulamalarınızı geleceğe hazır hale getirebilirsiniz.
Daha fazla bilgi için Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize tutmalıyım? sorusuna da bakın.
Her bir Google hizmeti için genel kullanıma sunma planı
Aşamalı sunum tek bir veri merkezinde başlar.
Tüm dünyada kullanıma sunulana kadar kullanıma sunma süreci daha fazla veri merkezine genişletilir.
Herhangi bir aşamada ciddi sorunlar tespit edilirse testler, sorunlar giderilirken geçici olarak geri alınabilir.
Önceki iterasyonlardan elde edilen bilgilere göre, tüm Google hizmetleri kademeli olarak yeni sertifikalara geçene kadar kullanıma sunulan diğer Google hizmetleri de dahil edilir.
Bu durum kimleri ne zaman ve nerede etkileyecek?
Yeni veri merkezleri taşınırken Google Haritalar Platformu geliştiricilerinin sayısı
yeni sertifikaları almaya başlayacaktır. İstemci istekleri, coğrafi olarak yakındaki veri merkezlerinde bulunan sunuculara yönlendirilme eğiliminde olduğundan değişiklikler biraz yerelleştirilir.
Kimlerin, ne zaman ve nerede etkileneceğini kesin olarak söyleyemediğimiz için, tüm müşterilerimizin, mevcut Google kök CA taşıma aşamalarından önce hizmetlerini zaten doğrulayıp geleceğe hazır hâle getirmelerini öneririz.
Daha fazla bilgi için Kök sertifikalarımın güncellenmesinin gerekip gerekmediğini doğrulama bölümünü inceleyin.
Dikkat edilecek noktalar
Gerekli kök sertifikayla yapılandırılmayan istemciler, Google Haritalar Platformu'na ait TLS bağlantılarını doğrulayamaz. Bu durumda, müşteriler genellikle sertifika doğrulamasının başarısız olduğu konusunda bir uyarı verir.
TLS yapılandırmasına bağlı olarak istemciler bir Google Haritalar Platformu isteği göndermeye devam edebilir veya bu isteğe devam etmeyi reddedebilir.
Bir TLS istemcisinin Google Haritalar Platformu ile iletişim kurabilmesi için gereken minimum koşullar nelerdir?
Google Haritalar Platformu sertifikaları, DNS Konu Alternatif Adları (SAN'lar) kullandığından bir istemcinin sertifika işleme işlemi, adda en soldaki etiket olarak tek bir joker karakter içerebilen *.googleapis.com
gibi SAN'leri destekleyebilmelidir.
Diğer koşullar için lütfen GTS SSS sayfasındaki TLS istemcisinin Google ile iletişim kurması için önerilen koşullar nelerdir? bölümüne bakın.
Hangi tür uygulamalar bozulma riskiyle karşı karşıya?
Uygulama, herhangi bir geliştirici tarafından getirilen herhangi bir kısıtlama olmaksızın sistem kök sertifikalarını depolar
Google Haritalar Platformu web hizmeti uygulamaları
Standart bir işletim sistemi kullanıyorsanız (ör. Ubuntu, Red Hat, Windows 10 veya Server
2019, OS X) ve
mevcut düzenli güncellemeleri alıyorsanız varsayılan kök sertifika deponuzda GTS Root R1 sertifikası zaten bulunmalıdır.
Artık güncelleme almayan eski bir OS sürümü kullanıyorsanız GTS Root R1 sertifikasına sahip olabilirsiniz. Bununla birlikte, kök sertifika deponuz büyük olasılıkla en eski ve en yaygın güvenilir CA'lardan biri olan GlobalSign Root CA - R1 'i içerecektir.
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ı? bölümündeki yönergeler geçerlidir.
İstemci tarafı Google Haritalar Platformu uygulamaları
Maps JavaScript API uygulamaları, genellikle uygulamayı çalıştıran web tarayıcısının kök sertifikalarına dayanır. Daha ayrıntılı bilgi için JavaScript uygulamaları bozulma riskiyle mi karşılanıyor? bölümüne göz atı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ı kullanan yerel mobil uygulamalarda, Google Haritalar Platformu web hizmetlerini çağıran uygulamalar için aynı kurallar geçerlidir.
Daha fazla bilgi için Mobil uygulamalar zarar verme riskiyle karşı karşıya mı? sorusuna bakın.
Uygulama kendi sertifika paketini veya sertifika sabitleme gibi gelişmiş güvenlik özelliklerini kullanıyor
Sertifika paketinizi kendiniz güncellediğinizden emin olmanız gerekir. Kök sertifikalarım neden güvenilen Google kök CA paketiyle senkronize edilmeli? sorusunda ele alındığı gibi, güvenilir Google kök CA paketinden tüm sertifikaları kendi kök sertifika deponuza aktarmanızı öneririz.
Uygulamanızın bağlandığı Google alanları için sertifikaları veya ortak anahtarları sabitliyorsanız sertifikaları ve ortak anahtarları uygulamanızdaki güvenilir varlıklar listesine eklemeniz gerekir.
Sertifika veya ortak anahtar sabitleme hakkında daha fazla bilgi için Daha fazla bilgiye mi ihtiyacınız var? bölümünde listelenen harici kaynaklara bakın.
Kök sertifikalarımı neden güvenilir Google kök CA paketiyle senkronize tutmalıyım?
Güvenilir Google kök CA paketindeki kök CA'ların oluşturduğu liste, Google tarafından tahmin edilebilir bir şekilde kullanılabilecek tüm CA'ları içerir.
Bu nedenle, sisteminizi daha sonra kanıtlamak isterseniz kök sertifika deponuzun paketteki tüm sertifikaları içerdiğini doğrulamanızı ve ikisini de senkronize durumda tutma alışkanlığı edinmenizi önemle tavsiye ederiz.
Bu durum, hizmetleriniz bakımsız bir işletim sistemi sürümünde çalışıyorsa işletim sisteminiz ve kitaplıklarınızın yaması veya kendi kök sertifika deponuz varsa başka nedenlerle de önemlidir.
Soruya bakın
Gelecekteki taşıma işlemleriyle ilgili güncellemeleri nasıl alacağınızı öğrenmek için
Kök sertifikalarınızı düzenli olarak seçilen listeyle senkronize halde tutarsanız hizmetleriniz, CA değişikliklerinden kaynaklanan gelecekteki hizmet kesintilerine karşı korunacak ve hem GTS Root R1 Cross hem de GlobalSign Root CA - R1 'in geçerlilik süresi sona erdikten sonra da çalışmaya devam edecek.
Ayrıca lütfen soruya bakın
Google hizmetlerine bağlanan bir ürün oluşturuyorum. Daha fazla öneri için GTS SSS bölümünde, hangi CA sertifikalarına güvenmem gerekir?
Uyarı: Hizmetlerinizi bir yaprak sertifikasına veya ara CA'ya açıkça güvenecek şekilde hiçbir zaman yapılandırmamalısınız.
Bunu yapmak, yeni bir kayıt yaptığımızda veya ara CA'ları değiştirdiğinizde başvurunuzun bozulmasına neden olabilir. Bu tercihlerden herhangi biri, herhangi bir zamanda ve önceden bildirimde bulunulmadan gerçekleştirilebilir. Bu örnekler, maps.googleapis.com
tarafından yayınlananlar gibi sunucu sertifikalarının yanı sıra GTS Root R1 Cross gibi ara CA'larımız için de aynı şekilde geçerlidir.
Hizmetlerinizi bunlara karşı korumak için yalnızca güvenilir Google kök CA paketinden kök sertifikaları yüklemeniz ve ona bağlı tüm sertifika zincirinin güvenilirliğini doğrulamak için yalnızca kök sertifikasına güvenmeniz gerekir.
Kök sertifika yetkilisine güvenildiği sürece tüm modern TLS kitaplığı uygulamaları bu tür zincirleri otomatik olarak doğrulayabilmelidir.
JavaScript uygulamaları bozulma riskiyle mi karşı karşıya?
GTS kök sertifikaları, birçok modern tarayıcı tarafından zaten iyi şekilde yerleştirilmiş ve güvenilirdir. GMO GlobalSign'ın çapraz işareti ise eski tarayıcılardaki çoğu son kullanıcı için bile sorunsuz bir geçiş yapmanızı sağlar. Bu, Maps JavaScript API için resmi olarak desteklenen tüm tarayıcıları içerir.
Her modern tarayıcı, son kullanıcıların tarayıcının güvendiği sertifikaları doğrulamasına ve genellikle düzenlemesine izin vermelidir. Her tarayıcıda tam konum farklılık gösterse de sertifika listesi genellikle Ayarlar bölümünde bulunabilir.
Mobil uygulamalar zarar verme riski taşıyor mu?
Cihaz üreticisinden düzenli güncellemeler almaya devam eden Android ve Apple iOS cihazların da gelecekte bu konuda kanıtlanması bekleniyor. Eski Android telefon modellerinin çoğu en azından GlobalSign Root CA - R1 sertifikasını içerir. Bununla birlikte, güvenilir sertifikaların listesi mobil cihaz üreticisine, cihaz modeline ve Android sürümüne göre farklılık gösterebilir.
Bununla birlikte, GTS Root R1 dahil GTS kök CA'ları desteği 10 öncesindeki Android sürümlerinde sınırlı olabilir.
Önemli: Her bir mobil cihaz üreticisi farklı güvenilir kök sertifika grupları eklemeyi seçmiş olabileceği için, Android cihazlarda kullanılabilen kök sertifikalarını doğrulamanın en güvenilir yolu, son kullanıcının bunu kendi başına doğrulamasıdır. Android Ice CreamSandwich'ten (4.0) başlayan tüm Android sürümleri, gerçek yol farklılık gösterse de ayarlar altındaki güvenilir kök CA'ların listesini sunmalıdır.
Apple, iOS cihazlarda destek sayfalarında her yeni iOS sürümü için güvenilir kök CA'ların listesini tutar. Ancak tüm iOS 5 ve sonraki sürümleri 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ını nasıl kontrol edebilirim?
başlıklı makaleye bakın.
Tarayıcım veya işletim sistemim, Google Güven Hizmetleri kök sertifikalarını ne zaman içerir?
Önemli Nokta: Muhtemelen öyledir.
Google, son yıllarda yaygın olarak kullanılan ve güvenilir kök sertifika paketlerine sahip olan tüm önemli üçüncü taraflarla kapsamlı bir çalışma yürüttü. Apple ve Microsoft gibi işletim sistemi üreticilerinin yanı sıra Google'ın kendi Android ve Chrome OS ekipleri, Mozilla, Apple ve Microsoft gibi tarayıcı geliştiricileri ve Google'ın kendi Chrome ekibi de bunlara örnek olarak verilebilir. Telefon, set üstü kutu, TV, oyun konsolu ve yazıcı gibi donanım üreticileri bunlardan bazılarıdır.
Bu nedenle, şu anda bakımda olan herhangi bir sistem, GTS Root R1 dahil olmak üzere Google'ın yeni GTS Root CA'larını zaten desteklemektedir. Hatta eski sistemlerin bile, önümüzdeki yıllarda Google tarafından verilen sertifikaların imzalanması için kullanılacak GlobalSign Root CA - R1 'i destekleme olasılığı yüksektir.
Ancak, üçüncü taraf sertifikaların dahil edilme zamanları büyük ölçüde Google'ın kontrolü dışında olduğundan, sunabileceğimiz en iyi genel öneri mevcut sistem güncellemelerini düzenli olarak uyguladığınızdan emin olmaktır.
Mozilla'nın CA Sertifika Programı gibi belirli üçüncü taraflar kendi sertifika ekleme zaman çizelgelerini belgelemiş olabilir.
Sorun giderme
Kıvırma
İşletim sisteminiz curl
sunmazsa bu dağıtımı https://curl.haxx.se/ adresinden indirebilirsiniz. Kaynağı indirebilir ve aracı kendiniz derleyebilir veya platformunuz için mevcutsa önceden derlenmiş bir ikili programı indirebilirsiniz.
OpenSSL alma
OS dağıtımınız openssl
öğesini sağlamıyorsa kaynağı https://www.openssl.org/ adresinden indirebilir ve aracı derleyebilirsiniz. Üçüncü taraflarca oluşturulan ikili programların listesine https://www.openssl.org/community/binaries.html adresinden ulaşabilirsiniz.
Ancak bu yapıların hiçbiri OpenSSL ekibi tarafından desteklenmemektedir veya herhangi bir şekilde desteklenmemektedir.
Wireshark, Tshark veya Tcpdump alma
Linux dağıtımlarının çoğu wireshark
hizmetini sunarken, komut satırı aracı tshark
ve tcpdump
, diğer işletim sistemleri için ilk iki SDK'nın önceden derlenmiş sürümlerini https://www.wireshark.org adresinde bulabilirsiniz.
Tcpdump ve LibPCAP için kaynak kodunu https://www.tcpdump.org adresinde bulabilirsiniz.
Bu faydalı araçlara ilişkin belgeler sırasıyla Wireshark Kullanıcı Kılavuzu 'nda, Tshark man sayfasında ve Tcpdump kişi sayfasında bulunabilir.
keytool
komut satırı aracı, tüm Java Geliştirme Kiti (JDK) veya Java Runtime Environment (JRE) sürümleriyle gönderilmelidir. keytool.
edinmek için bunları yükleyin. Ancak uygulamanız Java kullanılarak oluşturulmadığı sürece kök sertifika doğrulaması için keytool
kullanmanız gerekmez.
Üretim kesintilerinde yapılması gerekenler
Sizin için yapılacak birincil işlem, gerekli kök sertifikaları güvenilir Google kök CA paketinden uygulamanızın kullandığı kök sertifikalara yüklemektir.
Not: Bu yöntem işletim sistemine, hatta uygulamanızın kullandığı SSL/TLS kitaplığına göre değişiklik gösterir. Bu nedenle, lütfen her zaman önce
sistem belgelerinize bakın! Ancak, Güvenilir sertifikalarınızı yönetme bölümünde faydalı bilgiler bulabilirsiniz.
Yerel kök sertifika deponuzu yükseltmek için sistem yöneticilerinizle birlikte çalışın.
Sisteminiz için geçerli olan işaretçileri görmek üzere bu SSS'ye göz atın.
Platforma veya sisteme özel yardıma ihtiyacınız olursa sistem sağlayıcınızın sunduğu teknik destek kanallarına ulaşın.
Genel yardım için Google Haritalar Platformu destek ekibine ulaşma bölümünde açıklandığı gibi destek ekibimizle iletişime geçin.
Not: Platforma özgü sorunlarda rehberlik yalnızca en iyi çaba esasına göre sağlanır.
Taşıma ile ilgili daha fazla güncelleme için 186840968 numaralı herkese açık soruna yıldız ekleyin.
Google Haritalar Platformu Destek Ekibi ile iletişime geçme
İlk sorun giderme
Genel sorun giderme talimatları için Kök sertifikalarımın güncellenmesinin gerekip gerekmediğini doğrulama bölümüne göz atın.
Kök sertifikaları içe veya dışa aktarmanız gerekiyorsa Güvenilir sertifikalarınızı yönetme bölümü de değerli bilgiler sağlayabilir.
Sorun çözülmezse ve Google Haritalar Platformu destek ekibiyle iletişime geçmeye karar verirseniz aşağıdaki bilgileri de sağlamaya hazır olun:
Etkilenen sunucularınız nerede bulunuyor?
Hizmetiniz hangi Google IP adreslerini arıyor?
Hangi API'ler bu sorundan etkileniyor?
Sorun tam olarak ne zaman başladı?
Aşağıdaki komutların sonuç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ı alma talimatları için İhtiyacım olan araçları nereden edinebilirim? başlıklı makaleyi inceleyin.
Destek yazışması oluşturma
Lütfen Google Haritalar Platformu Desteği ve Kaynakları 'ndaki Destek kaydı oluşturma talimatlarını uygulayın.
Destek kaydı başlatırken, Başlangıçtaki sorun giderme bölümünde listelenen verilerin yanı sıra lütfen aşağıdakileri de sağlayın:
Herkese açık IP adresleriniz nedir?
DNS sunucunuzun genel IP adresi nedir?
Mümkünse başarısız TLS anlaşmasının https://maps.googleapis.com/
ile PCAP biçiminde bir tcpdump veya Wireshark paketi yakalaması ve paketin tamamını kesmeden (ör. tcpdump
'nin eski sürümlerinde -s0
kullanarak) yakalamak için yeterince büyük bir anlık görüntü uzunluğu kullanılması gerekir.
Mümkünse günlüklerinizden, alıntılanan TLS bağlantısı hatasının tam nedeninin gösterildiği ve tam sunucu sertifikası zinciri bilgileriyle ilgili alıntılar.
Gerekli araçları alma talimatları için İhtiyacım olan araçları nereden edinebilirim? başlıklı makaleyi inceleyin.
Herkese açık yayında yayınlama 186840968
Dikkat: Sorun izleyici herkese açık bir forum olduğundan, lütfen IP adresleri, e-posta adresleri, API anahtarları veya diğer kimlik bilgileri gibi kimliği tanımlayabilecek veya hassas bilgileri yayınlamayın . Bu tür bilgileri paylaşmanız gerekiyorsa lütfen yukarıdaki Destek kaydı oluşturma bölümünde açıklandığı gibi bir destek kaydı oluşturun.
Herkese açık bir sorunla ilgili yorum yayınlarken lütfen 186840968 Başlangıçtaki 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'ı etkileşimli modda kullanabilirsiniz:
C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com
curl çıktısı nasıl yorumlanır
curl
özelliğini -vvI
işaretiyle çalıştırmak son derece faydalı bilgiler sağlar. Çıktıyı yorumlamaya yönelik birkaç talimatları burada bulabilirsiniz:
"*
" ile başlayan satırlar, TLS pazarlığından çıkış çıkışının yanı sıra bağlantı sonlandırma bilgilerini gösterir.
">
" ile başlayan satırlar, curl
tarafından gönderilen giden HTTP isteğini gösterir.
"<
" ile başlayan satırlar, sunucudan aldığı HTTP yanıtını gösterir.
Protokol HTTPS ise ">
" veya "<
" satırları başarılı bir TLS el sıkışması anlamına gelir.
TLS kitaplığı ve kök sertifika paketi kullanıldı
curl
kullanıldığında -vvI
işaretleri, kullanılan kök sertifikalar deposunu da yazdırır. Ancak burada tam olarak gösterilen çıkış, sisteme göre değişiklik gösterebilir.
curl
ile NSS arasında bağlı bir Red Hat Linux makinesinden gelen çıkışta ş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 gelen çıkışta şu satırlar olabilir:
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
--cacert
işareti kullanılarak verilen Google kök sertifika PEM dosyasını kullanan Ubuntu veya Debian Linux makinesinden çıkışta şu satırlar yer alabilir:
* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
CApath: /etc/ssl/certs
Dikkat: Yaygın olarak kullanılan birden fazla SSL/TLS kitaplığı vardır (curl sitesindeki karşılaştırma tablosuna bakın). Bunların tümü, farklı kök sertifika paketleri/mağazalar kullanacak şekilde yapılandırılabilir. curl, uygulamanızdan farklı bir SSL/TLS kitaplığına bağlıysa test sonuçlarının tamamen güvenilir olması için her ikisinin de aynı kök sertifika deposunu işaret etmesini sağlayabilirsiniz. Not: Uygulamanız için kendi sertifika paketinizi kullanıyorsanız veya uygulama yalnızca curl
dışında bir mağaza kullanıyorsa ve uygulamanız tarafından kullanılan bir sertifikayı doğrulamak istiyorsanız curl
'ı kullanarak söz konusu depodan curl
'ı kullanarak bu mağazaya sertifika aktarabilirsiniz.
Güvenilir sertifikalarınızı yönetme bölümünü inceleyin.
Kullanıcı aracısı
Giden istekler Kullanıcı Aracısı üstbilgisi içerir. Bu üstbilgi, curl
ve sisteminiz hakkında yararlı bilgiler sağlayabilir.
Red Hat Linux makinesinden ö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ışma işlemi başarısız oldu
Bu kod örneğindekiler gibi satırlar, güvenilmeyen bir sunucu sertifikası nedeniyle bağlantının TLS ile el sıkışmanın sona erdiğini belirtir. >
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**
TLS el sıkışma işlemi başarılı
Başarılı bir TLS el sıkışması, bu kod örneğindekilere benzer görünümlü satırlarla belirtilir. Şifrelenmiş bağlantı için kullanılan şifre paketi ve kabul edilen sunucu sertifikasının ayrıntıları listelenmelidir. Ayrıca, >
veya <
ile başlayan hatların varlığı, yük HTTP trafiğinin TLS şifreli bağlantı üzerinden başarıyla aktarıldığını 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
…
Çıkışın PEM biçiminde olduğunu varsayalım (ör. openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null
çıkışı), aşağıdaki adımları uygulayarak sunulan sertifikayı yazdırabilirsiniz:
Üstbilgi ve altbilgi dahil olmak üzere Base 64 kodlamalı sertifikanın tamamını kopyalayın:
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
Daha sonra:
openssl x509 -inform pem -noout -text
````
Ardından, kopya arabelleğinizin içeriğini terminale yapıştırın.
Return tuşuna basın.
Giriş ve çıkış örnekleri için PEM sertifikalarının okunaklı biçimde yazdırılması 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 telefonumdaki güvenilir kök sertifikaları nasıl kontrol edebilirim?
Android güvenilir sertifikaları
Daha önce belirtildiği gibi
Mobil uygulamalar zarar verme riskiyle karşı karşıya mı? ,
Android'in 4.0 sürümünden bu yana mobil cihaz kullanıcılarının Ayarlar bölümündeki güvenilen sertifikalar listesini doğrulamasına izin verilmiştir. Bu tabloda, Ayarlar menü yolu tam olarak 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 en kritik kök sertifikaların muhtemelen kullanılabilirliği gösterilmektedir. Bu bilgiler, sistem resimlerinin artık kullanılamadığı AOSP ca-sertifikalarına dayanır.
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+
Android sistem kök sertifikaları deposunu güncellemek genellikle bir donanım yazılımı güncellemesi veya rootlanmış cihaz olmadan mümkün değildir. Bununla birlikte, hâlâ yaygın olarak kullanılan Android sürümlerinin çoğunda mevcut güvenilir kök sertifika grubunun, mevcut cihazların çoğunun kullanım ömründen daha uzun bir süre boyunca hizmet kesintisi yaşamaması muhtemeldir.
Android, 7.0 sürümünden itibaren, uygulama geliştiricilere yalnızca güvenilir uygulamaları olan güvenilir sertifikalar eklemek için güvenli bir yöntem sunar. Bunu, Uygulamada Güvenlik ve Gizlilik İçin En İyi Uygulamalar
Ağ Güvenliği Yapılandırması
eğitim dokümanında açıklandığı şekilde sertifikaları uygulamayla birleştirerek ve özel bir ağ güvenliği yapılandırması oluşturarak yapabilirsiniz.
Ancak üçüncü taraf uygulama geliştiriciler Google Play Hizmetleri APK 'dan 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 ise tek seçeneğiniz, kullanıcı tarafından eklenen CA'ları kullanmak olabilir. Bunu, son kullanıcı cihazına uygulanan bir kurumsal grup politikası ya da son kullanıcıların kendisi yükleyebilir.
iOS Trust Store
Apple, varsayılan güvenilir kök sertifika grubunu mobil telefon kullanıcısına doğrudan göstermese de şirketin Apple Destek makalelerinden iOS 5 ve sonraki sürümler için güvenilir kök CA kümelerine bağlantıları vardır:
Ancak iOS cihazda yüklü olan tüm ek sertifikalar Ayarlar > Genel > Profil altında görüntülenebilir. Ek sertifikalar yüklü değilse Profil menü öğesi gösterilmeyebilir.
Bu tablo, yukarıdaki kaynaklara göre iOS sürümü başına en kritik kök sertifikaların kullanılabilirliğini gösterir:
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 ve üzeri
Sistem kök sertifikalarım nerede depolanır ve bu sertifikaları nasıl güncelleyebilirim?
Varsayılan kök sertifikaları deposunun konumu, işletim sistemine ve kullanılan SSL/TLS kitaplığına göre değişir. Bununla birlikte, ç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ı arasında şunlar bulunabilir:
/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.
Dikkat: Bu yollara yeni bir sertifika eklemek yeterli olmayabilir. Sisteminizi kullanmaya başlayacak şekilde yapılandırmak için büyük olasılıkla /usr/sbin/update-ca-certificates
(Debian, Ubuntu) veya /bin/update-ca-trust
(Fedora, RHEL ve CentOS) gibi ayrı bir komut çalıştırmanız gerekir. Bu komut, kullanılan gerçek kök sertifika paketini oluşturur. Önemli: Uygulamanız, özel bir sertifika deposu veya kök sertifika paketi kullanacak şekilde de yapılandırılmış olabilir. Bu nedenle, doğru komutu güncellediğinizden emin olun.
OpenSSL kök sertifikaları deposu
OpenSSL kullanan uygulamalar için yüklü bileşenlerin yapılandırılmış konumunu kontrol etmek için aşağıdaki komutu kullanarak varsayılan kök sertifikaları depolar:
openssl version -d
Komut, kitaplığın ve yapılandırmaların en üst düzey dizinine karşılık gelen OPENSSLDIR
kodunu yazdırır:
OPENSSLDIR: "/usr/lib/ssl"
Kök sertifikalar deposu, certs
alt dizininde bulunur.
Not: Bu dizinde, aşağıda gösterildiği gibi, yinelenen konumlara işaret eden sembolik bağlantılar (ör.varsayılan sistem kök sertifikaları deposu) bulunabilir. 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ının depolanıyorsa sistem kök sertifika paketinin güncel olduğundan emin olmak için üst düzey bölümü Sistem kök sertifikalarım nerede depolanır ve nasıl güncelleyebilirim? bölümüne bakın.
openssl
alma talimatları için OpenSSL'yi alma bölümüne bakın.
Java kök sertifikaları deposu
Java uygulamaları kendi kök sertifika deposunu kullanabilir . Bu sistem, Linux sistemlerinde genellikle /etc/pki/java/cacerts
veya /usr/share/ca-certificates-java
konumunda bulunur ve Java keytool
komut satırı aracı ile yönetilebilir.
Uyarı: Java keytool
yalnızca belirli bir PEM dosyasından ilk sertifikayı içe aktarır. Bu nedenle, önerilen sertifikaları içe aktarmaya devam etmeden önce roots.pem
grubunu bölmeniz gerekiyor. Şu soruya bakın: Roots.pem'den sertifikaları tek tek nasıl çıkarabilirim?
başlıklı makaleyi inceleyin.
Tek bir sertifikayı Java sertifika deponuza aktarmak için aşağıdaki komutu verin:
keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks
cert.pem
dosyasını, önerilen her kök sertifikaya karşılık gelen sertifika dosyasıyla, alias
öğesini benzersiz ancak anlamlı bir sertifika takma adıyla ve ortamınızda kullanılan sertifika veritabanı dosyasıyla certs.jks
değiştirin.
Not: İçe aktarmaya çalıştığınız sertifika, sertifika deponuzda zaten mevcut olup olmadığı sorulur.
Daha fazla bilgi için lütfen 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ı veya ${HOME}/.pki/nssdb
altında kullanıcıya özel bir varsayılan mağaza 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
Bunun için cert.pem
yerine önerilen her kök sertifikaya karşılık gelen sertifika dosyasını, anlamlı bir sertifika takma adı ile cert-name
ve ortamınızda kullanılan sertifika veritabanı yoluyla certdir
belirlemeniz yeterlidir.
Daha fazla bilgi için lütfen işletim sisteminizin dokümanlarının yanı sıra resmi NSS Araçları sertifikası kılavuzuna bakın.
Microsoft .NET kök sertifikaları deposu
Windows .NET geliştiricileri, en az aşağıdaki Microsoft makalelerini kök sertifika depolamalarını güncellerken faydalı bulabilir:
PEM dosyası nedir?
Privacy-Enhanced Mail (PEM) , kriptografik sertifikaların, anahtarların vb. depolanması ve gönderilmesi için kullanılan, RFC 7468 'da jüri standardı olarak kabul edilen standart bir metin dosyası biçimidir.
Dosya biçimi kullanıcılar tarafından okunabilir olsa da, Base64 kodlamalı ikili sertifika veri bilgileri değildir. Ancak PEM spesifikasyonu, metin kodlamalı sertifika gövdesinden önce veya sonra açıklama metni oluşturulmasına izin verir. Ayrıca birçok araç, sertifikadaki en alakalı veri öğelerinin net metin özetini sağlamak için de bu özelliği kullanır.
openssl
gibi araçlar, sertifikanın tamamını kullanıcılar tarafından okunabilir bir formda çözmek için de kullanılabilir. Daha fazla bilgi için PEM sertifikalarını kullanıcılar tarafından okunabilir biçimde yazdırma bölümüne göz atın.
".crt" dosyası nedir?
Sertifikaların PEM biçiminde dışa aktarılmasına izin veren araçlar
genellikle , dosyanın metin kodlamasını kullandığını belirtmek için ".crt" dosya uzantısını kullanılı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 genellikle Base64 kodlamalı DER sertifikalarıdır.
".cer" dosyası nedir?
".cer" son ekine sahip dışa aktarılan bir dosya PEM kodlamalı bir sertifika içerebilir , ancak genellikle DER kodlamalı bir sertifikadır. Kurala göre, ".cer" dosyaları genellikle tek bir sertifika içerir.
Sistemim roots.pem'deki tüm sertifikaları içe aktarmayı reddediyor
Bazı sistemler (ör. Java keytool
, birkaç tane içerse bile PEM dosyasından yalnızca 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? konusuna bakın.
Aşağıdaki basit bash komut dosyasını kullanarak roots.pem
öğesini bileşen sertifikalarına bölebilirsiniz:
csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done
Bu işlem, burada listelenenlere benzer bir dizi bağımsız 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
Daha sonra 02265526.pem
gibi ayrı PEM dosyaları içe aktarılabilir veya sertifika deponuzun kabul ettiği bir dosya biçimine dönüştürülebilir.
OpenSSL Araç seti komut satırı aracı
openssl
, yaygın olarak kullanılan tüm sertifika dosyası biçimleri arasında dosya dönüştürmek için kullanılabilir. PEM dosyasından en yaygın kullanılan sertifika dosyası biçimlerine dönüştürme talimatları aşağıda listelenmiştir.
Kullanılabilir seçeneklerin tam listesi için resmi OpenSSL Komut Satırı Yardımcı Dokümanlarına bakın.
openssl
alma talimatları için OpenSSL'yi alma bölümüne bakın.
openssl
kullanarak bir dosyayı PEM'den DER'e dönüştürmek için aşağıdaki komutu verebilirsiniz:
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 verebilirsiniz:
openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Bir PEM dosyasını PKCS #12'ye (PFX) nasıl dönüştürebilirim?
openssl
kullanarak bir dosyayı PEM'den PKCS #12'ye dönüştürmek için aşağıdaki komutu verebilirsiniz:
openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys
PKCS #12 arşivi oluştururken dosya şifresi sağlamanız gerekir. PKCS #12 dosyasını sisteminize hemen aktarmazsanız şifreyi güvenli bir yerde saklayın.
Kök sertifika mağazanızdaki sertifikaları listeleme, yazdırma ve dışa aktarma
Java Anahtar Deposu'ndaki bir sertifikayı PEM dosyası olarak nasıl dışa aktarırım?
keytool
aracını kullanarak sertifika mağazanızdaki tüm sertifikaları listelemek için aşağıdaki komutu verebilir, bunların her birini dışa aktarmak için kullanabileceğiniz takma adı öğrenebilirsiniz:
keytool -v -list -keystore certs.jks
certs.jks
öğesini 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. Dışa aktarmak için ihtiyacınız olan her şey bu 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
öğesini ortamınızda kullanılan sertifika veritabanı dosyasıyla değiştirin ve dışa aktarmak istediğiniz sertifikaya karşılık gelen bir alias
ve alias.pem
sağlayın.
Daha fazla bilgi için lütfen Java Platformu, Standart Sürüm Araçları Referansı: keytool kılavuzuna bakın.
NSS kök sertifikalarının sertifikalarını PEM dosyası olarak nasıl dışa aktarırım?
certutil
aracını kullanarak sertifika deponuzdaki tüm sertifikaları listelemek için aşağıdaki komutu verebilir, bunların her birini dışa aktarmak için kullanabileceğiniz takma adı öğrenebilirsiniz:
certutil -L -d certdir
certdir
ortamında, ortamınızda kullanılan sertifika veritabanı yolunu değiştirmeniz yeterlidir. Bu komut ayrıca her bir sertifikanın takma adını gösterir. Bu sertifikayı dışa aktarmak için ihtiyacınız olacaktır.
Tek bir sertifikayı PEM biçiminde dışa aktarmak için aşağıdaki komutu verin:
certutil -L -n cert-name -a -d certdir > cert.pem
certdir
öğesini ortamınızda kullanılan sertifika veritabanı yolu ile değiştirmeniz ve dışa aktarmak istediğiniz sertifikaya karşılık gelen bir cert-name
ve cert.pem
sağlamanız yeterlidir.
Daha fazla bilgi için lütfen işletim sisteminizin dokümanlarının yanı sıra resmi NSS Araçları sertifikası kılavuzuna bakın.
Aşağıdaki örneklerde, aşağıdaki içeriğe sahip GTS_Root_R1.pem
dosyanızın 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
Komutun yayınlanması
openssl x509 -in GTS_Root_R1.pem -text
aşağıdakine benzer bir sonuç vermelidir:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
Signature Algorithm: sha384WithRSAEncryption
Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
Validity
Not Before: Jun 22 00:00:00 2016 GMT
Not After : Jun 22 00:00:00 2036 GMT
Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
…
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
Signature Algorithm: sha384WithRSAEncryption
…
openssl
alma talimatları için OpenSSL'yi alma bölümüne bakın.
Aşağıdaki komutu verme
keytool -printcert -file GTS_Root_R1.pem
aşağıdakine benzer bir sonuç vermelidir:
Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48 27 85 2F 52 66 2C EF F0 ..+&q.+H'./Rf,..
0010: 89 13 71 3E ..q>
]
]
keytool
dosyasını alma talimatları için Java keytool alma başlıklı makaleye bakın.
Kök sertifikalar depolamamda 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ın kök sertifikalar deposuna ve bu sertifikalardan dışa aktarılmasına izin veren araçlar da genellikle yüklenen sertifikaları listeleme seçeneği sunar.
Ayrıca, güvenilir kök sertifikaları PEM dosyalarına başarıyla dışa aktardıysanız veya kök sertifika deponuz zaten PEM dosyaları içeriyorsa dosyaları düz metin dosyası biçiminde olduğu için herhangi bir metin düzenleyicide açmayı deneyebilirsiniz.
PEM dosyası, ilişkili sertifika yetkilisinin insan tarafından okunabilir bilgileri doğru şekilde etiketlenebilir (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 tür durumlarda dosyanın adı (ör. GTS_Root_R1.pem
), sertifikanın hangi CA'ya ait olduğunu belirleyebilir. -----BEGIN CERTIFICATE-----
ile -----END CERTIFICATE-----
jetonları arasındaki sertifika dizesinin de her CA için benzersiz olması garanti edilir.
Bununla birlikte, yukarıdaki araçlara sahip olmasanız bile güvenilir Google kök CA paketindeki her sertifika doğru bir şekilde etiketlendiğinden, paket ganistindeki kök CA'ları kök sertifika depounuzdaki kök CA'larla Issuer
tarihine kadar veya PEM dosyası sertifika dizelerini karşılaştırarak güvenilir bir şekilde eşleştirebilirsiniz.
Web tarayıcıları kendi kök sertifika deposunu kullanabilir veya işletim sistemi tarafından sağlanan varsayılan sertifikayı kullanabilir. Ancak tüm modern tarayıcılar, güvendikleri kök CA grubunu yönetmenize veya en azından bunların listesini görüntülemenize izin vermelidir. Daha fazla bilgi için JavaScript uygulamaları bozulma riskiyle mi karşılanıyor? sorusuna bakın.
Cep telefonuna özel talimatlar için ayrı bir soruya bakın
Cep telefonumdaki güvenilir kök sertifikaları nasıl kontrol edebilirim?
Ek
Daha fazla bilgiye mi ihtiyacınız var?
Her zaman işletim sisteminizin belgelerine, uygulama programlama dillerinizin dokümanlarına ve uygulamanızın kullandığı harici kitaplıklardan gelen belgelere güvenin.
Bu SSS dahil diğer tüm bilgi kaynakları güncelliğini yitirmiş veya başka şekilde yanlış olabilir ve yetkili olarak değerlendirilmemelidir. Ancak, Stack Exchange Soru-Cevap topluluklarının yanı sıra Linux'ta AdamW ve daha fazlası ve blogu onaylama gibi sitelerde faydalı bilgilere ulaşabilirsiniz.
Lütfen Google Güven Hizmetleri ile ilgili SSS sayfasına da göz atın.
Sertifika sabitleme gibi gelişmiş konular hakkında daha ayrıntılı bilgi için Open Web Application Security Project (OWASP) Sertifika ve Ortak Anahtar Sabitleme
makalesini ve Sabitleme Hile Sayfası 'nı bilgilendirici bulabilirsiniz. Android'e özel talimatlar için lütfen Android Güvenlik ve Gizlilik İçin En İyi Uygulamalar
HTTPS ve SSL ile güvenlik eğitim dokümanına bakın. Android'de sertifika ve ortak anahtar sabitleme hakkında
tartışmak için Matthew Dolan'ın blog gönderisi
Android Güvenlik: SSL Sabitleme
sizin için yararlı olabilir.
Android Güvenlik ve Gizlilik İçin En İyi Uygulamalar Ağ Güvenliği Yapılandırması eğitim dokümanı ve JeroenHD'nin blog yayını
Android 7 Nougat ve sertifika yetkilileri
Android'de ek güvenilir sertifikaları yönetme hakkında daha fazla bilgi sağlar.
AOSP tarafından güvenilen kök CA'ların kapsamlı bir listesi için ca-certificates Git deposuna bakın. Resmi olmayan Android çatallarını temel alan tüm sürümler (ör. LineageOS) için OS sağlayıcısı tarafından sağlanan ilgili veri havuzlarına bakın.