Bagikan melalui

Mengelola sertifikat dalam kluster Service Fabric

  • Artikel

Artikel ini membahas aspek manajemen sertifikat yang digunakan untuk mengamankan komunikasi di kluster Azure Service Fabric. Artikel ini melengkapi pengenalan keamanan klaster Service Fabric dan penjelasan tentang autentikasi berbasis sertifikat X.509 di Service Fabric.

Prasyarat

Sebelum memulai, Anda harus memahami konsep keamanan mendasar dan kontrol yang ditampilkan Service Fabric untuk mengonfigurasi keamanan kluster.

Pengelakan

Artikel ini memadukan aspek teoretis manajemen sertifikat dengan contoh langsung yang mencakup kekhususan layanan, teknologi, dan sebagainya. Karena sebagian besar audiens di sini adalah internal Microsoft, artikel tersebut merujuk pada layanan, teknologi, dan produk yang khusus untuk Azure. Jika detail khusus Microsoft tertentu tidak berlaku untuk Anda, jangan ragu untuk meminta klarifikasi atau panduan di bagian komentar di bagian akhir.

Mendefinisikan manajemen sertifikat

Seperti yang Anda pelajari dalam artikel pendamping Autentikasi berbasis Sertifikat X.509 di kluster Service Fabric, sertifikat adalah objek kriptografi yang pada dasarnya mengikat pasangan kunci asimetris dengan atribut yang menjelaskan entitas yang diwakilinya.

Namun, sertifikat juga merupakan objek tidak tahan lama, karena masa pakainya terbatas dan rentan disusupi. Pengungkapan yang tidak disengaja atau eksploitasi yang berhasil dapat membuat sertifikat menjadi tidak berguna dari sudut pandang keamanan. Karakteristik ini menyiratkan kebutuhan untuk mengubah sertifikat baik secara rutin atau sebagai tanggapan terhadap insiden keamanan.

Aspek lain dari manajemen sertifikat, dan topik yang sama sekali terpisah, adalah pengamanan kunci privat sertifikat atau rahasia yang melindungi identitas dari entitas yang terlibat dalam pengadaan dan penyediaan sertifikat.

Kami menggambarkan manajemen sertifikat sebagai proses dan prosedur yang digunakan untuk mendapatkan sertifikat dan untuk membawanya dengan aman ke tempat yang dibutuhkan.

Beberapa operasi manajemen, seperti pendaftaran, pengaturan kebijakan, dan kontrol otorisasi, berada di luar cakupan artikel ini. Operasi lain, seperti penyediaan, perpanjangan, kunci ulang, atau pencabutan, hanya terkait secara kebetulan dengan Service Fabric. Meskipun demikian, artikel ini sedikit membahasnya, karena memahami bahwa operasi tersebut dapat membantu Anda mengamankan kluster dengan benar.

Tujuan langsung Anda kemungkinan adalah mengotomatiskan manajemen sertifikat sebanyak mungkin untuk memastikan ketersediaan kluster tanpa gangguan. Karena prosesnya bebas sentuhan pengguna, Anda juga ingin menawarkan jaminan keamanan. Dengan kluster Service Fabric, tujuan ini dapat dicapai.

Bagian lain dari artikel pertama-tama mendekonstruksi manajemen sertifikat, dan kemudian berfokus pada mengaktifkan autorollover.

Secara khusus, cakupannya adalah topik-topik berikut:

  • Asumsi tentang pemisahan atribusi antara pemilik dan platform
  • Alur panjang dari penerbitan sertifikat hingga penggunaan
  • Rotasi sertifikat: Mengapa, bagaimana, dan kapan
  • Apa yang mungkin bisa salah?

Artikel ini tidak membahas topik-topik ini:

  • Mengamankan dan mengelola nama domain
  • Mendaftar ke sertifikat
  • Menyiapkan kontrol otorisasi untuk memberlakukan penerbitan sertifikat.

Untuk informasi mengenai topik-topik ini, lihat otoritas pendaftaran (RA) layanan infrastruktur kunci umum (PKI) favorit Anda. Jika Anda adalah pembaca internal Microsoft, Anda dapat menghubungi Keamanan Azure.

Peran dan entitas yang terlibat dalam manajemen sertifikat

Pendekatan keamanan dalam kluster Service Fabric adalah kasus "pemilik cluster menyatakannya, runtime Service Fabric memberlakukannya." Ini berarti bahwa hampir tidak ada sertifikat, kunci, atau informasi masuk identitas lain yang berpartisipasi dalam fungsi kluster yang berasal dari layanan itu sendiri. Semuanya dinyatakan oleh pemilik kluster. Pemilik kluster juga bertanggung jawab untuk menyediakan sertifikat ke dalam kluster, memperbaruinya sesuai kebutuhan, dan membantu menjamin keamanannya setiap saat.

Lebih khusus lagi, pemilik kluster harus memastikan bahwa:

  • Sertifikat yang dinyatakan di bagian NodeType manifes kluster dapat ditemukan di setiap node dari jenis tersebut, sesuai dengan aturan presentasi.
  • Sertifikat yang dinyatakan seperti pada poin-poin sebelumnya dipasang dengan kunci privat terkait yang disertakan.
  • Sertifikat yang dinyatakan dalam aturan presentasi harus lulus aturan validasi.

Service Fabric, untuk bagiannya, mengasumsikan tanggung jawab berikut:

  • Menemukan sertifikat yang cocok dengan deklarasi dalam definisi kluster
  • Memberikan akses ke kunci privat yang sesuai ke entitas yang dikontrol Service Fabric berdasarkan kebutuhan
  • Memvalidasi sertifikat secara ketat sesuai dengan praktik terbaik keamanan yang telah ditetapkan dan definisi kluster
  • Meningkatkan peringatan tentang kedaluwarsa sertifikat yang akan datang, atau kegagalan untuk melakukan langkah-langkah dasar validasi sertifikat
  • Memvalidasi (sampai tingkat tertentu) bahwa aspek terkait sertifikat dari definisi Kluster dipenuhi oleh konfigurasi yang mendasari host

Ini mengikuti bahwa beban manajemen sertifikat (sebagai operasi aktif) hanya jatuh pada pemilik kluster. Bagian berikutnya menawarkan pandangan yang lebih dekat pada setiap operasi manajemen, termasuk mekanisme yang tersedia dan dampaknya terhadap kluster.

Perjalanan sertifikat

Mari kita uraikan perkembangan sertifikat dari penerbitan hingga penggunaan dalam konteks kluster Service Fabric:

  1. Pemilik domain mendaftarkan domain atau subjek yang ingin dikaitkan dengan sertifikat berikutnya dengan RA dari PKI. Sertifikat nantinya akan menjadi bukti kepemilikan domain atau subjek.

  2. Pemilik domain juga menetapkan entitas yang berhak meminta pendaftaran sertifikat dengan domain atau subjek yang ditentukan dalam RA identitas pemohon resmi.

  3. Pemohon resmi kemudian mendaftar ke sertifikat melalui layanan manajemen rahasia. Di Azure, layanan manajemen rahasia pilihan adalah Azure Key Vault, yang menyimpan dan memungkinkan pengambilan rahasia dan sertifikat oleh entitas yang berwenang dengan aman. Key Vault juga memperbarui dan mengunci ulang sertifikat seperti yang dikonfigurasi dalam kebijakan sertifikat terkait. Key Vault menggunakan ID Microsoft Entra sebagai idP.

  4. Pengakses resmi, atau agen penyediaan, mengambil sertifikat dari brankas kunci, termasuk kunci privatnya, dan memasangnya di komputer yang meng-hosting kluster.

  5. Layanan Service Fabric (berjalan meningkat pada setiap node) memberikan akses ke sertifikat kepada entitas Service Fabric yang diizinkan, yang ditetapkan oleh grup lokal dan dibagi antara ServiceFabricAdministrator dan ServiceFabricAllowedUsers.

  6. Runtime Service Fabric mengakses dan menggunakan sertifikat untuk membentuk federasi, atau untuk mengautentikasi permintaan masuk dari klien yang berwenang.

  7. Agen penyediaan memantau sertifikat brankas kunci dan memicu alur penyediaan ketika perpanjangan terdeteksi. Pemilik kluster kemudian memperbarui definisi kluster, jika diperlukan, untuk menunjukkan niat menyerahkan sertifikat.

  8. Agen penyediaan atau pemilik kluster juga bertanggung jawab untuk membersihkan dan menghapus sertifikat yang tidak digunakan.

Untuk tujuan artikel ini, dua langkah pertama dalam urutan sebelumnya sebagian besar tidak terkait. Satu-satunya hubungannya adalah bahwa nama umum subjek sertifikat adalah nama DNS yang dinyatakan dalam definisi kluster.

Alur penerbitan dan provisi sertifikat diilustrasikan dalam diagram berikut:

Untuk sertifikat yang dinyatakan dengan thumbprint

Diagram sertifikat provisi yang dideklarasikan dengan thumbprint.

Untuk sertifikat yang dinyatakan dengan nama subjek umum

Diagram sertifikat provisi yang dideklarasikan dengan nama umum subjek.

Pendaftaran sertifikat

Topik pendaftaran sertifikat dibahas secara mendetail dalam dokumentasi Key Vault. Sebuah sinopsis disertakan di sini untuk kesinambungan dan referensi yang lebih mudah.

Melanjutkan Azure sebagai konteksnya, dan menggunakan Key Vault sebagai layanan manajemen rahasia, pemohon sertifikat resmi harus memiliki setidaknya izin manajemen sertifikat di brankas kunci, yang diberikan oleh pemilik brankas kunci. Pemohon kemudian mendaftar ke sertifikat sebagai berikut:

  • Pemohon membuat kebijakan sertifikat di Key Vault, yang menentukan domain/subjek sertifikat, pengeluar sertifikat yang diinginkan, jenis dan panjang kunci, penggunaan kunci yang dimaksudkan, dan banyak lagi. Untuk informasi selengkapnya, lihat Sertifikat di Azure Key Vault.

  • Pemohon membuat sertifikat di vault yang sama dengan kebijakan yang ditentukan dalam langkah sebelumnya. Ini nantinya akan menghasilkan pasangan kunci sebagai objek vault dan permintaan penandatanganan sertifikat yang ditandatangani dengan kunci privat, yang kemudian diteruskan ke pengeluar sertifikat yang telah ditentukan untuk ditandatangani.

  • Setelah penerbit, atau otoritas sertifikat (OS), membalas dengan sertifikat yang telah ditandatangani, hasilnya digabungkan ke dalam brankas kunci, dan data sertifikat tersedia sebagai berikut:

    • Di bagian {vaultUri}/certificates/{name}: Sertifikat, termasuk kunci umum dan metadata
    • Di bagian {vaultUri}/keys/{name}: Kunci privay sertifikat, tersedia untuk operasi kriptografi (tutup/buka, tanda tangani/verifikasi)
    • Di bagian {vaultUri}/secrets/{name}: Sertifikat, termasuk kunci privatnya, tersedia untuk diunduh sebagai file PFX atau PEM yang tidak dilindungi.

Perlu diingat bahwa sertifikat di brankas kunci berisi daftar kronologis instans sertifikat yang berbagi kebijakan. Versi sertifikat akan dibuat sesuai dengan atribut masa pakai dan perpanjangan kebijakan ini. Sangat disarankan agar sertifikat vault tidak berbagi subjek atau domain atau nama DNS, karena dapat menimbulkan gangguan dalam kluster untuk menyediakan instans sertifikat dari sertifikat vault yang berbeda, dengan subjek yang identik tetapi atribut lain yang secara substansial berbeda, seperti pengeluar sertifikat, penggunaan kunci, dan sebagainya. Pada titik ini, sertifikat ada di brankas kunci, siap untuk digunakan. Sekarang mari kita jelajahi sisa prosesnya.

Penyediaan sertifikat

Kami menyebutkan agen penyediaan, yang merupakan entitas yang mengambil sertifikat, termasuk kunci privatnya, dari brankas kunci dan memasangnya di setiap host kluster. (Perlu diingat bahwa Service Fabric tidak menyediakan sertifikat.)

Dalam konteks artikel ini, kluster akan di-hosting pada kumpulan mesin virtual (VM) Azure atau set skala mesin virtual. Di Azure, Anda dapat menyediakan sertifikat dari vault ke VM/VMSS dengan menggunakan mekanisme berikut. Ini mengasumsikan, seperti sebelumnya, bahwa sebelumnya agen penyediaan telah diberikan izin mendapatkan rahasia di brankas kunci oleh pemilik brankas kunci.

  • Ad-hoc: Operator mengambil sertifikat dari brankas kunci (sebagai PFX/PKCS #12 atau PEM) dan memasangnya di setiap node.

    Mekanisme ad-hoc tidak disarankan, karena berbagai alasan, mulai dari keamanan hingga ketersediaan, dan tidak akan dibahas di sini lebih lanjut. Untuk informasi selengkapnya, lihat FAQ untuk kumpulan skala mesin virtual Azure.

  • Sebagai rahasia set skala mesin virtual selama penyebaran: Dengan menggunakan identitas pihak pertama atas nama operator, layanan komputasi mengambil sertifikat dari vault yang mendukung penyebaran templat dan memasangnya di setiap node set skala mesin virtual, seperti yang dijelaskan dalam FAQ untuk set skala mesin virtual Azure.

    Catatan

    Pendekatan ini memungkinkan penyediaan rahasia versi saja.

  • Dengan menggunakan ekstensi VM Key Vault. Ini memungkinkan Anda menyediakan sertifikat dengan menggunakan deklarasi tanpa versi, dengan refresh berkala untuk sertifikat yang diamati. Dalam hal ini, VM/VMSS diharapkan memiliki identitas terkelola, identitas yang telah diberikan akses ke brankas kunci yang berisi sertifikat yang diamati.

Penyediaan berbasis VMSS/koputasi menghadirkan keuntungan keamanan dan ketersediaan, tetapi juga menghadirkan pembatasan. Secara desain, itu mengharuskan Anda mendeklarasikan sertifikat sebagai rahasia dengan versi. Persyaratan ini membuat provisi berbasis VMSS/komputasi hanya cocok untuk kluster yang diamankan dengan sertifikat yang dideklarasikan dengan thumbprint.

Sebaliknya, provisi berbasis ekstensi VM Key Vault selalu menginstal versi terbaru dari setiap sertifikat yang diamati. yang membuatnya hanya cocok untuk cluster yang diamankan dengan sertifikat yang dideklarasikan dengan nama umum subjek. Untuk menekankan, jangan gunakan mekanisme penyediaan autorefresh (seperti ekstensi VM Key Vault) untuk sertifikat yang dinyatakan oleh instans (yaitu, dengan thumbprint). Risiko kehilangan ketersediaan cukup besar.

Mekanisme penyediaan lainnya ada, tetapi pendekatan yang disebutkan di sini adalah opsi yang saat ini diterima untuk kluster Azure Service Fabric.

Konsumsi dan pemantauan sertifikat

Seperti yang disebutkan sebelumnya, runtime Service Fabric bertanggung jawab untuk menemukan dan menggunakan sertifikat yang dinyatakan dalam definisi kluster. Artikel Autentikasi berbasis Sertifikat X.509 di kluster Service Fabric menjelaskan secara rinci bagaimana Service Fabric menerapkan aturan presentasi dan validasi, dan tidak akan ditinjau kembali di sini. Artikel ini akan meninjau akses dan pemberian izin, serta pemantauan.

Perlu diingat bahwa sertifikat di Service Fabric digunakan untuk berbagai tujuan, mulai dari autentikasi timbal balik di lapisan federasi hingga autentikasi Keamanan Lapisan Transportasi (TLS) untuk titik akhir manajemen. Ini mengharuskan berbagai komponen atau layanan sistem untuk memiliki akses ke kunci privat sertifikat. Runtime Service Fabric memindai penyimpanan sertifikat secara berkala, mencari kecocokan untuk setiap aturan presentasi yang diketahui.

Untuk setiap sertifikat yang cocok, kunci privat yang sesuai ditemukan, dan daftar kontrol akses diskresinya diperbarui untuk menyertakan izin (Baca dan Jalankan, biasanya) yang diberikan kepada identitas yang memerlukannya.

Proses ini secara informal disebut sebagai ACLing. Proses berjalan dengan irama satu menit dan juga mencakup sertifikat aplikasi, seperti yang digunakan untuk mengenkripsi pengaturan atau sebagai sertifikat titik akhir. ACLing mengikuti aturan presentasi, jadi penting untuk diingat bahwa sertifikat yang dinyatakan oleh thumbprint dan yang di-refresh otomatis tanpa pembaruan konfigurasi kluster berikutnya tidak akan dapat diakses.

Rotasi sertifikat

Catatan

Internet Engineering Task Force (IETF) RFC 3647 secara resmi mendefinisikan perpanjangan sebagai penerbitan sertifikat dengan atribut yang sama dengan sertifikat yang diganti. Pengeluar sertifikat, kunci umum subjek, dan informasi dipertahankan. Penguncian ulang adalah penerbitan sertifikat dengan pasangan kunci baru, tanpa batasan apakah penerbit dapat mengubahnya. Mengingat perbedaan mungkin penting (pertimbangkan kasus sertifikat yang dinyatakan dengan nama umum subjek dengan penyematan pengeluar sertifikat), kami akan memilih istilah netral rotasi untuk mencakup kedua skenario. Perlu diingat bahwa, jika perpanjangan digunakan secara informal, ini merujuk pada penguncian ulang.

Seperti disebutkan sebelumnya, Key Vault mendukung rotasi sertifikat otomatis. Artinya, kebijakan sertifikat asosiasi menentukan titik waktu, baik berdasarkan hari sebelum kedaluwarsa atau persentase masa pakai total, saat sertifikat diputar di brankas kunci. Agen penyediaan harus dipanggil setelah titik waktu ini, dan sebelum berakhirnya sertifikat sekarang-sebelumnya, untuk mendistribusikan sertifikat baru ini ke semua node kluster.

Service Fabric membantu proses ini dengan meningkatkan peringatan kesehatan ketika tanggal kedaluwarsa sertifikat, yang saat ini digunakan di kluster, terjadi lebih cepat dari interval yang telah ditentukan. Agen penyediaan otomatis, ekstensi VM Key Vault, yang dikonfigurasi untuk mengamati sertifikat brankas kunci, secara berkala melakukan polling brankas kunci, mendeteksi rotasi, dan mengambil serta menginstal sertifikat baru. Penyediaan yang berlangsung melalui fitur rahasia VM/VMSS memerlukan operator resmi untuk memperbarui VM/VMSS dengan versi URI Key Vault yang sesuai dengan sertifikat baru.

Sertifikat yang diputar sekarang disediakan untuk semua node. Sekarang, dengan asumsi bahwa rotasi yang diterapkan pada sertifikat kluster dinyatakan dengan nama umum subjek, mari kita lihat apa yang terjadi akan selanjutnya:

  • Untuk koneksi baru di dalam, serta ke dalam kluster, runtime Fabric Layanan menemukan dan memilih sertifikat pencocokan yang terakhir diterbitkan (nilai terbesar dari properti NotBefore). Ini adalah perubahan dari versi runtime Service Fabric sebelumnya.

  • Koneksi yang ada tetap aktif atau dibiarkan kedaluwarsa secara alami atau dihentikan, dan penghandel internal akan diberi tahu jika ada kecocokan baru.

Catatan

Saat ini, pada versi 7.2 CU4+, Service Fabric memilih sertifikat dengan nilai properti NotBefore terbesar (terakhir diterbitkan). Sebelum 7.2 CU4, Service Fabric memilih sertifikat yang valid dengan nilai NotAfter terbesar (kedaluwarsa terakhir).

Ini diterjemahkan ke dalam pengamatan penting berikut:

  • Ketersediaan kluster, atau aplikasi yang di-hosting, lebih diutamakan daripada direktif untuk memutar sertifikat. Pada akhirnya, kluster akan bertemu pada sertifikat baru, tetapi tanpa jaminan waktu. Ini mengikuti bahwa:

    • Mungkin tidak langsung jelas bagi pengamat bahwa sertifikat yang diputar sepenuhnya menggantikan pendahulunya. Satu-satunya cara untuk memberlakukan penggantian langsung dari sertifikat yang sedang digunakan adalah dengan memulai ulang mesin host. Memulai ulang node Service Fabric saja tidak cukup, karena komponen mode kernel yang membentuk koneksi sewa dalam sebuah kluster tidak akan terpengaruh. Selain itu, memulai ulang VM/VMSS dapat menyebabkan hilangnya ketersediaan sementara. Untuk sertifikat aplikasi, cukup mulai ulang instans aplikasi masing-masing.

    • Memperkenalkan sertifikat yang dikunci ulang yang tidak memenuhi aturan validasi dapat memutuskan kluster. Contoh paling umum dari hal ini adalah kasus pengeluar sertifikat tak terduga, ketika sertifikat kluster dinyatakan dengan nama umum subjek bersama penyematan pengeluar sertifikat, tetapi sertifikat yang diputar diterbitkan oleh pengeluar sertifikat baru atau belum dinyatakan.

Pembersihan sertifikat

Saat ini, tidak ada ketentuan di Azure untuk penghapusan sertifikat secara eksplisit. Untuk menentukan apakah sertifikat tertentu digunakan pada waktu tertentu Sering kali bukan hal yang mudah. Ini lebih sulit untuk sertifikat aplikasi daripada untuk sertifikat kluster. Service Fabric sendiri, bukan sebagai agen penyedia, tidak akan menghapus sertifikat yang dinyatakan oleh pengguna dalam keadaan apa pun. Untuk mekanisme penyediaan standar:

  • Sertifikat yang dinyatakan sebagai rahasia VM/VMSS tersedia selama direferensikan dalam definisi VM/VMSS dan dapat diambil dari brankas kunci. Menghapus rahasia atau sertifikat kunci vault akan menggagalkan penyebaran VM/VMSS berikutnya. Demikian pula, menonaktifkan versi rahasia di brankas kunci juga akan menggagalkan penyebaran VM/VMSS yang mereferensikan versi rahasia.

  • Versi sertifikat sebelumnya yang tersedia melalui ekstensi VM Key Vault mungkin ada atau tidak ada pada node VM/VMSS. Agen hanya mengambil dan memasang versi saat ini, dan tidak menghapus sertifikat apa pun. Pencitraan ulang sebuah node, yang biasanya terjadi setiap bulan, mengatur ulang penyimpanan sertifikat ke konten citra OS, sehingga versi sebelumnya akan dihapus secara implisit. Namun, pertimbangkan bahwa menskalakan set skala mesin virtual hanya akan menghasilkan versi terbaru dari sertifikat yang diamati yang terpasang. Jangan berasumsi homogenitas node sehubungan dengan sertifikat yang dipasang.

Menyederhanakan manajemen: Contoh autorollover

Sejauh ini, artikel ini telah menjelaskan mekanisme dan batasan, menguraikan aturan dan definisi yang rumit, dan membuat prediksi pemadaman yang mengerikan. Sekarang saatnya menyiapkan manajemen sertifikat otomatis untuk menghindari semua masalah tersebut. Mari lakukan dalam konteks kluster Azure Service Fabric yang berjalan pada set skala mesin virtual platform as a service (PaaS) v2, menggunakan Key Vault untuk manajemen rahasia dan memanfaatkan identitas terkelola, sebagai berikut:

  • Validasi sertifikat diubah dari penyematan thumbprint menjadi penyematan pengeluar sertifikat + subjek. Sertifikat apa pun dengan subjek tertentu dari pengeluar sertifikat tertentu sama-sama tepercaya.
  • Sertifikat didaftarkan ke dan diperoleh dari penyimpanan tepercaya (Key Vault), dan di-refresh oleh agen (dalam hal ini, ekstensiVM Key Vault).
  • Penyediaan sertifikat diubah dari waktu penyebaran dan berbasis versi (seperti yang dilakukan oleh Penyedia Sumber Azure Compute) menjadi pasca-penyebaran dengan menggunakan URI Key Vault tanpa versi.
  • Akses ke brankas kunci diberikan melalui identitas terkelola yang ditetapkan pengguna, yang dibuat dan ditetapkan ke set skala mesin virtual selama penyebaran.
  • Setelah penyebaran, agen (ekstensi VM Key Vault) melakukan polling dan me-refresh sertifikat yang diamati pada setiap node set skala mesin virtual. Dengan demikian, rotasi sertifikat sepenuhnya otomatis, karena Service Fabric otomatis mengambil sertifikat terbaru yang valid.

Urutannya sepenuhnya dapat ditulis dan otomatis, dan memungkinkan penyebaran awal kluster tanpa sentuhan pengguna yang dikonfigurasi untuk autorollover sertifikat. Bagian berikutnya memberikan langkah-langkah mendetail, yang berisi perpaduan cmdlet PowerShell dan fragmen templat JSON. Fungsionalitas yang sama dapat dicapai dengan semua cara berinteraksi yang didukung dengan Azure.

Catatan

Contoh ini mengasumsikan bahwa sertifikat sudah ada di brankas kunci Anda. Mendaftarkan dan memperbarui sertifikat yang dikelola Key Vault memerlukan langkah manual prasyarat, seperti yang dijelaskan sebelumnya dalam artikel ini. Untuk lingkungan produksi, gunakan sertifikat yang dikelola Key Vault. Kami telah menyertakan skrip sampel yang dikhususkan untuk PKI internal Microsoft.

Catatan

Autorollover sertifikat hanya dapat dimungkinkan untuk sertifikat yang dikeluarkan OS. Menggunakan sertifikat yang ditandatangani sendiri, termasuk yang dihasilkan selama penyebaran kluster Service Fabric di portal Azure, adalah hal yang mustahil, tetapi masih memungkinkan untuk penyebaran lokal atau yang di-hosting pengembang jika Anda menyatakan thumbprint pengeluar sertifikat sama dengan yang ada pada sertifikat node leaf.

Titik awal

Untuk singkatnya, mari kita asumsikan status awal berikut:

  • Kluster Service Fabric ada, dan diamankan dengan sertifikat yang dikeluarkan CA yang dinyatakan dengan thumbprint.
  • Sertifikat disimpan dalam brankas kunci, dan disediakan sebagai rahasia set skala mesin virtual.
  • Sertifikat yang sama akan digunakan untuk mengonversi kluster ke deklarasi sertifikat berbasis nama umum, sehingga dapat divalidasi oleh subjek dan pengeluar sertifikat. Jika tidak demikian, dapatkan sertifikat yang diterbitkan OS yang dimaksudkan untuk tujuan ini, dan tambahkan ke definisi klaster dengan thumbprint. Proses ini dijelaskan di Menambahkan atau menghapus sertifikat untuk kluster Service Fabric di Azure.

Berikut ini kutipan JSON dari templat yang sesuai dengan status semacam itu. Kutipan tersebut menghilangkan banyak pengaturan yang diperlukan dan hanya mengilustrasikan aspek terkait sertifikat.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

Kode sebelumnya pada dasarnya mengatakan bahwa sertifikat dengan thumbprint json [parameters('primaryClusterCertificateTP')] dan ditemukan di URI Key Vault json [parameters('clusterCertificateUrlValue')] dinyatakan sebagai satu-satunya sertifikat kluster, dengan thumbprint.

Selanjutnya, mari siapkan sumber daya tambahan yang diperlukan untuk memastikan autorollover sertifikat.

Menyiapkan sumber daya prasyarat

Seperti yang disebutkan sebelumnya, sertifikat yang disediakan sebagai rahasia set skala mesin virtual diambil dari brankas kunci oleh layanan Penyedia Sumber Komputasi Microsoft. Ini dilakukan dengan menggunakan identitas pihak pertama atas nama operator penyebaran. Proses itu akan berubah untuk autorollover. Anda akan beralih menggunakan identitas terkelola yang ditetapkan ke set skala mesin virtual dan yang telah diberikan izin GET pada rahasia di vault tersebut.

Anda harus menyebarkan kutipan berikutnya pada waktu yang sama. Kutipan dicantumkan secara individual hanya untuk analisis dan penjelasan play-by-play.

Pertama, tentukan identitas yang ditetapkan pengguna (nilai default disertakan sebagai contoh). Untuk informasi selengkapnya, lihat dokumentasi resmi.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

Selanjutnya, berikan akses identitas ini ke rahasia brankas kunci. Untuk informasi terbaru, lihat dokumentasi resmi.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

Pada langkah berikutnya, Anda akan melakukan hal berikut:

  • Menetapkan identitas yang ditetapkan pengguna ke set skala mesin virtual.
  • Menyatakan dependensi set skala komputer virtual pada pembuatan identitas terkelola, dan pada hasil pemberian akses ke brankas kunci.
  • Menyatakan ekstensi VM Key Vault dan mengharuskan pengambilan sertifikat yang diamati saat memulai. Untuk informasi selengkapnya, lihat dokumentasi resmi ekstensi VM Key Vault untuk Windows.
  • Perbarui definisi ekstensi VM Service Fabric agar bergantung pada ekstensi VM Key Vault, dan untuk mengonversi deklarasi sertifikat kluster dari thumbprint menjadi nama umum.

Catatan

Perubahan tersebut dibuat sebagai satu langkah karena berada dalam cakupan sumber daya yang sama.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

Meskipun tidak secara eksplisit tercantum dalam kode sebelumnya, perhatikan bahwa URL sertifikat brankas kunci telah dihapus dari bagian OsProfile dari set skala komputer virtual.

Langkah terakhir adalah memperbarui definisi kluster untuk mengubah deklarasi sertifikat dari thumbprint menjadi nama umum. Kami juga menyematkan thumbprint pengeluar sertifikat:

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

Pada titik ini, Anda dapat menjalankan pembaruan yang disebutkan sebelumnya dalam satu penyebaran. Untuk bagiannya, layanan Penyedia Sumber Service Fabric membagi peningkatan kluster dalam beberapa langkah, seperti yang dijelaskan di segmen tentang mengonversi sertifikat kluster dari thumbprint ke nama umum.

Analisis dan pengamatan

Bagian ini adalah keseluruhan untuk menjelaskan konsep dan proses yang telah disajikan di seluruh artikel ini, serta menarik perhatian pada aspek penting tertentu lainnya.

Tentang penyediaan sertifikat

Ekstensi VM Key Vault, sebagai agen penyediaan, berjalan terus menerus pada frekuensi yang telah ditentukan. Jika gagal mengambil sertifikat yang diamati, maka dilanjutkan ke baris berikutnya, dan kemudian hibernasi hingga siklus berikutnya. Ekstensi VM Service Fabric, sebagai agen bootstrap kluster, memerlukan sertifikat yang dinyatakan sebelum kluster dapat terbentuk. Ini, pada gilirannya, berarti bahwa ekstensi VM Service Fabric hanya dapat berjalan setelah sertifikat kluster berhasil diambil, ditandai di sini oleh klausul json "provisionAfterExtensions" : [ "KVVMExtension" ]", dan oleh pengaturan json "requireInitialSync": true ekstensiVM Key Vault.

Hal ini menunjukkan kepada ekstensi VM Key Vault bahwa, saat pertama kali dijalankan (setelah penyebaran atau mulai ulang), ekstensi tersebut harus menggilir sertifikat yang diamati hingga semua berhasil diunduh. Menyetel parameter ini ke false, ditambah dengan kegagalan mengambil sertifikat kluster, akan mengakibatkan kegagalan penyebaran kluster. Sebaliknya, memerlukan sinkronisasi awal dengan daftar sertifikat yang diamati yang salah atau tidak valid akan mengakibatkan kegagalan ekstensi VM Key Vault dan, sekali lagi, kegagalan untuk menyebarkan kluster.

Penautan sertifikat, dijelaskan

Anda mungkin telah memperhatikan bendera linkOnRenewal ekstensi VM Key Vault, dan fakta bahwa itu diatur ke false. Pengaturan ini membahas perilaku yang dikendalikan oleh bendera ini dan implikasinya pada fungsi cluster. Perilaku ini khusus untuk Windows.

Menurut definisinya:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

Sertifikat yang digunakan untuk membuat koneksi TLS biasanya diperoleh sebagai handel melalui Penyedia Dukungan Keamanan S-channel. Artinya, klien tidak secara langsung mengakses kunci privat sertifikat tersebut. S-channel mendukung pengalihan, atau penautan, informasi masuk dalam bentuk ekstensi sertifikat, CERT_RENEWAL_PROP_ID.

Jika properti ini ditetapkan, nilainya mewakili thumbprint dari sertifikat perpanjangan, sehingga S-channel akan mencoba memuat sertifikat tertaut. Bahkan, S-channel akan melintasi daftar tertaut ini dan, mudah-mudahan, daftar asiklik hingga berujung pada sertifikat final, sertifikat tanpa tanda perpanjangan. Fitur ini, jika digunakan dengan bijaksana, merupakan mitigasi yang bagus terhadap hilangnya ketersediaan yang disebabkan oleh, misalnya, sertifikat yang kedaluwarsa.

Dalam kasus lain, itu bisa menjadi penyebab pemadaman yang sulit didiagnosis dan dimitigasi. S-channel menjalankan traversal sertifikat pada properti perpanjangannya tanpa syarat, terlepas dari subjek, penerbit, atau atribut spesifik lainnya yang berpartisipasi dalam validasi sertifikat yang dihasilkan oleh klien. Ada kemungkinan bahwa sertifikat yang dihasilkan tidak memiliki kunci privat terkait, atau kunci tersebut belum ACL untuk calon konsumennya.

Jika penautan diaktifkan, ekstensi VM KeyVault, setelah mengambil sertifikat yang diamati dari brankas kunci, akan berusaha menemukan pencocokan, sertifikat yang ada untuk menautkannya melalui properti perpanjangan pembaruan. Pencocokan didasarkan secara eksklusif pada nama alternatif subjek (SAN), dan berhasil, jika terdapat dua sertifikat, seperti yang ditunjukkan dalam contoh berikut: A: Certificate name (CN) = “Alice's accessories”, SAN = {“alice.universalexports.com”}, renewal = ‘’ B: CN = “Bob's bits”, SAN = {“bob.universalexports.com”, “bob.universalexports.net”}, renewal = ‘’

Asumsikan bahwa sertifikat C diambil oleh ekstensi VM Key Vault: CN = “malware Mallory”, SAN = {“alice.universalexports.com”, “bob.universalexports.com”, “mallory.universalexports.com”}

Daftar SAN Sertifikat A sepenuhnya disertakan dalam C, sehingga A.renewal = C.thumbprint. Daftar SAN Sertifikat B memiliki persimpangan yang sama dengan C, tetapi tidak sepenuhnya disertakan di dalamnya, sehingga B.renewal tetap kosong.

Setiap upaya untuk menggunakan AcquireCredentialsHandle (S-channel) dalam status ini pada sertifikat A sebenarnya berujung pada pengiriman C ke pihak jarak jauh. Dalam kasus Service Fabric, Subsistem transportasi kluster menggunakan S-channel untuk autentikasi timbal balik, sehingga perilaku yang dijelaskan sebelumnya memengaruhi komunikasi fundamental kluster secara langsung. Melanjutkan contoh sebelumnya, dan dengan asumsi bahwa A adalah sertifikat kluster, yang akan terjadi selanjutnya tergantung pada:

  • Jika kunci privat C tidak ACL ke akun yang menjalankan Service Fabric, Anda akan melihat kegagalan untuk memperoleh kunci privat (SEC_E_UNKNOWN_CREDENTIALS atau serupa).
  • Jika kunci privat C dapat diakses, Anda akan melihat kegagalan otorisasi yang ditampilkan oleh node lain (CertificateNotMatched, tidak diizinkan, dan sebagainya).

Dalam kedua kasus, transportasi akan gagal dan kluster mungkin tidak berfungsi. Gejalanya bervariasi. Lebih buruk lagi, penautan bergantung pada urutan perpanjangan, yang ditentukan oleh urutan daftar sertifikat yang diamati dari ekstensi VM Key Vault, jadwal perpanjangan di brankas kunci, atau bahkan kesalahan sementara yang akan mengubah urutan dari pengambilan.

Untuk mengurangi insiden tersebut, sebaiknya:

  • Jangan mencampur nama alternatif subjek dari sertifikat vault yang berbeda. Setiap sertifikat vault harus memiliki tujuan yang berbeda, dan SAN serta subjeknya harus mencerminkan hal tersebut dengan spesifik.

  • Sertakan nama umum subjek dalam daftar SAN (misalnya, secara harfiah, CN=<subject common name>).

  • Jika Anda tidak mengetahui cara untuk melanjutkan, nonaktifkan penautan pada perpanjangan sertifikat yang ditentukan dengan ekstensi VM Key Vault.

    Catatan

    Menonaktifkan penautan adalah properti tingkat atas ekstensi VM Key Vault dan tidak dapat diatur untuk masing-masing sertifikat yang diamati.

Mengapa menggunakan identitas terkelola yang ditetapkan pengguna? Apa implikasi menggunakannya?

Seperti dalam cuplikan JSON sebelumnya, urutan operasi dan pembaruan tertentu diperlukan untuk menjamin keberhasilan konversi dan menjaga ketersediaan kluster. Secara khusus, sumber daya set skala mesin virtual menyatakan dan menggunakan identitasnya untuk mengambil rahasia dalam pembaruan tunggal (dari sudut pandang pengguna).

Ekstensi Service Fabric VM, yang mem-bootstrap kluster, bergantung pada penyelesaian ekstensi VM Key Vault, yang nanatinya akan bergantung pada keberhasilan pengambilan sertifikat yang diamati.

Ekstensi VM Key Vault menggunakan identitas set skala mesin virtual untuk mengakses brankas kunci, yang berarti bahwa kebijakan akses pada brankas kunci harus diperbarui sebelum penyebaran set skala mesin virtual.

Untuk membuang pembuatan identitas terkelola, atau untuk menetapkannya ke sumber daya lain, operator penyebaran harus memiliki peran yang diperlukan (ManagedIdentityOperator) dalam langganan atau grup sumber daya, selain peran yang diperlukan untuk mengelola sumber daya lain yang dirujuk dalam templat.

Dari sudut pandang keamanan, perlu diingat bahwa set skala mesin virtual dianggap sebagai batas keamanan sehubungan dengan identitas Azure-nya. Artinya bahwa aplikasi apa pun yang di-hosting di VM, pada dasarnya, dapat memperoleh token akses yang mewakili VM. Token akses identitas terkelola diperoleh dari titik akhir Instance Metadata Service yang tidak diautentikasi. Jika Anda menganggap VM sebagai lingkungan bersama, atau multi-penyewa, metode pengambilan sertifikat kluster ini mungkin tidak diindikasikan. Namun, ini adalah satu-satunya mekanisme penyediaan yang cocok untuk autorollover sertifikat.

Pemecahan masalah dan pertanyaan yang sering diajukan

T: Bagaimana cara mendaftar secara terprogram ke dalam sertifikat yang dikelola Key Vault?

Cari tahu nama pengeluar sertifikat dari dokumentasi Key Vault, lalu ganti dalam skrip berikut:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName

T: Apa yang terjadi jika sertifikat diterbitkan oleh penerbit yang tidak dinyatakan atau tidak ditentukan? Di mana saya dapat memperoleh daftar lengkap pengeluar sertifikat aktif PKI tertentu?

Jika deklarasi sertifikat menentukan thumbprint pengeluar sertifikat, dan pengeluar sertifikat langsung tidak termasuk dalam daftar pengeluar sertifikat yang disematkan, sertifikat akan dianggap tidak sah, terlepas dari apakah akarnya dipercaya oleh klien atau tidak. Oleh karena itu, sangat penting untuk memastikan bahwa daftar pengeluar sertifikat adalah yang terbaru. Pengenalan pengeluar sertifikat baru adalah peristiwa langka, dan harus dipublikasikan secara luas sebelum mulai menerbitkan sertifikat.

Secara umum, PKI menerbitkan dan menyimpan pernyataan praktik sertifikasi, sesuai dengan RFC 7382 IETF. Di samping informasi lain, pernyataan tersebut mencakup semua pengeluar sertifikat aktif. Mengambil daftar ini secara terprogram mungkin berbeda dari satu PKI ke PKI lainnya.

Untuk PKI internal Microsoft, pastikan untuk membaca dokumentasi internal pada titik akhir dan SDK yang digunakan untuk mengambil pengeluar sertifikat resmi. Pemilik kluster bertanggung jawab untuk meninjau daftar ini secara berkala guna memastikan bahwa definisi kluster mereka mencakup semua pengeluar sertifikat yang diharapkan.

T: Apakah beberapa PKI didukung?

Ya. Anda tidak boleh menyatakan beberapa entri CN dalam manifes kluster dengan nilai yang sama, tetapi Anda dapat mencantumkan pengeluar sertifikat dari beberapa PKI yang sesuai dengan CN yang sama. Ini bukan praktik yang direkomendasikan, dan praktik transparansi sertifikat dapat mencegah penerbitan sertifikat tersebut. Namun, sebagai sarana untuk bermigrasi dari satu PKI ke PKI lainnya, ini merupakan mekanisme yang dapat diterima.

T: Bagaimana jika sertifikat kluster saat ini tidak diterbitkan OS, atau tidak memiliki subjek yang dimaksud?

Dapatkan sertifikat dengan subjek yang dimaksud, dan tambahkan ke definisi kluster sebagai sekunder, dengan thumbprint. Setelah peningkatan berhasil diselesaikan, mulai peningkatan konfigurasi kluster lain untuk mengonversi deklarasi sertifikat menjadi nama umum.