FAQ Migrasi Root CA Google Maps Platform

Dokumen ini berisi bagian-bagian berikut:

Untuk ringkasan yang lebih terperinci tentang migrasi root CA Google yang sedang berlangsung, lihat Apa yang terjadi?.

Terminologi

Di bawah ini, kami telah mengumpulkan daftar istilah paling penting yang perlu Anda ketahui untuk dokumen ini. Untuk mendapatkan ringkasan yang lebih komprehensif tentang istilah terkait, buka FAQ Layanan Kepercayaan Google.

Sertifikat SSL/TLS
Sertifikat mengikat kunci kriptografis ke identitas.
Sertifikat SSL/TLS digunakan untuk mengautentikasi dan membuat koneksi yang aman ke situs. Sertifikat diterbitkan dan ditandatangani secara kriptografis oleh entitas yang dikenal sebagai Certificate Authority.
Browser menggunakan sertifikat yang diterbitkan oleh Certificate Authority tepercaya untuk mengetahui bahwa informasi yang ditransmisikan dikirim ke server yang benar dan dienkripsi saat transit.
Secure Socket Layer (SSL)
Secure Socket Layer adalah protokol yang paling banyak di-deploy dan digunakan untuk mengenkripsi komunikasi internet. Protokol SSL tidak lagi dianggap aman dan tidak boleh digunakan.
Transport Layer Security (TLS)
Transport Layer Security adalah pengganti SSL.
Certificate Authority (CA)
Certificate Authority mirip seperti kantor paspor digital untuk perangkat dan orang. Certificate Authority akan menerbitkan dokumen (sertifikat) yang dilindungi secara kriptografis untuk membuktikan kebenaran klaim suatu entity (misalnya, situs).
Sebelum menerbitkan Sertifikat, CA bertanggung jawab untuk memastikan bahwa nama dalam Sertifikat terkait dengan orang atau entity yang memintanya.
Istilah Certificate Authority dapat merujuk ke organisasi seperti Layanan Kepercayaan Google, dan ke sistem yang menerbitkan sertifikat.
Penyimpanan root certificate
Penyimpanan root certificate berisi kumpulan Certificate Authority yang dipercaya oleh Penyedia Software Aplikasi. Sebagian besar browser web dan sistem operasi memiliki penyimpanan root certificate sendiri.
Agar dapat disertakan dalam penyimpanan root certificate, Certificate Authority harus memenuhi persyaratan ketat yang ditetapkan oleh Penyedia Software Aplikasi.
Biasanya persyaratan ini mencakup kepatuhan terhadap standar industri seperti persyaratan Forum Browser/CA.
Root Certificate Authority
Root Certificate Authority (atau lebih tepatnya, sertifikatnya) adalah sertifikat teratas dalam rantai sertifikat.
Sertifikat root CA biasanya ditandatangani sendiri. Kunci pribadi yang terkait dengan sertifikat root CA disimpan di fasilitas yang sangat aman, dan dikelola secara offline untuk melindunginya dari akses yang tidak sah.
Intermediate Certificate Authority
Intermediate Certificate Authority (atau lebih tepatnya, sertifikatnya) adalah sertifikat yang digunakan untuk menandatangani sertifikat lain dalam rantai sertifikat.
Intermediate CA terutama tersedia untuk memungkinkan penerbitan sertifikat online sekaligus mengizinkan sertifikat Root CA tetap offline.
Intermediate CA juga dikenal sebagai Subordinate CA.
Issuing Certificate Authority
Issuing Certificate Authority (atau lebih tepatnya, sertifikatnya) adalah sertifikat yang digunakan untuk menandatangani sertifikat paling bawah dalam rantai sertifikat.
Sertifikat yang paling bawah ini biasanya disebut sertifikat pelanggan, sertifikat entity akhir, atau leaf certificate. Dalam dokumen ini, kami juga akan menggunakan istilah sertifikat server.
Rantai sertifikat
Sertifikat ditautkan ke (ditandatangani secara kriptografis oleh) penerbitnya. Rantai sertifikat dibuat dari leaf-certificate, semua sertifikat penerbitnya, dan root certificate.
Penandatanganan silang
Klien Penyedia Software Aplikasi harus memperbarui penyimpanan root certificate-nya untuk menyertakan sertifikat CA baru agar dapat dipercaya oleh produknya. Perlu waktu agak lama hingga produk yang berisi sertifikat CA baru digunakan secara luas.
Untuk meningkatkan kompatibilitas dengan klien lama, sertifikat CA dapat "ditandatangani silang" oleh CA lama lainnya yang pernah digunakan. Hal ini pada dasarnya membuat sertifikat CA kedua untuk identitas yang sama (nama & pasangan kunci).
Bergantung pada CA yang disertakan dalam penyimpanan root certificate-nya, klien akan membuat rantai sertifikat yang berbeda hingga root yang dipercayai klien tersebut.

Informasi umum

Apa yang terjadi?

Gambaran besarnya

Pada tahun 2017, Google memulai project multi-tahun untuk menerbitkan dan menggunakan root certificate miliknya sendiri, yaitu tanda tangan kriptografis yang menjadi dasar keamanan internet TLS yang digunakan oleh HTTPS.

Setelah fase pertama, keamanan TLS layanan Google Maps Platform telah dijamin oleh GS Root R2, sebuah root certificate authority (CA) yang dikenal luas dan tepercaya, yang diperoleh Google dari GMO GlobalSign untuk memudahkan transisi ke root CA Layanan Kepercayaan Google (GTS) yang kami terbitkan sendiri.

Pada dasarnya, semua klien TLS (seperti browser Web, smartphone, dan server aplikasi) telah memercayai root certificate ini, sehingga dapat membuat koneksi yang aman ke server Google Maps Platform selama fase pertama migrasi.

Namun, CA tidak dapat dengan sengaja menerbitkan sertifikat yang berlaku setelah masa berlaku sertifikatnya sendiri habis. Karena masa berlaku GS Root R2 akan berakhir pada 15 Desember 2021, Google akan memigrasikan layanannya sendiri ke CA baru, GTS Root R1 Cross, menggunakan sertifikat yang diterbitkan oleh root CA milik Google sendiri, GTS Root R1.

Meskipun sebagian besar sistem operasi modern dan library klien TLS sudah memercayai root CA GTS, untuk memastikan transisi yang lancar bagi sebagian besar sistem lama, Google telah memperoleh penandatanganan silang dari GMO GlobalSign menggunakan Root CA GlobalSign - R1, salah satu root CA paling lama dan paling tepercaya yang saat ini tersedia.

Oleh karena itu, sebagian besar klien Google Maps Platform pelanggan sudah mengenali salah satu (atau kedua) root CA tepercaya ini, dan sama sekali tidak akan terpengaruh oleh fase kedua migrasi.

Hal ini juga berlaku untuk pelanggan yang mengambil tindakan selama fase pertama migrasi pada tahun 2018, dengan asumsi bahwa pada saat itu mereka mengikuti petunjuk kami, yaitu menginstal semua sertifikat dari paket root CA Google tepercaya.

Anda harus memverifikasi sistem jika hal berikut berlaku:

  • layanan Anda menjalankan platform lama atau non-standar dan/atau Anda mengelola penyimpanan root certificate sendiri
  • Anda tidak mengambil tindakan pada tahun 2017-2018, selama fase pertama migrasi root CA Google, atau Anda tidak menginstal kumpulan lengkap sertifikat dari paket root CA Google tepercaya

Jika hal di atas berlaku, klien Anda mungkin perlu diupdate dengan root certificate yang direkomendasikan agar dapat memastikan penggunaan Google Maps Platform tanpa gangguan selama fase migrasi ini.

Lihat di bawah untuk detail teknis lebih lanjut. Untuk petunjuk umum, lihat bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan.

Sebaiknya pastikan penyimpanan root certificate Anda tetap sinkron dengan paket root CA yang diseleksi di atas agar layanan Anda siap untuk menghadapi perubahan root CA di masa mendatang. Namun, hal ini akan diumumkan di awal. Lihat bagian Bagaimana cara mendapatkan informasi terbaru tentang fase migrasi ini? dan Bagaimana cara mendapatkan pemberitahuan awal tentang migrasi mendatang? untuk petunjuk lebih lanjut tentang cara mendapatkan informasi terbaru.

Ringkasan teknis

Seperti yang diumumkan pada 15 Maret 2021 di Blog Keamanan Google, GS Root R2, root CA yang telah digunakan Google Maps Platform sejak awal tahun 2018 akan berakhir masa berlakunya pada 15 Desember 2021. Oleh karena itu, tahun ini Google akan bermigrasi ke CA yang baru diterbitkan, GTS Root R1 Cross. Artinya, layanan kami akan secara bertahap bertransisi ke leaf certificate TLS yang diterbitkan oleh CA baru ini.

Hampir semua klien dan sistem TLS modern sudah dikonfigurasi sebelumnya dengan sertifikat GTS Root R1 atau akan menerimanya melalui update software normal, dan Root CA GlobalSign - R1 seharusnya juga tersedia di sistem lama.

Namun, Anda harus memverifikasi sistem setidaknya jika kedua hal berikut berlaku:

  • layanan Anda berjalan di platform lama atau non-standar dan/atau Anda mengelola penyimpanan root certificate sendiri
  • Anda tidak mengambil tindakan pada tahun 2017-2018, selama fase pertama migrasi root CA Google, atau Anda tidak menginstal kumpulan lengkap sertifikat dari paket root CA Google tepercaya

Bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan menyediakan panduan umum untuk menguji apakah sistem Anda akan terpengaruh.

Lihat pertanyaan Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya? untuk mengetahui detail selengkapnya.

Bagaimana cara mendapatkan informasi terbaru tentang fase migrasi ini?

Bintangi masalah umum 186840968 untuk mengetahui informasi terbaru. FAQ ini juga diperbarui selama proses migrasi, setiap kali kami menemukan topik yang mungkin sesuai dengan kepentingan umum.

Bagaimana cara mendapatkan pemberitahuan awal tentang migrasi mendatang?

Sebaiknya ikuti Blog Keamanan Google. Kami juga akan berusaha untuk memperbarui dokumentasi khusus produk secepatnya, mengikuti pengumuman publik di blog tersebut.

Anda juga dapat berlangganan Notifikasi Google Maps Platform, karena kami secara rutin memposting info terbaru di forum tentang perubahan yang kemungkinan akan memengaruhi sejumlah besar pelanggan.

Kami menggunakan beberapa layanan Google. Apakah migrasi root CA akan memengaruhi semuanya?

Ya, migrasi root CA akan terjadi di semua API dan layanan Google, tetapi waktunya mungkin berbeda untuk setiap layanan. Namun, setelah Anda memverifikasi bahwa penyimpanan root certificate yang digunakan oleh aplikasi klien Google Maps Platform Anda berisi semua CA yang tercantum dalam paket root CA Google tepercaya, layanan Anda tidak akan terpengaruh oleh migrasi yang sedang berlangsung, dan memastikan keduanya tetap sinkron juga akan melindungi Anda dari perubahan root CA di masa mendatang.

Lihat pertanyaan Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya? dan Jenis aplikasi apa yang berisiko mengalami error? untuk mengetahui insight selengkapnya.

Bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan di bawah juga menyediakan petunjuk umum untuk menguji sistem Anda.

Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan

Uji lingkungan aplikasi Anda terhadap endpoint pengujian yang tercantum di bawah:

  • Jika Anda dapat menghubungkan TLS ke endpoint pengujian GTS Root R1 Cross, Anda seharusnya tidak akan terpengaruh oleh berakhirnya masa berlaku GS Root R2.
  • Jika Anda dapat menghubungkan TLS ke endpoint pengujian GTS Root R1, aplikasi Anda kemungkinan akan terlindung dari berakhirnya masa berlaku GTS Root R1 Cross dan Root CA GlobalSign - R1 pada tahun 2028.

Sistem Anda umumnya akan kompatibel dengan perubahan root CA ini jika:

  • layanan Anda berjalan pada sistem operasi umum yang dikelola, dan Anda telah memastikan sistem operasi dan library yang digunakan oleh layanan Anda selalu diperbaiki, dan Anda tidak mengelola penyimpanan root certificate sendiri, atau:
  • Anda mengikuti rekomendasi kami sebelumnya, dan menginstal semua root CA dari paket root CA Google tepercaya

Pelanggan yang mungkin terpengaruh harus segera menginstal sertifikat dari paket root CA Google tepercaya untuk menghindari gangguan layanan di masa mendatang.

Lihat pertanyaan Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya? untuk mengetahui detail selengkapnya.

Apakah ada alat sederhana yang dapat saya gunakan untuk memverifikasi penyimpanan root certificate?

Anda dapat memanfaatkan dua alat command line curl dan openssl dalam investigasi. Kedua alat tersebut tersedia di sebagian besar platform, dan menawarkan berbagai opsi untuk menguji penyiapan Anda.

Untuk mengetahui petunjuk cara mendapatkan curl, lihat bagian Mendapatkan curl di bawah.

Perintah openssl yang ditampilkan di bawah ini adalah untuk versi 1.1.1 atau yang lebih baru. Versi sebelum 1.1.1 tidak lagi didukung. Jika Anda menggunakan versi yang lebih lama, upgrade atau ubah perintah ini sesuai kebutuhan untuk versi Anda. Untuk mengetahui petunjuk cara mendapatkan openssl, lihat bagian Mendapatkan OpenSSL di bawah.

Anda juga akan menemukan lebih banyak alat yang bermanfaat di bagian Di mana saya bisa mendapatkan alat yang saya butuhkan? di bawah.

Untuk petunjuk pengujian yang konkret, lihat bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan.

Menguji penyimpanan root certificate default

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;

Memverifikasi paket root CA Google tepercaya

Download paket root CA Google tepercaya, lalu ikuti langkah-langkah berikut:

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

Bagaimana dan kapan migrasi root CA Google akan dilanjutkan?

  1. Fase pertama (migrasi ke GS Root R2), diumumkan pada Januari 2017, dimulai pada akhir 2017 dan ditutup pada paruh pertama 2018.
  2. Fase kedua (migrasi ke GTS Root R1 Cross) telah diumumkan pada Maret 2021, dan diluncurkan dalam beberapa bulan berikutnya, sebelum berakhirnya masa berlaku GS root R2 pada 15 Desember 2021.

Jadwal fase migrasi berikutnya akan diumumkan jauh sebelum berakhirnya masa berlaku sertifikat mendatang.

Namun, Anda dapat memastikan aplikasi Anda siap menghadapi masa depan, jika penyimpanan root certificate Anda tetap sinkron dengan daftar pilihan root CA di paket root CA Google tepercaya.

Lihat juga pertanyaan Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya? untuk memahami latar belakangnya.

Rencana peluncuran umum untuk setiap layanan Google

  1. Peluncuran bertahap dimulai di satu pusat data.
  2. Peluncuran ini akan diperluas secara bertahap ke lebih banyak pusat data hingga mencapai cakupan global.
  3. Jika masalah serius terdeteksi di suatu tahap, pengujian dapat di-roll back untuk sementara selagi masalah tersebut ditangani.
  4. Berdasarkan input dari iterasi sebelumnya, layanan Google selanjutnya akan disertakan dalam peluncuran hingga semua layanan Google secara bertahap dimigrasikan ke sertifikat baru.

Siapa yang akan terpengaruh, kapan, dan di mana?

Sejumlah besar developer Google Maps Platform akan mulai menerima sertifikat baru saat pusat data baru dimigrasikan. Perubahan akan dilokalkan, karena permintaan klien cenderung diteruskan ke server di pusat data yang terdekat secara geografis.

Karena kami tidak dapat mengetahui dengan pasti siapa yang akan terpengaruh, kapan, dan di mana, sebaiknya semua pelanggan sudah memverifikasi dan mempersiapkan layanannya untuk menghadapi perubahan yang akan datang, jauh sebelum kemungkinan fase migrasi root CA Google.

Lihat bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan untuk mendapatkan panduan tambahan.

Yang perlu diperhatikan

Klien yang tidak dikonfigurasi dengan root certificate yang diperlukan tidak akan dapat memverifikasi koneksi TLS-nya ke Google Maps Platform. Dalam situasi ini, klien biasanya akan mengeluarkan peringatan bahwa validasi sertifikat gagal.

Bergantung pada konfigurasi TLS-nya, klien dapat terus mengirimkan permintaan ke Google Maps Platform, atau klien dapat menolak untuk mengirimkan permintaan tersebut.

Apa saja persyaratan minimum bagi klien TLS untuk berkomunikasi dengan Google Maps Platform?

Sertifikat Google Maps Platform menggunakan Nama Alternatif Subjek (SAN) DNS, sehingga penanganan sertifikat klien harus dapat mendukung SAN yang mungkin menyertakan karakter pengganti tunggal sebagai label paling kiri dalam nama, seperti *.googleapis.com.

Untuk persyaratan lainnya, lihat bagian Apa persyaratan yang direkomendasikan bagi klien TLS untuk berkomunikasi dengan Google? di FAQ GTS.

Jenis aplikasi apa yang berisiko mengalami error?

Aplikasi yang menggunakan penyimpanan root certificate sistem tanpa batasan yang diberlakukan oleh developer

Aplikasi layanan web Google Maps Platform

Jika Anda menggunakan OS umum, misalnya, Ubuntu, Red Hat, Windows 10, atau Server 2019, OS X) yang masih dikelola dan menerima update rutin, penyimpanan root certificate default Anda seharusnya sudah menyertakan sertifikat GTS Root R1.

Jika Anda menggunakan versi OS lama yang tidak lagi menerima update, Anda mungkin memiliki atau tidak memiliki sertifikat GTS Root R1. Namun, penyimpanan root certificate Anda kemungkinan besar akan berisi Root CA GlobalSign - R1, salah satu root CA terlama dan paling banyak dipercaya.

Untuk aplikasi seluler yang memanggil layanan web Google Maps Platform langsung dari perangkat pengguna akhir, pedoman dari pertanyaan Apakah aplikasi seluler berisiko mengalami error? dapat digunakan.

Aplikasi Google Maps Platform sisi klien

Aplikasi Maps JavaScript API umumnya mengandalkan root certificate browser web yang menjalankan aplikasi. Lihat bagian Apakah aplikasi JavaScript berisiko mengalami error? untuk mengetahui detail lebih lanjut.

Untuk aplikasi seluler native yang menggunakan Maps SDK for Android, Maps SDK for iOS, Places SDK for Android, atau Places SDK for iOS, aturan yang sama berlaku untuk aplikasi yang memanggil layanan web Google Maps Platform.

Lihat pertanyaan Apakah aplikasi seluler berisiko mengalami error? untuk mengetahui detail selengkapnya.

Aplikasi yang menggunakan paket sertifikat sendiri atau menggunakan fitur keamanan lanjutan, seperti penyematan sertifikat

Pastikan Anda memperbarui paket sertifikat Anda sendiri. Seperti yang telah dibahas dalam pertanyaan Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya?, sebaiknya impor semua sertifikat dari paket root CA Google tepercaya ke penyimpanan root certificate Anda sendiri.

Jika Anda menyematkan sertifikat atau kunci publik untuk domain Google yang terhubung dengan aplikasi Anda, Anda harus menambahkan sertifikat dan kunci publik ke daftar entitas tepercaya dalam aplikasi Anda.

Untuk informasi lebih lanjut tentang penyematan sertifikat atau kunci publik, lihat referensi eksternal yang tercantum pada pertanyaan Perlu info lebih lanjut?.

Mengapa penyimpanan root certificate saya harus tetap sinkron dengan paket root CA Google tepercaya?

Daftar pilihan root CA dalam paket root CA Google tepercaya mencakup semua CA yang mungkin digunakan oleh layanan Google pada masa mendatang.

Oleh karena itu, jika ingin sistem Anda siap menghadapi masa depan, sebaiknya Anda memastikan bahwa penyimpanan root certificate Anda berisi semua sertifikat dari paket, dan secara rutin memastikan keduanya tetap sinkron.

Hal ini penting terutama jika layanan Anda berjalan pada versi sistem operasi yang tidak dikelola, jika karena alasan lain Anda tidak dapat memastikan sistem operasi dan library selalu diperbaiki, atau jika Anda mengelola penyimpanan root certificate milik sendiri.

Lihat pertanyaan Bagaimana cara mendapatkan pemberitahuan awal tentang migrasi mendatang? untuk mengetahui cara mendapatkan informasi terbaru tentang migrasi root CA mendatang. Dengan secara rutin memastikan penyimpanan root certificate Anda tetap sinkron dengan daftar pilihan, layanan Anda akan terlindungi dari gangguan layanan di masa mendatang karena perubahan CA, dan layanan Anda akan dapat tetap berjalan setelah berakhirnya masa berlaku GTS Root R1 Cross dan Root CA GlobalSign - R1.

Selain itu, lihat pertanyaan Saya membuat produk yang terhubung ke layanan Google. Sertifikat CA apa yang perlu saya percayai? di FAQ GTS untuk rekomendasi lebih lanjut.

Mengapa saya tidak boleh menginstal sertifikat leaf atau intermediate CA?

Jika dilakukan, aplikasi akan berisiko mengalami error saat kami mendaftarkan sertifikat baru, atau mengganti intermediate CA. Kedua hal ini dapat terjadi kapan saja dan tanpa pemberitahuan sebelumnya, serta berlaku untuk setiap sertifikat server, seperti yang ditampilkan oleh maps.googleapis.com, serta setiap intermediate CA kami, seperti GTS Root R1 Cross.

Untuk melindungi layanan Anda dari hal ini, sebaiknya Anda hanya menginstal root certificate dari paket root CA Google tepercaya, dan hanya menggunakan root certificate untuk memverifikasi ketepercayaan seluruh rantai sertifikat yang didasarkan padanya.

Setiap penerapan library TLS modern harus dapat memverifikasi rantai kepercayaan tersebut secara otomatis, selama root certificate authority tepercaya.

Apakah aplikasi JavaScript berisiko mengalami error?

Root certificate GTS sudah disematkan dengan baik dan dipercaya oleh sebagian besar browser modern, dan penandatanganan silang dari GMO GlobalSign akan memastikan kelancaran migrasi bahkan bagi sebagian besar pengguna akhir yang menggunakan browser lama. Hal ini mencakup semua browser yang didukung secara resmi untuk Maps JavaScript API.

Setiap browser modern harus memungkinkan pengguna akhir memverifikasi dan biasanya mengedit sertifikat yang dipercayai browser. Meski lokasi persisnya berbeda di setiap browser, daftar sertifikat biasanya dapat ditemukan di bagian Setelan.

Apakah aplikasi seluler berisiko mengalami error?

Perangkat Android dan Apple iOS yang masih menerima update rutin dari produsen perangkat juga diharapkan siap untuk menghadapi masa depan. Sebagian besar ponsel Android model lama menyertakan setidaknya sertifikat Root CA GlobalSign - R1, meskipun jika daftar sertifikat tepercaya dapat bervariasi untuk setiap produsen handset, model perangkat, dan versi Android.

Namun, dukungan untuk root CA GTS, termasuk GTS Root R1 mungkin masih terbatas pada versi Android sebelum versi 10.

Untuk perangkat iOS, Apple menyimpan daftar root CA tepercaya untuk setiap versi iOS terbaru di halaman dukungannya. Namun, semua iOS versi 5 dan yang lebih baru mendukung Root CA GlobalSign - R1.

Root CA GTS, termasuk GTS Root R1 telah didukung sejak iOS versi 12.1.3.

Lihat pertanyaan Bagaimana cara memeriksa root certificate tepercaya di ponsel saya? untuk mengetahui detail lebih lanjut.

Kapan browser atau sistem operasi saya menyertakan root certificate Layanan Kepercayaan Google?

Selama bertahun-tahun, Google telah bekerja sama secara intensif dengan semua pihak ketiga utama yang mengelola paket root certificate yang digunakan secara luas dan tepercaya. Contohnya meliputi produsen sistem operasi, seperti Apple dan Microsoft, dan juga tim Android serta ChromeOS milik Google; developer browser, seperti Mozilla, Apple, Microsoft, dan juga tim Chrome milik Google; produsen hardware, seperti ponsel, dekoder, TV, konsol game, printer, dll.

Oleh karena itu, sangat mungkin bahwa sistem yang dikelola saat ini sudah mendukung root CA GTS Google yang baru, termasuk GTS Root R1, dan bahkan sistem lama kemungkinan besar mendukung Root CA GlobalSign - R1, yang akan digunakan untuk penandatanganan silang sertifikat yang diterbitkan Google hingga beberapa tahun mendatang.

Namun karena jadwal penyertaan sertifikat pihak ketiga berada di luar kendali Google, saran terbaik yang dapat kami berikan adalah memastikan Anda secara rutin menerapkan update sistem yang tersedia.

Pihak ketiga tertentu, seperti Program Sertifikat CA Mozilla, mungkin telah mendokumentasikan jadwal penyertaan sertifikat sendiri.

Pemecahan masalah

Di mana saya bisa mendapatkan alat yang saya butuhkan?

Mendapatkan curl

Jika distribusi OS Anda tidak menyediakan curl, Anda dapat mendownloadnya dari https://curl.haxx.se/. Anda dapat mendownload sumber dan mengompilasi alat tersebut sendiri atau mendownload biner yang telah dikompilasi sebelumnya, jika tersedia untuk platform Anda.

Mendapatkan OpenSSL

Jika distribusi OS Anda tidak menyediakan openssl, Anda dapat mendownload sumber dari https://www.openssl.org/ dan mengompilasi alat tersebut. Daftar biner yang dibuat oleh pihak ketiga dapat dilihat melalui https://www.openssl.org/community/binaries.html. Namun, build ini tidak didukung atau dengan cara tertentu direkomendasikan oleh tim OpenSSL.

Mendapatkan Wireshark, Tshark, atau Tcpdump

Meskipun sebagian besar distribusi Linux menawarkan wireshark, alat command line-nya tshark dan tcpdump, versi yang telah dikompilasi sebelumnya dari dua versi pertama untuk OS lain dapat ditemukan di https://www.wireshark.org.

Kode sumber untuk Tcpdump dan LibPCAP dapat ditemukan di https://www.tcpdump.org.

Dokumentasi untuk alat-alat yang berguna ini dapat ditemukan di Panduan Pengguna Wireshark, halaman utama Tshark, dan halaman utama Tcpdump.

Mendapatkan keytool Java

Alat command line keytool seharusnya dikirimkan bersama dengan setiap versi Java Development Kit (JDK) atau Java Runtime Environment (JRE). Instal semuanya untuk mendapatkan keytool. Namun, penggunaan keytool mungkin tidak diperlukan untuk verifikasi root certificate, kecuali jika aplikasi Anda dibuat menggunakan Java.

Apa yang harus dilakukan saat terjadi penonaktifan produksi

Tindakan utama yang harus Anda lakukan adalah menginstal root certificate yang diperlukan dari paket root CA Google tepercaya ke dalam penyimpanan root certificate yang digunakan aplikasi Anda.

  1. Bekerja sama dengan administrator sistem untuk mengupgrade penyimpanan root certificate lokal Anda.
  2. Lihat FAQ ini untuk mengetahui pointer yang berlaku untuk sistem Anda.
  3. Jika Anda memerlukan bantuan khusus platform atau sistem lebih lanjut, hubungi saluran dukungan teknis yang disediakan oleh penyedia sistem Anda.
  4. Untuk mendapatkan bantuan umum, hubungi tim dukungan kami, seperti yang dijelaskan di bagian Menghubungi dukungan Google Maps Platform. Catatan: Untuk masalah khusus platform, panduan hanya diberikan sesuai dengan kemampuan terbaik kami.
  5. Bintangi masalah umum 186840968 untuk mengetahui informasi terbaru tentang migrasi.

Menghubungi dukungan Google Maps Platform

Pemecahan masalah awal

Lihat bagian Cara memastikan apakah penyimpanan root certificate saya memerlukan pembaruan untuk petunjuk pemecahan masalah umum.

Bagian Mengelola sertifikat tepercaya Anda juga dapat memberikan informasi penting, jika Anda perlu mengimpor atau mengekspor root certificate.

Jika masalah tidak terselesaikan, dan Anda memutuskan untuk menghubungi dukungan Google Maps Platform, siapkan juga informasi berikut:

  1. Di mana lokasi server Anda yang terpengaruh?
  2. Alamat IP Google mana yang dipanggil oleh layanan Anda?
  3. API mana yang terpengaruh oleh masalah ini?
  4. Kapan masalah mulai muncul?

  5. Output dari perintah berikut:

    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;

Untuk mengetahui petunjuk cara mendapatkan alat yang diperlukan, lihat pertanyaan Di mana saya bisa mendapatkan alat yang saya butuhkan?.

Mengajukan kasus dukungan

Ikuti petunjuk untuk Membuat kasus dukungan di bagian Referensi dan Dukungan Google Maps Platform.

Saat mengajukan kasus dukungan, selain data yang tercantum di bagian Pemecahan masalah awal, berikan juga informasi berikut:

  • Apa alamat IP publik Anda?
  • Apa alamat IP publik server DNS Anda?
  • Jika memungkinkan, gambar paket tcpdump atau Wireshark dari negosiasi TLS yang gagal terhadap https://maps.googleapis.com/ dalam format PCAP, menggunakan panjang snapshot yang memadai untuk menangkap seluruh paket tanpa terpotong (misalnya menggunakan -s0 pada versi lama tcpdump).
  • Jika memungkinkan, nukilan log dari layanan Anda yang menunjukkan alasan persisnya kegagalan koneksi TLS, sebaiknya sertakan juga informasi rantai sertifikat server yang lengkap.

Untuk mengetahui petunjuk cara mendapatkan alat yang diperlukan, lihat pertanyaan Di mana saya bisa mendapatkan alat yang saya butuhkan?.

Memposting tentang masalah umum 186840968

Saat memposting komentar tentang masalah umum 186840968, sertakan informasi yang tercantum di bagian Pemecahan masalah awal.

Bagaimana cara menentukan alamat publik DNS saya?

Di Linux, Anda dapat menjalankan perintah berikut:

dig -t txt o-o.myaddr.l.google.com

Di Windows, Anda dapat menggunakan nslookup dalam mode interaktif:

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

Cara menafsirkan output curl

Menjalankan curl dengan tanda -vvI akan memberikan banyak informasi berguna. Berikut ini beberapa petunjuk untuk menafsirkan output:

  • Baris yang dimulai dengan '*' menampilkan output dari negosiasi TLS, serta informasi penghentian koneksi.
  • Baris yang dimulai dengan '>' menampilkan permintaan HTTP keluar yang dikirim curl.
  • Baris yang diawali dengan '<' menampilkan respons HTTP yang diperoleh dari server.
  • Jika protokolnya adalah HTTPS, keberadaan baris '>' atau '<' menandakan handshake TLS berhasil.

Library TLS dan paket root certificate yang digunakan

Menjalankan curl dengan tanda -vvI juga akan mencetak penyimpanan root certificate yang digunakan, tetapi output persisnya dapat bervariasi untuk setiap sistem seperti yang ditunjukkan di sini.

Output dari mesin Red Hat Linux dengan curl yang ditautkan ke NSS dapat berisi baris berikut:

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

Output dari mesin Ubuntu atau Debian Linux dapat berisi baris berikut: 

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

Output dari mesin Ubuntu atau Debian Linux menggunakan file PEM root certificate Google yang diberikan menggunakan tanda --cacert dapat berisi baris berikut:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

Agen pengguna

Permintaan keluar berisi header Agen Pengguna yang mungkin memberikan informasi berguna tentang curl dan sistem Anda.

Contoh dari mesin Red Hat Linux:

> 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: */*
>

Handshake TLS gagal

Baris seperti yang ada di contoh kode ini menunjukkan bahwa koneksi diakhiri di tengah handshake TLS karena sertifikat server tidak tepercaya. Tidak adanya output debug yang dimulai dengan > atau < juga merupakan indikator kuat gagalnya koneksi:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

Handshake TLS berhasil

TLS handshake yang berhasil ditunjukkan dengan adanya baris yang mirip dengan yang terlihat di contoh kode ini. Cipher suite yang digunakan untuk koneksi yang dienkripsi harus dicantumkan, begitu juga detail sertifikat server yang diterima. Selain itu, adanya baris yang dimulai dengan > atau < menunjukkan bahwa traffic HTTP payload berhasil dikirim melalui koneksi yang dienkripsi TLS:

*   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
…

Cara mencetak sertifikat server yang diterima dalam bentuk yang dapat dibaca manusia

Dengan menganggap output berformat PEM, misalnya, output dari openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, Anda dapat mencetak sertifikat yang disajikan dengan mengikuti langkah-langkah berikut ini:

  • Salin seluruh sertifikat yang dienkode ke Base 64, termasuk header dan footer:

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

  • Kemudian, jalankan perintah:

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

  • lalu tempel konten buffer salinan ke terminal.

  • Tekan tombol Return.

Untuk contoh input dan output, lihat bagian Cara mencetak sertifikat PEM dalam bentuk yang dapat dibaca manusia.

Seperti apa tampilan sertifikat Google yang ditandatangani silang di OpenSSL?

…
---
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

---
…

Mengelola sertifikat tepercaya Anda

Bagaimana cara memeriksa root certificate tepercaya di ponsel saya?

Sertifikat tepercaya Android

Seperti yang disebutkan dalam pertanyaan Apakah aplikasi seluler berisiko mengalami error?, Android mulai versi 4.0 memungkinkan pengguna handset memverifikasi daftar sertifikat tepercaya di Setelan. Tabel ini menunjukkan jalur menu Setelan yang tepat:

Versi Android Jalur menu
1.x, 2.x, 3.x T/A
4.x, 5.x, 6.x, 7.x Setelan > Keamanan > Kredensial tepercaya
8.x, 9 Setelan > Keamanan & Lokasi > Enkripsi & kredensial > Kredensial tepercaya
10+ Setelan > Keamanan > Lanjutan > Enkripsi & kredensial > Kredensial tepercaya

Tabel di bawah ini mengilustrasikan kemungkinan ketersediaan root certificate yang paling penting untuk setiap versi Android, berdasarkan verifikasi manual menggunakan image sistem Perangkat Virtual Android (AVD) yang saat ini tersedia, kembali menggunakan histori versi repositori Git sertifikat CA AOSP saat image sistem tidak lagi tersedia:

Versi Android GTS Root R1 Root CA GlobalSign - R1 GlobalSign Root R2 (berlaku hingga 15 Desember 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Memperbarui penyimpanan root certificate sistem Android biasanya tidak dapat dilakukan tanpa update firmware atau rooting perangkat. Namun, pada sebagian besar versi Android yang masih banyak digunakan, kumpulan root certificate tepercaya saat ini kemungkinan akan memberikan layanan tanpa gangguan selama beberapa tahun ke depan, melebihi masa pakai efektif sebagian besar perangkat yang ada sekarang.

Mulai versi 7.0, Android menawarkan metode yang aman bagi developer aplikasi untuk menambahkan sertifikat tepercaya yang hanya dipercaya oleh aplikasi mereka. Hal ini dilakukan dengan memaketkan sertifikat dengan aplikasi dan membuat konfigurasi keamanan jaringan khusus, seperti yang dijelaskan dalam dokumen pelatihan Praktik Terbaik Android untuk Keamanan & Privasi Konfigurasi Keamanan Jaringan.

Namun, karena developer aplikasi pihak ketiga tidak akan dapat memengaruhi konfigurasi keamanan jaringan traffic yang berasal dari APK Layanan Google Play, paya tersebut tidak akan sepenuhnya menyelesaikan masalah.

Pada perangkat lama, opsi yang tersedia hanya menggunakan CA yang ditambahkan pengguna, baik yang diinstal oleh kebijakan grup perusahaan yang diterapkan pada perangkat pengguna akhir, atau oleh pengguna akhir itu sendiri.

Trust Store iOS

Meskipun Apple tidak secara langsung menampilkan kumpulan default root certificate tepercaya kepada pengguna handset, perusahaan tersebut memiliki link ke kumpulan root CA tepercaya untuk iOS versi 5 dan yang lebih baru dari artikel Dukungan Apple:

Namun, semua sertifikat tambahan yang diinstal di perangkat iOS dapat dilihat di Setelan > Umum > Profil. Jika tidak ada sertifikat tambahan yang diinstal, item menu Profile mungkin tidak akan ditampilkan.

Tabel di bawah ini mengilustrasikan ketersediaan root certificate yang paling penting untuk setiap versi iOS, berdasarkan sumber di atas:

Versi iOS GTS Root R1 Root CA GlobalSign - R1 GlobalSign Root R2 (berlaku hingga 15 Desember 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Di mana penyimpanan root certificate sistem saya dan bagaimana cara memperbaruinya?

Lokasi penyimpanan root certificate default berbeda-beda bergantung pada sistem operasi dan library SSL/TLS yang digunakan. Namun, pada sebagian besar distribusi Linux, root certificate default dapat ditemukan di salah satu jalur berikut:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, versi lebih lama dari RHEL dan CentOS
  • /etc/pki/ca-trust/source/anchors dan /usr/share/pki/ca-trust-source: Fedora, versi lebih baru dari RHEL dan CentOS
  • /var/lib/ca-certificates: OpenSUSE

Jalur sertifikat lainnya dapat mencakup:

  • /etc/ssl/certs: Debian, Ubuntu
  • /etc/pki/tls/certs: RHEL, CentOS

Sebagian sertifikat di direktori ini kemungkinan berupa link simbolis ke file di direktori lain.

Penyimpanan root certificate OpenSSL

Untuk aplikasi yang menggunakan OpenSSL, Anda dapat memeriksa lokasi yang dikonfigurasi dari komponen yang diinstal, termasuk penyimpanan root certificate default menggunakan perintah berikut:

openssl version -d

Perintah tersebut mencetak OPENSSLDIR, yang sesuai dengan direktori tingkat teratas di library dan konfigurasinya dapat ditemukan di:

OPENSSLDIR: "/usr/lib/ssl"

Penyimpanan root certificate terletak di subdirektori certs.

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
…

Jika OpenSSL menggunakan penyimpanan root certificate sistem default seperti pada contoh di atas, periksa bagian tingkat teratas Di mana penyimpanan root certificate sistem saya dan bagaimana cara memperbaruinya? untuk memastikan paket root certificate sistem sudah diperbarui.

Untuk mengetahui petunjuk cara mendapatkan openssl, lihat bagian Mendapatkan OpenSSL.

Penyimpanan root certificate Java

Aplikasi Java mungkin menggunakan penyimpanan root certificate-nya sendiri, yang pada sistem Linux biasanya berada di /etc/pki/java/cacerts atau /usr/share/ca-certificates-java, yang bisa dikelola menggunakan alat command line keytool Java.

Untuk mengimpor satu per satu sertifikat ke penyimpanan sertifikat Java Anda, berikan perintah berikut:

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

Cukup ganti cert.pem dengan file sertifikat yang sesuai dengan setiap root certificate yang direkomendasikan, alias dengan alias sertifikat yang unik dan bermakna, serta certs.jks dengan file database sertifikat yang digunakan di lingkungan Anda.

Untuk informasi selengkapnya, lihat artikel Oracle dan Stack Overflow berikut:

Penyimpanan root certificate Mozilla NSS

Aplikasi yang menggunakan Mozilla NSS mungkin secara default juga menggunakan database sertifikat seluruh sistem yang biasanya berada di /etc/pki/nssdb, atau penyimpanan default khusus pengguna di ${HOME}/.pki/nssdb.

Untuk memperbarui database NSS, gunakan alat certutil.

Untuk mengimpor satu per satu file sertifikat ke database NSS Anda, berikan perintah berikut:

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

Cukup ganti cert.pem dengan file sertifikat yang terkait dengan setiap root certificate yang direkomendasikan, cert-name dengan nama panggilan sertifikat yang bermakna, dan certdir dengan jalur database sertifikat yang digunakan di lingkungan Anda.

Untuk informasi selengkapnya, baca panduan resmi NSS Tools certutil, serta dokumentasi sistem operasi Anda.

Penyimpanan root certificate Microsoft .NET

Bagi developer .NET Windows, artikel Microsoft berikut mungkin berguna untuk memperbarui penyimpanan root certificate:

Format file sertifikat

Apa yang dimaksud dengan file PEM?

Privacy-Enhanced Mail (PEM) adalah format file teks standar de-facto untuk menyimpan dan mengirim sertifikat kriptografi, kunci, dll., yang dinyatakan sebagai standar de jure di RFC 7468.

Meskipun format file itu sendiri dapat dibaca manusia, informasi data sertifikat biner yang dienkode ke Base64 tidak dapat dibaca. Namun, spesifikasi PEM mengizinkan pemberian teks penjelasan baik sebelum maupun setelah isi sertifikat yang dienkode ke teks. Selain itu, banyak alat menggunakan fitur ini untuk memberikan ringkasan teks yang jelas terkait elemen data yang paling relevan dalam sertifikat.

Alat, seperti openssl juga dapat digunakan untuk mendekode seluruh sertifikat menjadi bentuk yang dapat dibaca manusia. Lihat bagian Cara mencetak sertifikat PEM dalam bentuk yang dapat dibaca manusia untuk mengetahui info selengkapnya.

Apa yang dimaksud dengan file ".crt"?

Alat yang memungkinkan ekspor sertifikat dalam format PEM biasanya menggunakan ekstensi file ".crt" untuk menunjukkan bahwa file menggunakan enkode tekstual.

Apa yang dimaksud dengan file DER?

Distinguished Encoding Rules (DER) adalah format biner standar untuk mengenkode sertifikat. Sertifikat dalam file PEM biasanya adalah sertifikat DER yang dienkode ke Base64.

Apa yang dimaksud dengan file ".cer"?

File yang diekspor dengan akhiran ".cer" mungkin berisi sertifikat yang dienkode ke PEM, tetapi lebih mungkin berupa biner, biasanya sertifikat yang dienkode ke DER. Berdasarkan konvensi, file ".cer" biasanya hanya berisi satu sertifikat.

Sistem saya menolak mengimpor semua sertifikat dari roots.pem

Beberapa sistem, misalnya, keytool Java, hanya dapat mengimpor satu sertifikat dari file PEM, meskipun berisi beberapa sertifikat. Lihat pertanyaan Bagaimana cara mengekstrak satu per satu sertifikat dari roots.pem? untuk mengetahui cara memisahkan file terlebih dahulu.

Bagaimana cara mengekstrak satu per satu sertifikat dari roots.pem?

Anda dapat memisahkan roots.pem menjadi sertifikat komponennya menggunakan skrip bash sederhana berikut:

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

Tindakan ini akan membuat sejumlah file PEM terpisah yang mirip dengan yang tercantum di sini:

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

Kemudian, masing-masing file PEM, seperti 02265526.pem dapat diimpor secara terpisah, atau dikonversi lebih lanjut ke dalam format file yang diterima oleh penyimpanan sertifikat Anda.

Cara mengonversi file PEM ke format yang didukung oleh sistem saya

Alat command line toolkit openssl OpenSSL dapat digunakan untuk mengonversi file ke semua format file sertifikat yang umum digunakan. Petunjuk untuk mengonversi file PEM ke format file sertifikat yang paling umum digunakan tercantum di bawah.

Untuk daftar lengkap opsi yang tersedia, lihat dokumentasi Utilitas Command Line OpenSSL resmi.

Untuk mengetahui petunjuk cara mendapatkan openssl, lihat bagian Mendapatkan OpenSSL.

Bagaimana cara mengonversi file PEM ke format DER?

Dengan menggunakan openssl, Anda dapat memberikan perintah berikut untuk mengonversi file dari PEM ke DER:

openssl x509 -in roots.pem -outform der -out roots.der
Bagaimana cara mengonversi file PEM ke PKCS #7?

Dengan menggunakan openssl, Anda dapat memberikan perintah berikut untuk mengonversi file dari PEM ke PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Bagaimana cara mengonversi file PEM ke PKCS #12 (PFX)?

Dengan menggunakan openssl, Anda dapat memberikan perintah berikut untuk mengonversi file dari PEM ke PKCS #12:

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

Anda harus membuat sandi untuk file saat membuat arsip PKCS #12. Pastikan untuk menyimpan sandi di tempat yang aman, jika Anda tidak langsung mengimpor file PKCS #12 ke dalam sistem.

Mencantumkan, mencetak, dan mengekspor sertifikat dari penyimpanan root certificate

Bagaimana cara mengekspor sertifikat dari Java Key Store sebagai file PEM?

Dengan menggunakan keytool, Anda dapat memberikan perintah berikut untuk mencantumkan semua sertifikat di penyimpanan sertifikat, bersama dengan alias yang dapat Anda gunakan untuk mengekspor setiap sertifikat:

keytool -v -list -keystore certs.jks

Cukup ganti certs.jks dengan file database sertifikat yang digunakan di lingkungan Anda. Perintah ini juga akan menampilkan alias dari setiap sertifikat, yang akan diperlukan jika Anda ingin mengekspornya.

Untuk mengekspor satu per satu sertifikat dalam format PEM, berikan perintah berikut:

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

Cukup ganti certs.jks dengan file database sertifikat yang digunakan di lingkungan Anda, dan berikan alias serta alias.pem yang sesuai dengan sertifikat yang ingin diekspor.

Untuk informasi selengkapnya, lihat panduan Platform Java, Referensi Alat Edisi Standard: keytool.

Bagaimana cara mengekspor sertifikat dari penyimpanan root certificate NSS sebagai file PEM?

Dengan menggunakan certutil, Anda dapat memberikan perintah berikut untuk mencantumkan semua sertifikat di penyimpanan sertifikat, bersama dengan nama panggilan yang dapat digunakan untuk mengekspor setiap sertifikat:

certutil -L -d certdir

Cukup ganti certdir dengan jalur database sertifikat yang digunakan di lingkungan Anda. Perintah ini juga akan menampilkan nama panggilan setiap sertifikat, yang akan diperlukan jika Anda ingin mengekspornya.

Untuk mengekspor satu per satu sertifikat dalam format PEM, berikan perintah berikut:

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

Cukup ganti certdir dengan jalur database sertifikat yang digunakan di lingkungan Anda, serta berikan cert-name dan cert.pem yang sesuai dengan sertifikat yang ingin diekspor.

Untuk informasi selengkapnya, baca panduan resmi NSS Tools certutil, serta dokumentasi sistem operasi Anda.

Cara mencetak sertifikat PEM dalam bentuk yang dapat dibaca manusia

Pada contoh berikut, kami menganggap Anda memiliki file GTS_Root_R1.pem dengan konten berikut:

# 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-----
Mencetak file sertifikat menggunakan OpenSSL

Memberikan perintah

openssl x509 -in GTS_Root_R1.pem -text

akan menghasilkan sesuatu yang mirip dengan:

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
        …

Untuk mengetahui petunjuk cara mendapatkan openssl, lihat bagian Mendapatkan OpenSSL.

Mencetak sertifikat menggunakan keytool Java

Memberikan perintah berikut

keytool -printcert -file GTS_Root_R1.pem

akan menghasilkan sesuatu yang mirip dengan:

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>
]
]

Untuk mengetahui petunjuk cara mendapatkan keytool, lihat bagian Mendapatkan keytool Java.

Bagaimana cara melihat sertifikat yang diinstal di penyimpanan root certificate saya?

Ini berbeda untuk setiap sistem operasi dan library SSL/TLS. Namun, alat yang memungkinkan pengimporan dan pengeksporan sertifikat ke dan dari penyimpanan root certificate biasanya juga memberikan opsi untuk mencantumkan sertifikat yang diinstal.

Selain itu, jika Anda telah berhasil mengekspor root certificate tepercaya ke dalam file PEM, atau penyimpanan root certificate Anda sudah berisi file PEM yang disimpan, Anda dapat mencoba membuka file tersebut di editor teks apa pun, karena itu adalah format file teks biasa.

File PEM dapat diberi label yang sesuai, sehingga memberikan informasi yang mudah dibaca tentang certificate authority terkait (misalnya dari paket root CA Google tepercaya):

# 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-----

File mungkin juga hanya berisi bagian sertifikat. Dalam kasus seperti ini, nama file, seperti GTS_Root_R1.pem dapat menjelaskan CA yang menerbitkan sertifikat tersebut. String sertifikat antara token -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE----- juga dijamin unik untuk setiap CA.

Namun, meskipun Anda tidak memiliki alat di atas, karena setiap sertifikat dalam paket root CA Google tepercaya diberi label dengan benar, Anda dapat dengan mudah mencocokkan root CA dari paket dengan root CA dari penyimpanan root certificate Anda, baik dengan Issuer, atau dengan membandingkan string sertifikat file PEM.

Browser web dapat menggunakan penyimpanan root certificate-nya sendiri, atau menggunakan penyimpanan root certificate default yang disediakan oleh operasi. Namun, semua browser modern harus memungkinkan Anda mengelola atau setidaknya melihat kumpulan root CA yang dipercayai. Lihat pertanyaan Apakah aplikasi JavaScript berisiko mengalami error? untuk mengetahui detail lebih lanjut.

Untuk petunjuk khusus ponsel, lihat pertanyaan terpisah Bagaimana cara memeriksa root certificate tepercaya di ponsel saya?.

Lampiran

Perlu info lebih lanjut?

Selalu utamakan mengandalkan dokumentasi sistem operasi, dokumentasi bahasa pemrograman aplikasi, serta dokumentasi dari library eksternal yang digunakan aplikasi Anda.

Segala sumber informasi lainnya termasuk FAQ ini mungkin sudah tidak berlaku lagi atau salah, dan tidak boleh dianggap bersifat otoritatif. Namun, Anda masih dapat menemukan informasi yang berguna di banyak komunitas Tanya Jawab Stack Exchange, serta situs seperti AdamW on Linux and more dan confirm blog.

Lihat juga FAQ Layanan Kepercayaan Google.

Untuk mengetahui detail selengkapnya tentang topik lanjutan, seperti penyematan sertifikat, sebaiknya baca artikel Certificate and Public Key Pinning dari Open Web Application Security Project (OWASP) dan Pinning Cheat Sheet. Untuk petunjuk khusus Android, lihat dokumen pelatihan resmi Praktik Terbaik Android untuk Keamanan & Privasi Keamanan dengan HTTPS dan SSL. Untuk diskusi tentang perbandingan penyematan sertifikat dan penyematan kunci publik di Android, postingan blog Matthew Dolan, Android Security: SSL Pinning (hanya dalam bahasa Inggris), mungkin berguna untuk Anda.

Dokumen pelatihan Praktik Terbaik Android untuk Keamanan & Privasi Konfigurasi Keamanan Jaringan dan postingan blog JeroenHD Android 7 Nougat dan certificate authority (hanya dalam bahasa Inggris) memberikan informasi lebih lanjut tentang cara mengelola sertifikat tepercaya tambahan di Android.

Untuk mengetahui daftar lengkap root CA yang dipercaya oleh AOSP, lihat repositori Git ca-certificates. Untuk mengetahui versi berbasis fork Android tidak resmi, misalnya, LineageOS, lihat repositori yang sesuai yang disediakan oleh vendor OS.