Perubahan sertifikat TLS Azure
Penting
Artikel ini diterbitkan bersamaan dengan perubahan sertifikat TLS, dan tidak sedang diperbarui. Untuk informasi terbaru tentang CA, lihat Detail Otoritas Sertifikat Azure.
Microsoft menggunakan sertifikat TLS dari kumpulan Otoritas Sertifikat Akar (CA) yang mematuhi Persyaratan Garis Besar Forum CA/Browser. Semua titik akhir Azure TLS/SSL berisi rangkaian sertifikat hingga CA Root yang disediakan dalam artikel ini. Perubahan pada titik akhir Azure mulai bertransisi pada Agustus 2020, dengan beberapa layanan menyelesaikan pembaruan mereka pada tahun 2022. Semua titik akhir TLS/SSL Azure yang baru dibuat berisi rantai sertifikat yang diperbarui hingga CA Akar baru.
Semua layanan Microsoft Azure terpengaruh oleh perubahan ini. Detail untuk beberapa layanan tercantum di bawah ini:
- Layanan MICROSOFT Entra ID (MICROSOFT Entra ID) memulai transisi ini pada 7 Juli 2020.
- Untuk informasi terbaru tentang perubahan sertifikat TLS untuk layanan Azure IoT, lihat posting blog Azure IoT ini.
- Azure IoT Hub memulai transisi ini pada Februari 2023 dengan penyelesaian yang diharapkan pada Oktober 2023.
- Azure IoT Central akan memulai transisi ini pada Juli 2023.
- Azure IoT Hub Device Provisioning Service akan memulai transisi ini pada Januari 2024.
- Azure Cosmos DB memulai transisi ini pada Juli 2022 dengan perkiraan selesai pada Oktober 2022.
- Detail tentang perubahan sertifikat TLS Azure Storage dapat ditemukan di posting blog Azure Storage ini.
- Azure Cache for Redis beralih dari sertifikat TLS yang dikeluarkan oleh Baltimore CyberTrust Root mulai Mei 2022, seperti yang dijelaskan dalam artikel Azure Cache for Redis ini
- Azure Instance Metadata Service memiliki penyelesaian yang diharapkan pada Mei 2022, seperti yang dijelaskan dalam posting blog Tata Kelola dan Manajemen Azure ini.
Apa yang berubah?
Sebelum perubahan, sebagian besar sertifikat TLS yang digunakan oleh layanan Azure dirantai ke Root CA berikut:
| Nama umum CA | Thumbprint (SHA1) |
|---|---|
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
Setelah perubahan, sertifikat TLS yang digunakan oleh layanan Azure akan dirangkai ke salah satu CA Root berikut:
| Nama umum CA | Thumbprint (SHA1) |
|---|---|
| DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
| DigiCert Global Root CA | a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 |
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
| D-TRUST Root Class 3 CA 2 2009 | 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0 |
| Microsoft RSA Root Certificate Authority 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Microsoft ECC Root Certificate Authority 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
Apakah aplikasi saya terpengaruh?
Jika aplikasi Anda secara eksplisit menentukan daftar OS yang dapat diterima, aplikasi Anda kemungkinan terpengaruh. Praktik ini dikenal sebagai penyematan sertifikat. Tinjau artikel Komunitas Teknologi Microsoft tentang Azure Storage perubahan TLS untuk informasi selengkapnya tentang cara menentukan apakah layanan Anda terpengaruh dan langkah berikutnya.
Berikut adalah beberapa cara untuk mendeteksi apakah aplikasi Anda terpengaruh:
Telusuri kode sumber Anda untuk sidik jari, Nama Umum, dan properti sertifikat lainnya dari Microsoft IT TLS CA di repositori Microsoft PKI. Jika ada kecocokan, maka aplikasi Anda akan terpengaruh. Untuk mengatasi masalah ini, perbarui kode sumber yang menyertakan CA baru. Sebagai praktik terbaik, pastikan bahwa CA dapat ditambahkan atau diedit dalam waktu singkat. Peraturan industri mengharuskan sertifikat CA diganti dalam waktu tujuh hari sejak perubahan dan oleh karena itu pelanggan yang mengandalkan penyematan harus bereaksi dengan cepat.
Jika Anda memiliki aplikasi yang terintegrasi dengan Azure API atau layanan Azure lainnya dan Anda tidak yakin apakah itu menggunakan penyematan sertifikat, hubungi vendor aplikasi.
Sistem operasi dan runtime bahasa yang berbeda yang berkomunikasi dengan layanan Microsoft Azure mungkin memerlukan langkah lainnya untuk membuat rantai sertifikat secara benar dengan akar baru berikut:
- Linux: Banyak distribusi mengharuskan Anda untuk menambahkan CA ke /etc/ssl/certs. Untuk petunjuk khusus, lihat dokumentasi distribusi.
- Java: Pastikan penyimpanan kunci Java berisi CA yang tercantum di atas.
- Windows yang berjalan di lingkungan terputus: Sistem yang berjalan di lingkungan terputus perlu memiliki akar baru yang ditambahkan ke penyimpanan Otoritas Sertifikasi Akar Tepercaya, dan perantara yang ditambahkan ke penyimpanan Otoritas Sertifikasi Perantara.
- Android: Periksa dokumentasi untuk perangkat dan versi Android.
- Perangkat keras lainnya, terutama IoT: Hubungi produsen perangkat.
Jika Anda memiliki lingkungan tempat aturan firewall diatur untuk mengizinkan panggilan keluar hanya ke unduhan Daftar Pencabutan Sertifikat (CRL) tertentu dan/atau lokasi verifikasi Protokol Status Sertifikat Online (OCSP), Anda harus mengizinkan URL CRL dan OCSP berikut. Untuk daftar lengkap URL CRL dan OCSP yang digunakan di Azure, lihat artikel detail Azure CA.
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
Langkah berikutnya
Jika ada pertanyaan lain, hubungi kami melalui dukungan.