Service Fabric kümelerindeki sertifikaları yönetme

  • Makale

Bu makalede, Azure Service Fabric kümelerindeki iletişimin güvenliğini sağlamak için kullanılan sertifikaların yönetim yönleri ele alır. Service Fabric kümesi güvenliğine ve Service Fabric'te X.509 sertifika tabanlı kimlik doğrulamasında açıklamaya giriş işlemini tamamlar.

Ön koşullar

Başlamadan önce, temel güvenlik kavramları ve Service Fabric'in bir kümenin güvenliğini yapılandırmak için kullanıma sunma denetimleri hakkında bilgi sahibi olmanız gerekir.

Sorumluluk Reddi

Bu makale, sertifika yönetiminin teorik yönlerini hizmetlerin, teknolojilerin vb. özelliklerini kapsayan uygulamalı örneklerle eşleştirir. Buradaki hedef kitlenin çoğu Microsoft-internal olduğundan, makale Azure'a özgü hizmetlere, teknolojilere ve ürünlere başvuruyor. Microsoft'a özgü bazı ayrıntılar sizin için geçerli değilse, sonundaki açıklamalar bölümünde açıklama veya rehberlik isteyebilirsiniz.

Sertifika yönetimini tanımlama

Service Fabric kümelerinde X.509 Sertifika tabanlı kimlik doğrulaması yardımcı makalesinde öğrendiğiniz gibi, sertifika temelde asimetrik anahtar çiftini temsil ettiği varlığı açıklayan özniteliklerle bağlayan şifreleme nesnesidir.

Bununla birlikte, bir sertifika aynı zamanda kalıcı bir nesnedir, çünkü ömrü sonludur ve tehlikeye karşı savunmasızdır. Yanlışlıkla açığa çıkması veya başarılı bir açıktan yararlanma, sertifikayı güvenlik açısından yararsız hale getirebilir. Bu özellik, sertifikaları düzenli olarak veya bir güvenlik olayına yanıt olarak değiştirme gereksinimini ifade eder.

Sertifika yönetiminin bir diğer yönü ve tamamen ayrı bir konu başlığı, sertifika temini ve sağlanmasında yer alan varlıkların kimliklerini koruyan sertifika özel anahtarlarının veya gizli dizilerinin korunmasıdır.

Sertifika yönetimini, sertifikaları almak ve bunları güvenli ve güvenli bir şekilde ihtiyaç duyulan yere taşımak için kullanılan işlemler ve yordamlar olarak tanımlarız.

Kayıt, ilke ayarı ve yetkilendirme denetimleri gibi bazı yönetim işlemleri bu makalenin kapsamı dışındadır. Sağlama, yenileme, yeniden anahtarlama veya iptal gibi diğer işlemler yalnızca Service Fabric ile tesadüfen ilişkilidir. Bununla birlikte, bu işlemleri anlamak kümenizin güvenliğini düzgün bir şekilde sağlamanıza yardımcı olabileceğinden, makale bunları bir şekilde ele alır.

Hemen hedefiniz, kümenin kesintisiz kullanılabilirliğini sağlamak için sertifika yönetimini mümkün olduğunca otomatikleştirmektir. İşlem kullanıcı dokunmadan çalıştığından, güvenlik güvenceleri de sunmak isteyeceksiniz. Service Fabric kümelerinde bu hedefe ulaşılabilir.

Makalenin geri kalanı önce sertifika yönetimini kaldırır ve daha sonra otomatik kaydı etkinleştirmeye odaklanır.

Özellikle, aşağıdaki konuları kapsar:

  • Sahip ve platform arasındaki ilişkilendirmelerin ayrılmasıyla ilgili varsayımlar
  • Sertifika vermeden tüketime kadar uzun işlem hattı
  • Sertifika döndürme: Neden, nasıl ve ne zaman
  • Ne yanlış gidebilir ki?

Makale şu konuları kapsamaz:

  • Etki alanı adlarının güvenliğini sağlama ve yönetme
  • Sertifikalara kaydolma
  • Sertifika verme işlemini zorunlu kılmak için yetkilendirme denetimlerini ayarlama.

Bu konular hakkında bilgi için sık kullandığınız ortak anahtar altyapısı (PKI) hizmetinin kayıt yetkilisine (RA) bakın. Microsoft'un dahili okuyucusuysanız Azure Güvenliği'ne ulaşabilirsiniz.

Sertifika yönetimine dahil olan roller ve varlıklar

Service Fabric kümesindeki güvenlik yaklaşımı "küme sahibi bunu bildirir, Service Fabric çalışma zamanı zorlar". Bu, bir kümenin çalışmasına katılan sertifikaların, anahtarların veya diğer kimlik bilgilerinin neredeyse hiçbirinin hizmetin kendisinden gelmediğini gösterir. Bunların tümü küme sahibi tarafından bildirildi. Küme sahibi ayrıca sertifikaları kümeye sağlamak, gerektiğinde yenilemek ve her zaman güvenliklerinin sağlanmasına yardımcı olmakla sorumludur.

Daha açık belirtmek gerekirse, küme sahibi şunları sağlamalıdır:

  • Küme bildiriminin NodeType bölümünde bildirilen sertifikalar, sunu kurallarına göre bu türdeki her düğümde bulunabilir.
  • Önceki madde işareti noktasında olarak bildirilen sertifikalar, buna karşılık gelen özel anahtarlarla birlikte yüklenir.
  • Sunu kurallarında bildirilen sertifikalar doğrulama kurallarını geçirmelidir.

Service Fabric, kendi açısından aşağıdaki sorumlulukları üstlenir:

  • Küme tanımındaki bildirimlerle eşleşen sertifikaları bulma
  • Service Fabric denetimindeki varlıklara ilgili özel anahtarlara ihtiyaç temelinde erişim verme
  • Sertifikaları, yerleşik güvenlik en iyi yöntemlerine ve küme tanımına uygun olarak doğrulama
  • Sertifikaların süresi dolmak üzere olan veya sertifika doğrulamasının temel adımlarını gerçekleştirme hatalarıyla ilgili uyarılar oluşturma
  • Küme tanımının sertifikayla ilgili yönlerinin konakların temel yapılandırmasıyla karşılandığını doğrulama (bir dereceye kadar)

Sertifika yönetimi yükünün (etkin işlemler olarak) yalnızca küme sahibine yüklendiğini izler. Sonraki bölümlerde, kullanılabilir mekanizmalar ve bunların küme üzerindeki etkileri de dahil olmak üzere yönetim işlemlerinin her birine daha yakından bakabilirsiniz.

Sertifika yolculuğu

Service Fabric kümesi bağlamında sertifika verme aşamasından tüketime kadar olan ilerleme durumunu hızla özetleyelim:

  1. Etki alanı sahibi, sertifika veren sertifikalarla ilişkilendirmek istediği bir etki alanı veya konu olan PKI'nın RA'sına kaydolır. Sertifikalar da etki alanının veya konunun sahipliğini kanıtlar.

  2. Etki alanı sahibi ayrıca RA'da yetkili istekte bulunanların kimliklerini, belirtilen etki alanına veya konuya sahip sertifikaların kaydını isteme hakkına sahip varlıkları belirler.

  3. Yetkili bir istek sahibi daha sonra gizli dizi yönetimi hizmeti aracılığıyla bir sertifikaya kaydoldu. Azure'da gizli dizi yönetimi hizmeti, yetkili varlıklar tarafından gizli dizileri ve sertifikaları güvenli bir şekilde depolayan ve almaya izin veren Azure Key Vault'tur. Key Vault ayrıca sertifikayı ilişkili sertifika ilkesinde yapılandırıldığı şekilde yeniler ve yeniden anahtarlar. Key Vault, kimlik sağlayıcısı olarak Microsoft Entra Id kullanır.

  4. Yetkili bir almacı veya sağlama aracısı, sertifikayı özel anahtarı da dahil olmak üzere anahtar kasasından alır ve kümeyi barındıran makinelere yükler.

  5. Service Fabric hizmeti (her düğümde yükseltilmiş olarak çalıştırılır), yerel gruplar tarafından belirlenen ve ServiceFabric Yönetici istrators ile ServiceFabricAllowedUsers arasında bölünmüş izin verilen Service Fabric varlıklarına sertifikaya erişim verir.

  6. Service Fabric çalışma zamanı, federasyon oluşturmak veya yetkili istemcilerden gelen isteklerde kimlik doğrulaması yapmak için sertifikaya erişir ve kullanır.

  7. Sağlama aracısı anahtar kasası sertifikasını izler ve yenilemeyi algıladığında sağlama akışını tetikler. Daha sonra küme sahibi, sertifikayı devretme amacını belirtmek için gerekirse küme tanımını güncelleştirir.

  8. Sağlama aracısı veya küme sahibi de kullanılmayan sertifikaları temizlemek ve silmekle sorumludur.

Bu makalenin amaçları doğrultusunda, önceki dizideki ilk iki adım çoğunlukla ilgisizdir. Tek bağlantıları, sertifikanın konu ortak adının küme tanımında bildirilen DNS adı olmasıdır.

Sertifika verme ve sağlama akışı aşağıdaki diyagramlarda gösterilmiştir:

Parmak izi tarafından bildirilen sertifikalar için

Diagram of provisioning certificates that are declared by thumbprint.

Konu ortak adı tarafından bildirilen sertifikalar için

Diagram of provisioning certificates that are declared by subject common name.

Sertifika kaydı

Sertifika kaydı konusu Key Vault belgelerinde ayrıntılı olarak ele alınmıştır. Süreklilik ve daha kolay başvuru için buraya bir özet eklenmiştir.

Bağlam olarak Azure'a devam ederek ve gizli dizi yönetimi hizmeti olarak Key Vault'u kullanarak, yetkili bir sertifika isteğinde bulunanın anahtar kasası sahibi tarafından verilen anahtar kasası üzerinde en az sertifika yönetimi izinlerine sahip olması gerekir. İstek sahibi daha sonra aşağıdaki gibi bir sertifikaya kaydoldu:

  • İstek sahibi Key Vault'ta sertifikanın etki alanını/konusunu, istenen vereni, anahtar türünü ve uzunluğunu, hedeflenen anahtar kullanımını ve daha fazlasını belirten bir sertifika ilkesi oluşturur. Daha fazla bilgi için bkz . Azure Key Vault'ta sertifikalar.

  • İstek sahibi, önceki adımda belirtilen ilkeyle aynı kasada bir sertifika oluşturur. Bu da kasa nesneleri olarak bir anahtar çifti ve özel anahtarla imzalanan bir sertifika imzalama isteği oluşturur ve bu istek daha sonra imza için belirlenen verene iletilir.

  • Veren veya sertifika yetkilisi (CA) imzalı sertifikayı yanıtladıktan sonra, sonuç anahtar kasasıyla birleştirilir ve sertifika verileri aşağıdaki gibi kullanılabilir:

    • Altında {vaultUri}/certificates/{name}: Ortak anahtar ve meta veriler de dahil olmak üzere sertifika
    • Altında {vaultUri}/keys/{name}: Sertifikanın şifreleme işlemleri için kullanılabilen özel anahtarı (sarmalama/kaldırma, imzalama/doğrulama)
    • altında {vaultUri}/secrets/{name}: Özel anahtarı da dahil olmak üzere, korumasız pfx veya PEM dosyası olarak indirilebilen sertifika.

Anahtar kasasındaki bir sertifikanın, ilkeyi paylaşan sertifika örneklerinin kronolojik bir listesini içerdiğini hatırlayın. Sertifika sürümleri, bu ilkenin yaşam süresi ve yenileme özniteliklerine göre oluşturulur. Kasa sertifikalarının özneleri veya etki alanlarını veya DNS adlarını paylaşmamalarını kesinlikle öneririz, çünkü bir kümede sertifika örneklerini farklı kasa sertifikalarından, özdeş öznelerle ama veren, anahtar kullanımları gibi önemli ölçüde farklı diğer özniteliklerle sağlamak kesintiye neden olabilir. Bu noktada anahtar kasasında kullanıma hazır bir sertifika bulunur. Şimdi sürecin geri kalanını inceleyelim.

Sertifika sağlama

Özel anahtarı dahil olmak üzere sertifikayı anahtar kasasından alan ve kümenin konaklarının her birine yükleyen varlık olan bir sağlama aracısından bahsettik. (Service Fabric'in sertifika sağlamadığını hatırlayın.)

Bu makale bağlamında, küme bir Azure sanal makineleri (VM' ler) veya sanal makine ölçek kümeleri koleksiyonunda barındırılacaktır. Azure'da aşağıdaki mekanizmaları kullanarak kasadan VM/VMSS'ye sertifika sağlayabilirsiniz. Bu, daha önce olduğu gibi sağlama aracısının daha önce anahtar kasası sahibi tarafından anahtar kasası üzerinde gizli dizi alma izinleri verildiğini varsayar.

  • Geçici: Operatör sertifikayı anahtar kasasından (PFX/PKCS #12 veya PEM olarak) alır ve her düğüme yükler.

    Güvenlikten kullanılabilirliğe kadar birçok nedenden dolayı geçici mekanizma önerilmez ve burada daha fazla tartışılmayacaktır. Daha fazla bilgi için bkz . Azure sanal makine ölçek kümeleri hakkında SSS.

  • Dağıtım sırasında sanal makine ölçek kümesi gizli dizisi olarak: İşlem hizmeti, operatör adına birinci taraf kimliğini kullanarak sertifikayı şablon dağıtımı özellikli bir kasadan alır ve Azure sanal makine ölçek kümeleri hakkında SSS bölümünde açıklandığı gibi sanal makine ölçek kümesinin her düğümüne yükler.

    Dekont

    Bu yaklaşım yalnızca sürümlenmiş gizli dizilerin sağlanmasına olanak tanır.

  • Key Vault VM uzantısını kullanarak. Bu, gözlemlenen sertifikaların düzenli aralıklarla yenilenmesiyle sürüm olmayan bildirimleri kullanarak sertifikalar sağlamanızı sağlar. Bu durumda VM/VMSS'nin, gözlemlenen sertifikaları içeren anahtar kasalarına erişim verilmiş bir kimlik olan yönetilen bir kimliğe sahip olması beklenir.

VMSS/işlem tabanlı sağlama, güvenlik ve kullanılabilirlik avantajları sunar, ancak kısıtlamalar da sunar. Tasarım gereği sertifikaları sürümlenmiş gizli diziler olarak bildirmeniz gerekir. Bu gereksinim, VMSS/işlem tabanlı sağlamayı yalnızca parmak izi tarafından bildirilen sertifikalarla güvenliği sağlanan kümeler için uygun hale getirir.

Buna karşılık, Key Vault VM uzantısı tabanlı sağlama her zaman gözlemlenen her sertifikanın en son sürümünü yükler. bu, yalnızca konu ortak adı tarafından bildirilen sertifikalarla güvenliği sağlanan kümeler için uygun hale getirir. Örneğin bildirdiği sertifikalar için (yani parmak iziyle) otomatik başvuru sağlama mekanizması (Key Vault VM uzantısı gibi) kullanmayın. Kullanılabilirliği kaybetme riski önemli ölçüdedir.

Diğer sağlama mekanizmaları mevcuttur, ancak burada belirtilen yaklaşımlar Azure Service Fabric kümeleri için şu anda kabul edilen seçeneklerdir.

Sertifika tüketimi ve izleme

Daha önce belirtildiği gibi Service Fabric çalışma zamanı, küme tanımında bildirilen sertifikaları bulmak ve kullanmakla sorumludur. Service Fabric kümelerinde X.509 Sertifika tabanlı kimlik doğrulaması makalesinde, Service Fabric'in sunu ve doğrulama kurallarını nasıl uyguladığı ayrıntılı olarak açıklanmaktadır ve burada yeniden ziyaret edilmeyecektir. Bu makalede erişim ve izin vermenin yanı sıra izleme konusuna da bakacağız.

Service Fabric'teki sertifikaların federasyon katmanındaki karşılıklı kimlik doğrulamasından yönetim uç noktaları için Aktarım Katmanı Güvenliği (TLS) kimlik doğrulamasına kadar birçok amaçla kullanıldığını hatırlayın. Bunun için çeşitli bileşenlerin veya sistem hizmetlerinin sertifikanın özel anahtarına erişmesi gerekir. Service Fabric çalışma zamanı, sertifika deposunu düzenli olarak tarar ve bilinen sunu kurallarının her biri için eşleşmeleri arar.

Eşleşen her sertifika için ilgili özel anahtar bulunur ve isteğe bağlı erişim denetim listesi, gerekli olan kimliğe verilen izinleri (Okuma ve Yürütme) içerecek şekilde güncelleştirilir.

Bu işlem, resmi olmayan bir şekilde ACLing olarak adlandırılır. İşlem bir dakikalık tempoda çalışır ve ayrıca ayarları şifrelemek için veya uç nokta sertifikaları olarak kullanılanlar gibi uygulama sertifikalarını kapsar. ACLing, sunu kurallarına uyar, bu nedenle parmak izi tarafından bildirilen ve veren küme yapılandırma güncelleştirmesi olmadan otomatik olarak iade edilen sertifikaların erişilemez olacağını aklınızda bulundurmanız önemlidir.

Sertifika döndürme

Dekont

İnternet Mühendisliği Görev Gücü (IETF) RFC 3647, yenilemeyi, değiştirilen sertifikayla aynı özniteliklere sahip bir sertifikanın verilmesi olarak resmen tanımlar. Veren, konunun ortak anahtarı ve bilgiler korunur. Yeniden anahtarlama , sertifikayı verenin değişip değişemeyeceğiyle ilgili kısıtlamalar olmadan yeni anahtar çiftine sahip bir sertifikanın verilmesidir. Ayrım önemli olabileceğinden (veren sabitleme ile konu ortak adı tarafından bildirilen sertifikaların durumunu göz önünde bulundurun), bu makalede her iki senaryoyu da kapsayacak şekilde nötr terim döndürme kullanılır. Yenileme resmi olmayan bir şekilde kullanıldığında yeniden anahtarlama anlamına geldiğini unutmayın.

Daha önce belirtildiği gibi Key Vault otomatik sertifika döndürmeyi destekler. Diğer bir ifadeyle, sertifikayı anahtar kasasında döndürüldüğünde, sertifikanın bitiş tarihinden önceki günlere veya toplam ömrün yüzdesine göre, sertifikayı ilişkilendirme ilkesi zaman noktasını tanımlar. Sağlama aracısı, bu yeni sertifikayı kümenin tüm düğümlerine dağıtmak için bu noktadan sonra ve şimdi önceki sertifikanın süresi dolmadan önce çağrılmalıdır.

Service Fabric, kümede kullanılmakta olan bir sertifikanın son kullanma tarihi önceden belirlenmiş bir aralıktan daha erken gerçekleştiğinde sistem durumu uyarılarını yükselterek bu işleme yardımcı olur. Anahtar kasası sertifikasını gözlemleyecek şekilde yapılandırılmış olan Key Vault VM uzantısı olan otomatik sağlama aracısı, anahtar kasasını düzenli aralıklarla yoklar, döndürmeyi algılar ve yeni sertifikayı alıp yükler. VM/VMSS gizli dizileri özelliği aracılığıyla gerçekleştirilir sağlama, yetkili bir operatörün VM/VMSS'yi yeni sertifikaya karşılık gelen sürüme sahip Key Vault URI'si ile güncelleştirmesini gerektirir.

Döndürülen sertifika artık tüm düğümlere sağlanır. Şimdi, küme sertifikasına uygulanan döndürmenin konu ortak adıyla bildirildiğini varsayarsak, şimdi ne olacağını inceleyelim:

  • Service Fabric çalışma zamanı, küme içindeki yeni bağlantılar için en son verilen eşleşen sertifikayı (NotBefore özelliğinin en büyük değeri) bulur ve seçer. Bu, Service Fabric çalışma zamanının önceki sürümlerinde yapılan bir değişikliktir.

  • Mevcut bağlantılar canlı tutulur veya doğal olarak süresi dolmasına veya başka bir şekilde sonlandırılmalarına izin verilir ve iç işleyiciye yeni bir eşleşme olduğu bildirilir.

Dekont

Şu anda 7.2 CU4+ sürümünden itibaren Service Fabric en büyük (en son verilen) NotBefore özellik değerine sahip sertifikayı seçer. Service Fabric, 7.2 CU4 tarihinden önce en büyük (son süresi dolan) NotAfter değerine sahip geçerli sertifikayı seçti.

Bu, aşağıdaki önemli gözlemlere dönüşür:

  • Kümenin veya barındırılan uygulamaların kullanılabilirliği, sertifikayı döndürme yönergesine göre önceliklidir. Küme sonunda yeni sertifika üzerinde yakınsanacak, ancak zamanlama garantisi olmayacaktır. Aşağıdaki gibidir:

    • Döndürülen sertifikanın öncülünü tamamen değiştirdiği bir gözlemci için hemen belli olmayabilir. Şu anda kullanılmakta olan sertifikanın hemen değiştirilmesini zorlamanın tek yolu konak makineleri yeniden başlatmaktır. Kümedeki kira bağlantılarını oluşturan çekirdek modu bileşenleri etkilenmeyeceği için Service Fabric düğümlerini yeniden başlatmak yeterli değildir. Ayrıca VM/VMSS'nin yeniden başlatılması geçici kullanılabilirlik kaybına neden olabilir. Uygulama sertifikaları için yalnızca ilgili uygulama örneklerini yeniden başlatmak yeterlidir.

    • Doğrulama kurallarına uymayan yeniden anahtarlanmış bir sertifikanın tanıtılması kümeyi etkili bir şekilde bozabilir. Bunun en yaygın örneği, küme sertifikalarının veren sabitleme ile konu ortak adıyla bildirildiği ancak döndürülen sertifikanın yeni veya bildirilmemiş bir veren tarafından verildiği beklenmeyen bir veren örneğidir.

Sertifika temizleme

Şu anda Azure'da sertifikaların açıkça kaldırılmasına yönelik bir hüküm yoktur. Belirli bir sertifikanın belirli bir zamanda kullanılıp kullanılmadığını belirlemek genellikle önemsiz bir görevdir. Bu, uygulama sertifikaları için küme sertifikalarından daha zordur. Service Fabric'in kendisi sağlama aracısı değil, kullanıcı tarafından bildirilen bir sertifikayı hiçbir koşulda silmez. Standart sağlama mekanizmaları için:

  • VM/VMSS gizli dizileri olarak bildirilen sertifikalar, VM/VMSS tanımında başvuruldukları ve anahtar kasasından alınabilir oldukları sürece sağlanır. Anahtar kasası gizli dizisini veya sertifikayı silmek, sonraki VM/VMSS dağıtımlarında başarısız olur. Benzer şekilde, anahtar kasasında gizli dizi sürümünü devre dışı bırakmak, gizli dizi sürümüne başvuran VM/VMSS dağıtımlarında da başarısız olur.

  • Key Vault VM uzantısı aracılığıyla sağlanan sertifikaların önceki sürümleri bir VM/VMSS düğümünde mevcut olabilir veya olmayabilir. Aracı yalnızca geçerli sürümü alır ve yükler ve hiçbir sertifikayı kaldırmaz. Normalde her ay gerçekleşen bir düğümü yeniden görüntüleme, sertifika depoyu işletim sistemi görüntüsünün içeriğine sıfırlar ve böylece önceki sürümler örtük olarak kaldırılır. Ancak, bir sanal makine ölçek kümesinin ölçeklendirilmesinin yalnızca gözlemlenen sertifikaların geçerli sürümünün yüklenmesine neden olacağını düşünün. Yüklü sertifikalarla ilgili düğümlerin homojenliğini varsaymayın.

Yönetimi basitleştirme: Otomatik kayıt örneği

Şimdiye kadar bu makalede mekanizmalar ve kısıtlamalar açıklanmış, karmaşık kurallar ve tanımlar özetlenmiştir ve kesintilerle ilgili korkunç tahminler yapılmıştır. Şimdi tüm bu sorunlardan kaçınmak için otomatik sertifika yönetimi ayarlamanın zamanı geldi. Bunu hizmet olarak platform (PaaS) v2 sanal makine ölçek kümesinde çalışan bir Azure Service Fabric kümesi bağlamında, gizli dizi yönetimi için Key Vault kullanarak ve yönetilen kimliklerden aşağıdaki gibi yararlanarak gerçekleştirelim:

  • Sertifikaların doğrulanması parmak izi sabitlemeden konu + veren sabitlemeye değiştirilir. Belirli bir verenden belirli bir konuya sahip tüm sertifikalara eşit şekilde güvenilir.
  • Sertifikalar güvenilir bir depoya (Key Vault) kaydedilir ve alınır ve bir aracı tarafından yenilenir (burada Key Vault VM uzantısı).
  • Sertifikaların sağlanması, dağıtım zamanından ve sürüm tabanlıdan (Azure İşlem Kaynak Sağlayıcısı tarafından yapıldığı gibi) sürüm olmayan Key Vault URI'leri kullanılarak dağıtım sonrası olarak değiştirilir.
  • Anahtar kasasına erişim, dağıtım sırasında oluşturulan ve sanal makine ölçek kümesine atanan kullanıcı tarafından atanan yönetilen kimlikler aracılığıyla verilir.
  • Dağıtımdan sonra aracı (Key Vault VM uzantısı) sanal makine ölçek kümesinin her düğümünde gözlemlenen sertifikaları yoklar ve yeniler. Bu nedenle, Service Fabric en son geçerli sertifikayı otomatik olarak aldığından sertifika döndürme işlemi tamamen otomatik hale gelir.

Sıra tamamen betiklenebilir ve otomatiktir ve sertifika otomatik kaydı için yapılandırılmış bir kümenin kullanıcı dokunmadan ilk dağıtımına olanak tanır. Sonraki bölümlerde, PowerShell cmdlet'lerinin ve JSON şablonlarının parçalarının bir karışımını içeren ayrıntılı adımlar sağlanır. Azure ile etkileşim kurmanın desteklenen tüm araçlarıyla aynı işleve ulaşılabilir.

Dekont

Bu örnekte, anahtar kasanızda bir sertifikanın zaten var olduğu varsayılır. Bu makalenin önceki bölümlerinde açıklandığı gibi, Key Vault tarafından yönetilen bir sertifikayı kaydetmek ve yenilemek için önkoşul el ile gerçekleştirilen adımlar gerekir. Üretim ortamları için Key Vault tarafından yönetilen sertifikaları kullanın. Microsoft iç PKI'sına özgü bir örnek betik ekledik.

Dekont

Sertifika otomatik kaydı yalnızca CA tarafından verilen sertifikalar için anlamlıdır. Azure portalında Service Fabric kümesinin dağıtımı sırasında oluşturulanlar da dahil olmak üzere otomatik olarak imzalanan sertifikaların kullanılması mantıksızdır, ancak veren parmak izini yaprak sertifikayla aynı olduğunu bildirirseniz yerel veya geliştirici tarafından barındırılan dağıtımlar için yine de mümkündür.

Başlangıç noktası

Kısalık için aşağıdaki başlangıç durumunu varsayalım:

  • Service Fabric kümesi var ve parmak izi tarafından bildirilen CA tarafından verilen bir sertifikayla güvenli hale getirildi.
  • Sertifika bir anahtar kasasında depolanır ve sanal makine ölçek kümesi gizli dizisi olarak sağlanır.
  • Kümeyi ortak ad tabanlı sertifika bildirimlerine dönüştürmek için aynı sertifika kullanılır ve böylece konu ve veren tarafından doğrulanabilir. Böyle bir durum söz konusu değilse, bu amaca yönelik CA tarafından verilen sertifikayı alın ve parmak iziyle küme tanımına ekleyin. Bu işlem, Azure'da Service Fabric kümesi için sertifika ekleme veya kaldırma bölümünde açıklanmıştır.

İşte böyle bir duruma karşılık gelen bir şablondan JSON alıntısı. alıntısı birçok gerekli ayarı atlar ve yalnızca sertifikayla ilgili yönleri gösterir.

  "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')]"
        },
    }
  ]

Yukarıdaki kod temelde parmak izi json [parameters('primaryClusterCertificateTP')] olan ve Key Vault URI'sinde json [parameters('clusterCertificateUrlValue')] bulunan sertifikanın parmak iziyle kümenin tek sertifikası olarak bildirildiğini söyler.

Şimdi sertifikanın otomatik kaydını sağlamak için gereken ek kaynakları ayarlayalım.

Önkoşul kaynaklarını ayarlama

Daha önce belirtildiği gibi, sanal makine ölçek kümesi gizli dizisi olarak sağlanan bir sertifika, Microsoft İşlem Kaynak Sağlayıcısı hizmeti tarafından anahtar kasasından alınır. Bunu, dağıtım operatörü adına birinci taraf kimliğini kullanarak yapar. Bu işlem otomatik kayıt için değişir. Sanal makine ölçek kümesine atanmış ve bu kasadaki gizli diziler üzerinde GET izinleri verilmiş bir yönetilen kimlik kullanmaya geçiş yapacaksınız.

Sonraki alıntıları aynı anda dağıtmanız gerekir. Bunlar yalnızca play-by-play analizi ve açıklaması için ayrı ayrı listelenir.

İlk olarak, kullanıcı tarafından atanan bir kimlik tanımlayın (varsayılan değerler örnek olarak eklenir). Daha fazla bilgi için resmi belgelere bakın.

{
  "$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]"
    },
  ]}

Ardından bu kimliğe anahtar kasası gizli dizilerine erişim verin. En güncel bilgiler için resmi belgelere bakın.

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

Sonraki adımda aşağıdakileri yapacaksınız:

  • Kullanıcı tarafından atanan kimliği sanal makine ölçek kümesine atayın.
  • Sanal makine ölçek kümesi bağımlılığını yönetilen kimliğin oluşturulmasına ve anahtar kasasına erişim vermenin sonucuna bildirin.
  • Key Vault VM uzantısını bildirin ve başlangıçta gözlemlenen sertifikaları almasını zorunlu tutun. Daha fazla bilgi için Windows için Key Vault VM uzantısı resmi belgelerine bakın.
  • Service Fabric VM uzantısının tanımını Key Vault VM uzantısına bağlı olarak güncelleştirin ve küme sertifikası bildirimini parmak izinden ortak ada dönüştürün.

Dekont

Bu değişiklikler aynı kaynağın kapsamına giren tek bir adım olarak yapılıyor.

  "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')]",
  } 
  }
  ]

Yukarıdaki kodda açıkça listelenmese de, anahtar kasası sertifika URL'sinin sanal makine ölçek kümesinin OsProfile bölümünden kaldırıldığını unutmayın.

Son adım, sertifika bildirimini parmak izinden ortak ada dönüştürmek için küme tanımını güncelleştirmektir. Ayrıca veren parmak izlerini sabitleyeceğiz:

  "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')]"
        },
  ]

Bu noktada, daha önce bahsedilen güncelleştirmeleri tek bir dağıtımda çalıştırabilirsiniz. Service Fabric Kaynak Sağlayıcısı hizmeti, küme sertifikalarını parmak izinden ortak ada dönüştürme segmentinde açıklandığı gibi küme yükseltmesini birkaç adımda böler.

Analiz ve gözlemler

Bu bölüm, bu makale boyunca sunulan kavramları ve süreçleri açıklamanın yanı sıra diğer bazı önemli yönlere dikkat çekmek için hazırlanmıştır.

Sertifika sağlama hakkında

Key Vault VM uzantısı, sağlama aracısı olarak önceden belirlenmiş bir sıklıkta sürekli olarak çalışır. Gözlemlenen bir sertifikayı alamazsa, satırda bir sonrakine devam eder ve sonraki döngüye kadar hazırda bekler. Küme önyükleme aracısı olarak Service Fabric VM uzantısı, kümenin oluşturulabilmesi için bildirilen sertifikaları gerektirir. Bu da Service Fabric VM uzantısının yalnızca küme sertifikalarının başarıyla alınmasından sonra, burada json "provisionAfterExtensions" : [ "KVVMExtension" ]" yan tümcesi ve Key Vault VM uzantısının json "requireInitialSync": true ayarıyla belirtildikten sonra çalışabileceği anlamına gelir.

Bu, Key Vault VM uzantısına, ilk çalıştırmada (dağıtım veya yeniden başlatmadan sonra), tümü başarıyla indirilene kadar gözlemlenen sertifikaları arasında geçiş yapması gerektiğini gösterir. Bu parametrenin false olarak ayarlanması, küme sertifikalarının alınamamasıyla birlikte küme dağıtımının başarısız olmasına neden olur. Buna karşılık, gözlemlenen sertifikaların yanlış veya geçersiz bir listesiyle ilk eşitlemenin gerekli olması, Key Vault VM uzantısının başarısız olmasına ve kümenin dağıtılamamasına neden olur.

Sertifika bağlama, açıklandı

Key Vault VM uzantısı linkOnRenewal bayrağını ve false olarak ayarlandığını fark etmiş olabilirsiniz. Bu ayar, bu bayrak tarafından denetlenen davranışı ve kümenin çalışması üzerindeki etkilerini ele alır. Bu davranış Windows'a özgüdür.

Tanımına göre:

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

TLS bağlantısı kurmak için kullanılan sertifikalar genellikle S kanalı Güvenlik Desteği Sağlayıcısı aracılığıyla tanıtıcı olarak alınır. Diğer bir ifadeyle, istemci sertifikanın özel anahtarına doğrudan erişmez. S kanalı, CERT_RENEWAL_PROP_ID sertifika uzantısı biçiminde kimlik bilgilerinin yeniden yönlendirilmesini veya bağlanmasını destekler.

Bu özellik ayarlanırsa, değeri yenileme sertifikasının parmak izini temsil eder ve bu nedenle S kanalı bunun yerine bağlı sertifikayı yüklemeyi dener. Aslında, S kanalı bu bağlantılı ve umalım ki son sertifikaya sahip olana kadar döngüsel listeden geçiş yapacaktır ve bu sertifika yenileme işareti olmadan olacaktır. Bu özellik, zaman aşımına uğramış sertifikalar gibi durumlardan kaynaklanan kullanılabilirlik kaybına karşı büyük bir risk azaltma özelliğidir.

Diğer durumlarda, tanılanması ve azaltılması zor olan kesintilerin nedeni olabilir. S kanalı, sertifikanın istemci tarafından doğrulanmasına katılan konu, verenler veya diğer belirli özniteliklerden bağımsız olarak sertifikaların yenileme özelliklerinde çapraz geçişini koşulsuz olarak yürütür. Sonuçta elde edilen sertifikanın ilişkili özel anahtarı yok veya anahtarın potansiyel tüketicisine ACL olarak verilmemiş olması mümkündür.

Bağlama etkinleştirilirse, Key Vault VM uzantısı, anahtar kasasından gözlemlenen bir sertifikayı aldığında, yenileme uzantısı özelliği aracılığıyla bunları bağlamak için eşleşen, mevcut sertifikaları bulmaya çalışır. Eşleştirme yalnızca konu alternatif adını (SAN) temel alır ve şu örneklerde gösterildiği gibi mevcut iki sertifika varsa çalışır: A: Sertifika adı (CN) = "Alice'in donatıları", SAN = {"alice.universalexports.com"}, yenileme = '' B: CN = "Bob's bits", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, yenileme = ''

C sertifikasının Key Vault VM uzantısı tarafından alındığını varsayalım: CN = "Mallory'nin kötü amaçlı yazılımı", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Sertifika A'nın SAN listesi C'lere tamamen dahil edilir ve bu nedenle A.renewal = C.thumbprint. Sertifika B'nin SAN listesi C'lerle ortak bir kesişime sahiptir, ancak buna tam olarak dahil değildir, bu nedenle B.renewal boş kalır.

A sertifikasında bu durumdaki AcquireCredentialsHandle'ı (S kanalı) çağırma girişimi aslında uzak tarafa C gönderir. Service Fabric söz konusu olduğunda, bir kümenin Aktarım alt sistemi karşılıklı kimlik doğrulaması için S-channel kullanır ve bu nedenle daha önce açıklanan davranış, kümenin temel iletişimini doğrudan etkiler. Yukarıdaki örnekten devam ederek ve A'nın küme sertifikası olduğunu varsayarak bundan sonra ne olacağı aşağıdakilere bağlıdır:

  • C'nin özel anahtarı Service Fabric'in çalıştığı hesaba ACLed değilse, özel anahtarı alma (SEC_E_UNKNOWN_CREDENTIALS veya benzeri) hatalarıyla karşılaşırsınız.
  • C'nin özel anahtarı erişilebilir durumdaysa, diğer düğümler tarafından döndürülen yetkilendirme hatalarını görürsünüz (CertificateNotMatched, yetkisiz vb.).

Her iki durumda da aktarım başarısız olur ve küme çökebilir. Belirtiler farklılık gösterir. İşleri daha da kötü hale getirmek için bağlama, Key Vault VM uzantısının gözlemlenen sertifikaları listesinin sırasına, anahtar kasasındaki yenileme zamanlamasına ve hatta alma sırasını değiştirecek geçici hatalara göre dikte edilen yenileme sırasına bağlıdır.

Bu tür olaylara karşı hafifletmek için aşağıdakileri öneririz:

  • Farklı kasa sertifikalarının konu alternatif adlarını karıştırmayın. Her kasa sertifikasının farklı bir amaca hizmet etmesi ve konusu ve SAN'ın bunu özgüllükle yansıtması gerekir.

  • SAN listesine konu ortak adını ekleyin (tam anlamıyla CN=<subject common name>).

  • Devam etme konusunda emin değilseniz Key Vault VM uzantısıyla sağlanan sertifikalar için yenilemede bağlamayı devre dışı bırakın.

    Dekont

    Bağlamayı devre dışı bırakmak, Key Vault VM uzantısının en üst düzey özelliğidir ve tek tek gözlemlenen sertifikalar için ayarlanamaz.

Kullanıcı tarafından atanan yönetilen kimliği neden kullanmalıyım? Kullanmanın etkileri nelerdir?

Önceki JSON kod parçacıklarından da görüldüğü gibi, hem dönüştürmenin başarısını garanti etmek hem de kümenin kullanılabilirliğini korumak için işlemlerin ve güncelleştirmelerin belirli bir sıralaması gerekir. Özellikle, sanal makine ölçek kümesi kaynağı gizli dizileri tek bir güncelleştirmede (kullanıcının perspektifinden) almak için kimliğini bildirir ve kullanır.

Kümeyi önyükleyen Service Fabric VM uzantısı, Key Vault VM uzantısının tamamlanmasına bağlıdır ve bu da gözlemlenen sertifikaların başarıyla alınmasına bağlıdır.

Key Vault VM uzantısı, anahtar kasasına erişmek için sanal makine ölçek kümesinin kimliğini kullanır. Bu, anahtar kasasındaki erişim ilkesinin sanal makine ölçek kümesinin dağıtımından önce zaten güncelleştirilmiş olması gerektiği anlamına gelir.

Yönetilen kimlik oluşturma işlemini atmak veya başka bir kaynağa atamak için dağıtım işlecinin, şablonda başvuruda bulunan diğer kaynakları yönetmek için gereken rollere ek olarak abonelikte veya kaynak grubunda gerekli role (ManagedIdentityOperator) sahip olması gerekir.

Güvenlik açısından, sanal makine ölçek kümesinin Azure kimliğiyle ilgili bir güvenlik sınırı olarak kabul edildiğini hatırlayın. Bu, VM'de barındırılan tüm uygulamaların ilke olarak VM'yi temsil eden bir erişim belirteci edinebileceği anlamına gelir. Yönetilen kimlik erişim belirteçleri kimliği doğrulanmamış Örnek Meta Veri Hizmeti uç noktasından alınır. VM'nin paylaşılan veya çok kiracılı bir ortam olduğunu düşünüyorsanız, küme sertifikalarını alma yöntemi belirtilmeyebilir. Ancak, sertifika otomatik kaydı için uygun tek sağlama mekanizmasıdır.

Sorun giderme ve sık sorulan sorular

S: Key Vault tarafından yönetilen bir sertifikaya program aracılığıyla nasıl kaydolabilirim?

Key Vault belgelerinden verenin adını bulun ve aşağıdaki betikte değiştirin:

  $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

S: Sertifika bildirilmemiş veya belirtilmemiş bir veren tarafından verildiğinde ne olur? Belirli bir PKI'nın etkin verenlerinin kapsamlı listesini nereden edinebilirim?

Sertifika bildirimi veren parmak izlerini belirtiyorsa ve sertifikanın doğrudan vereni sabitlenmiş verenler listesine eklenmiyorsa, kökünün istemci tarafından güvenilir olup olmadığına bakılmaksızın sertifika geçersiz kabul edilir. Bu nedenle, verenler listesinin güncel olduğundan emin olmak kritik önem taşır. Yeni bir verenin tanıtılması nadir görülen bir olaydır ve sertifikalar verilmeye başlamadan önce yaygın olarak kullanıma sunulması gerekir.

Genel olarak PKI, IETF RFC 7382'ye uygun olarak bir sertifikasyon uygulaması bildirimi yayımlar ve korur. Diğer bilgilerin yanı sıra, deyimi tüm etkin verenleri içerir. Bu listenin program aracılığıyla alınması bir PKI'dan diğerine farklılık gösterebilir.

Microsoft iç PKI'leri için yetkili verenleri almak için kullanılan uç noktalar ve SDK'lar hakkında iç belgelere başvurduğunuzdan emin olun. Küme tanımlarının beklenen tüm verenleri içerdiğinden emin olmak için bu listeyi düzenli aralıklarla gözden geçirmek küme sahibinin sorumluluğundadır.

S: Birden çok PKI destekleniyor mu?

Evet. Küme bildiriminde aynı değere sahip birden çok CN girdisi bildiremezsiniz, ancak aynı CN'ye karşılık gelen birden çok PKI'den verenleri listeleyebilirsiniz. Bu önerilen bir uygulama değildir ve sertifika saydamlığı uygulamaları bu tür sertifikaların verilmesini engelleyebilir. Ancak, bir PKI'dan diğerine geçiş için bir araç olarak, bu kabul edilebilir bir mekanizmadır.

S: Geçerli küme sertifikası CA tarafından verilmediyse veya hedeflenen konuya sahip değilse ne olur?

Hedeflenen konuya sahip bir sertifika alın ve parmak iziyle ikincil olarak kümenin tanımına ekleyin. Yükseltme başarıyla tamamlandıktan sonra, sertifika bildirimini ortak ada dönüştürmek için başka bir küme yapılandırma yükseltmesi başlatın.