Microsoft Cloud PKI ile Sertifika Yönetimi: Mimari, Dağıtım Modelleri ve Adım Adım Yapılandırma

---

Cloud PKI Nedir?

Microsoft Cloud PKI, Intune üzerinden yönetilen; Intune Suite, bağımsız Cloud PKI eklentisi veya uygun Microsoft 365 E5 lisansı kapsamında kullanılabilen bulut tabanlı bir sertifika yetkilisi (CA) hizmetidir. Amaç, Intune yönetilen cihazlara SCEP tabanlı kullanıcı ve cihaz sertifikası dağıtılan senaryolarda şirket içi CA, NDES ve Intune Certificate Connector altyapısına olan ihtiyacı ortadan kaldırmak veya mevcut PKI üzerindeki yükü azaltmaktır. Klasik senaryoda sertifika dağıtmak için Active Directory Certificate Services (AD CS), NDES sunucusu, CRL dağıtım noktaları ve Intune sertifika bağlayıcısı gerekir. Cloud PKI bu bileşenleri desteklenen senaryolarda bulut tarafına taşır.

Hizmet, Intune yönetim merkezinin içine gömülüdür. Kök CA ve veren CA’yı portal üzerinden dakikalar içinde oluşturursunuz. Sertifika dağıtımı SCEP profilleri ile yapılır. Yüksek erişilebilirlik, yama ve bakım Microsoft tarafındadır.

Anahtar depolamada bir ayrım vardır. Lisanslı Cloud PKI CA’ları Azure Managed HSM anahtarları kullanır. Trial döneminde oluşturulan CA’lar ise software-backed anahtar kullanır. Önemli nokta: trial sırasında oluşturulan bir CA sonradan lisanslansa bile anahtarları HSM tabanlı anahtarlara dönüştürülemez. Üretim için CA’yı lisanslı durumda oluşturun.

Bu doküman mimariyi, iki dağıtım modelini ve uçtan uca yapılandırmayı ele alır.

Mimari

Cloud PKI, PKI en iyi uygulamalarına uygun iki katmanlı (two-tier) bir hiyerarşi kurar.

Kök CA (Root CA). Tüm PKI’nın güven çıpasıdır. İlk oluşturulan CA’dır ve veren CA sertifikasını imzalar. Klasik şirket içi PKI tasarımlarında kök CA’nın çevrimdışı tutulması önerilir. Cloud PKI’de ise kök CA anahtarlarının güvenliği, HSM kullanımı ve hizmet operasyonları Microsoft tarafından yönetilir. Bu model, müşterinin yönettiği klasik offline kök CA tasarımıyla birebir aynı değildir.

Veren CA (Issuing CA). Cihazlara asıl sertifikaları veren CA’dır. Kök CA’ya bağlı (subordinate) çalışır. Tüm sertifika taleplerini SCEP üzerinden karşılar.

SCEP hizmeti. Cloud PKI, dahili bir SCEP (Simple Certificate Enrollment Protocol) hizmeti içerir. Bu hizmet sertifika kayıt yetkilisi (Certificate Registration Authority) görevi görür. Şirket içi NDES ihtiyacını ortadan kaldıran kısım budur.

Sertifika verme akışı

Yönetici, cihazlar check-in yapmadan önce şunları hazırlar: kök ve veren CA’yı oluşturur, her ikisi için güvenilen sertifika profillerini atar, platforma özel SCEP sertifika profillerini atar.

Sonrasında akış şöyle işler:

1. Cihaz Intune hizmetine check-in yapar. Güvenilen sertifikayı ve SCEP profillerini alır.
2. Cihaz, SCEP profiline göre bir sertifika imzalama talebi (CSR) oluşturur. Özel anahtar cihazda üretilir ve cihazı asla terk etmez. CSR ve SCEP challenge, buluttaki SCEP hizmetine gönderilir (profildeki SCEP URI adresine).
3. SCEP hizmeti talebi challenge’a karşı doğrular.
4. Veren CA, CSR’ı imzalar.
5. İmzalanan sertifika cihaza teslim edilir.

Özel anahtarın cihazda kalması kritik bir güvenlik detayıdır. Anahtar hiçbir zaman bulut tarafına aktarılmaz.

Desteklenen platformlar ve algoritmalar

Windows, macOS, iOS/iPadOS ve Android desteklenir. Cihazın Intune’a kayıtlı olması ve platformun Intune cihaz yapılandırması SCEP sertifika profilini desteklemesi gerekir.

İmzalama tarafında RSA desteklenir. Anahtar boyutları 2048, 3072 ve 4096’dır.

Dağıtım Modelleri

İki model vardır. Karar, mevcut PKI altyapınıza ve güven zinciri gereksiniminize bağlıdır.

Model 1: Cloud PKI kök CA

Hem kök CA hem veren CA bulutta oluşturulur. Her ikisi de tenant’a özeldir, herkese açık değildir. Tek bir tenant içinde, tenant başına üç CA sınırı dâhilinde, bir veya daha fazla PKI yapısı oluşturabilirsiniz. Kök CA altında birden fazla veren CA yer alabilir.

Bu model sıfırdan bulut yerel bir PKI kurmak isteyenler içindir. Mevcut bir kök CA’ya bağlanma zorunluluğu yoktur.

Model 2: Kendi CA’nızı getirin (BYOCA)

Veren CA yine bulutta oluşturulur ama kendi özel kök CA’nıza bağlanır. Örneğin şirket içi AD CS veya Microsoft dışı bir sertifika hizmeti. Mevcut PKI altyapınız varsa aynı kök CA’yı korur ve dış köke zincirlenen bir veren CA oluşturursunuz. Dış özel CA’nın N+ katmanlı hiyerarşileri de desteklenir.

BYOCA’da bir fark vardır. Veren CA oluşturulurken Intune tarafında bir CSR üretilir. Bu CSR’ı sizin özel CA’nızın imzalaması gerekir. Yani güven zinciri sizin mevcut kökünüzden akar.

Model seçimi

Kriter	Cloud PKI kök CA	BYOCA
Mevcut PKI altyapısı	Yok veya önemsiz	Var ve korunmak isteniyor
Güven çıpası	Bulutta yeni kök	Sizin mevcut kökünüz
Kurulum karmaşıklığı	Düşük	Orta (CSR imzalama adımı var)
Dış uygulamalarla güven	Yeni kökü dağıtmanız gerekir	Mevcut kök zaten güvenilir olabilir

Mevcut ortamda halihazırda güvenilen bir kök CA varsa ve dış sistemlerle sertifika güveni önemliyse BYOCA daha az sürtünme yaratır. Tamamen bulut yerel bir başlangıç için Model 1 daha hızlıdır.

Önkoşullar ve Lisanslama

Lisanslama

Cloud PKI, Intune Plan 1 veya Plan 2’ye ek bir abonelik gerektirir. Üç seçenekten biriyle erişilir:

• Microsoft Intune Suite lisansı
• Microsoft Cloud PKI bağımsız eklenti (standalone add-on) lisansı
• Microsoft 365 E5 lisansı

1 Temmuz 2026’dan itibaren Intune Suite özelliklerinin bir kısmı doğrudan Microsoft 365 E5’e dahil edildi. Cloud PKI, Endpoint Privilege Management ve Enterprise App Management bu kapsamda E5’e girdi. Aynı tarihte Microsoft 365 E5’in Teams içeren ticari SKU’sunun ABD liste fiyatı kullanıcı başına aylık 57 USD’den 60 USD’ye yükseldi. Teams içermeyen E5 SKU’sunun fiyatları farklıdır. Öncesinde Cloud PKI’ye erişim tipik olarak kullanıcı başına yaklaşık 2 USD liste fiyatlı ayrı bir eklenti gerektiriyordu. Bölgesel fiyat ve anlaşma farklılıkları olabilir.

Burada iki inceliği ayırmak gerekir. Liste fiyatı 1 Temmuz’da yürürlüğe girdi ama mevcut müşteriler yeni fiyatı genellikle bu tarihten sonraki sözleşme yenilemelerinde görür. Yeni hizmet planlarının tenant’lara açılması ise ayrı ve aşamalı bir süreç. Microsoft, ilgili Intune özelliklerinin rollout’unun 1 Ağustos 2026’ya kadar tamamlanacağını ve her tenant’a Message Center üzerinden en az 30 gün önceden bildirim gönderileceğini belirtiyor. Bu yüzden bazı tenant’larda yeni hizmet planları çoktan aktif, bazılarında hâlâ bekliyor olabilir. Kendi tenant’ınızdaki durumu lisans hizmet planlarından kontrol edin.

E3 veya altındaysanız Cloud PKI E5’e dahil değildir. Bu durumda Intune Suite ya da bağımsız Cloud PKI eklentisiyle erişirsiniz. Bunun maliyet açısından mantıklı olup olmadığı tek bir değişkene bağlı değildir. Kullanıcı sayısı, mevcut lisanslar, mevcut PKI yatırımı ve şirket içi altyapının işletme maliyetiyle birlikte değerlendirilmelidir.

Rol ve izinler (RBAC)

Yönetim merkezinde oturum açan hesabın CA oluşturma iznine sahip olması gerekir. Microsoft Entra Intune Administrator (Intune hizmet yöneticisi) rolü bu izne yerleşik olarak sahiptir. Alternatif olarak özel bir role Cloud PKI izinleri atayabilirsiniz.

Cloud PKI için atanabilen izinler:

• Read CAs. CA özelliklerini okuma.
• Create certificate authorities. Kök veya veren CA oluşturma.
• Disable and reenable CAs. CA’yı devre dışı bırakma ve yeniden etkinleştirme. CA yaşam döngüsü işlemlerinde kullanılır.
• Revoke issued leaf certificates. Veren CA tarafından verilen sertifikaları manuel iptal etme. Bu izin ayrıca Read CAs iznini de gerektirir.

Cihaz tarafı

Cihazlar Intune’a kayıtlı olmalıdır. Platform, Intune cihaz yapılandırması SCEP sertifika profilini desteklemelidir.

Şirket İçi PKI ile Cloud PKI Karşılaştırması

Cloud PKI’ye geçmeden önce sorulacak asıl soru şu: mevcut senaryonuz bulut modeline uyuyor mu? Klasik AD CS tabanlı şirket içi PKI hâlâ birçok senaryoda daha esnektir. Cloud PKI ise dar ama düşük bakımlı bir alan sunar.

Kriter	Şirket içi PKI (AD CS + NDES)	Cloud PKI
Altyapı	CA sunucuları, NDES, Intune sertifika bağlayıcısı, CRL/AIA noktaları ve tasarıma bağlı olarak reverse proxy veya DMZ	Yok, Microsoft yönetir
Anahtar depolama	Kendi HSM veya CA sunucusu	Lisanslı CA’larda Azure Managed HSM; trial CA’larda software-backed key
İşletme yükü	Yama, yüksek erişilebilirlik, CA ve NDES altyapısı kurumda	HSM, platform, yama ve yüksek erişilebilirlik Microsoft’ta; CA, trust, profil ve renewal yaşam döngüsü kurumda
CRL yayını	Kendi dağıtım noktalarınızı işletirsiniz	Bulutta, Intune yönetir
Kapsam	Domain-joined, Intune dışı, sunucular, her cihaz	Yalnızca Intune yönetilen cihazlar
Sertifika türleri	Sunucu, istemci, akıllı kart, özel şablonlar	Intune’a kayıtlı kullanıcı ve cihazlar için SCEP tabanlı yaprak sertifikalar; kullanım amacı CA ve SCEP profilinde tanımlanan EKU’larla sınırlandırılır.
Sunucu sertifikası (SSL, RADIUS)	Var	Yok
Gelişmiş senaryolar	OCSP ve akıllı kart desteği; ACME ve donanım token senaryoları ek entegrasyon gerektirebilir	Yerleşik OCSP ve ACME yok; donanım token senaryoları sınırlı
Hizmet bağımlılığı	Kurumsal ağ, CA, NDES ve CRL/AIA erişimine bağlı	Intune ve Cloud PKI internet uç noktalarına bağlı
Maliyet	Windows Server, CAL, işletme emeği	E5’e dahil, Intune Suite veya eklenti
İdeal senaryo	Hibrit, olgun mevcut PKI, geniş kapsam	Bulut yerel, NDES’i emekliye ayırma, Wi-Fi/VPN/cihaz kimliği

Hangi durumda hangisi

Mevcut PKI’niz kararlı, iyi yönetiliyor ve gereksinimleri karşılıyorsa taşınmak için acele etmeyin. Değişim maliyeti kazançtan büyük olabilir.

Bulut öncelikli bir ortamsanız, NDES ve CRL altyapısını sürdürmekten kurtulmak istiyorsanız ve tek ihtiyacınız Intune cihazlarına SCEP tabanlı Wi-Fi, VPN veya cihaz kimliği sertifikası dağıtmaksa Cloud PKI güçlü bir uyum sağlar. Sıfır güven (zero-trust) stratejilerinde cihaz kimliği için doğal bir seçenektir.

Sunucu sertifikası, Intune dışı cihazlar, akıllı kart veya ACME otomasyonu gerekiyorsa Cloud PKI tek başına yetmez. Şirket içi PKI’yi korumanız ya da üçüncü taraf bir çözüm değerlendirmeniz gerekir.

İki dünya bir arada da mümkün. BYOCA modelinde bulut veren CA’yı mevcut şirket içi kökünüze bağlarsınız. Böylece Intune cihazlarını buluttan sertifikalandırırken mevcut PKI’nizi diğer senaryolar için ayakta tutabilirsiniz.

Adım Adım Yapılandırma

Aşağıdaki ayrıntılı akış Model 1 (bulut kök CA) içindir. BYOCA’nın CSR imzalama ve sertifika yükleme farkları Adım 2 sonunda ayrıca özetlenmiştir.

Adım 1: Kök CA oluşturma

Cihazlara sertifika vermeden önce güven çıpası olacak kök CA’yı oluşturmanız gerekir. En az bir kök CA olmadan veren CA oluşturulamaz.

1. Microsoft Intune yönetim merkezinde oturum açın.
2. Tenant administration > Cloud PKI yolunu izleyin ve Create‘i seçin.
3. Basics ekranında ad ve açıklama girin. Örnek ad: Contoso C-PKI Root CA.
4. Next ile Configuration settings ekranına geçin.
5. CA type için Root CA seçin.
6. Validity period için 5, 10, 15, 20 veya 25 yıl seçin. Özel bir süre gerekiyorsa Microsoft Graph API kullanmanız gerekir.
7. Extended Key Usages altında CA’nın kullanım amacını seçin. Güvenlik nedeniyle CA’lar seçili kullanımlarla sınırlıdır. Kök CA’da tanımlamadığınız bir EKU, veren CA’da seçenek olarak çıkmaz. Bu noktayı planlarken dikkate alın.
8. Subject attributes altında CN ve diğer alanları doldurun.
9. Encryption altında anahtar boyutu ve hash algoritmasını seçin: RSA-2048/SHA-256, RSA-3072/SHA-384 veya RSA-4096/SHA-512. Bu seçim, daha sonra SCEP profillerinde kullanılabilecek en yüksek anahtar boyutu ve hash seviyesini belirler. 1024 anahtar boyutu ve SHA-1 desteklenmez.
10. Ayarları gözden geçirip Create ile oluşturun.

Adım 2: Veren CA oluşturma

1. Yine Tenant administration > Cloud PKI > Create yolunu izleyin.
2. Basics ekranında ad girin. Örnek: Contoso C-PKI Issuing CA.
3. CA type için Issuing CA seçin.
4. Root CA source olarak Intune seçin, ardından Root CA listesinden daha önce oluşturduğunuz kök CA’yı seçin. BYOCA kullanıyorsanız Root CA source olarak Bring your own root CA seçilir; bu akış Adım 2 sonunda ayrıca özetlenmiştir.
5. Validity period için 2, 4, 6, 8 veya 10 yıl seçin. Veren CA’nın geçerlilik süresi kök CA’dan uzun olamaz. Özel bir süre için Microsoft Graph API kullanılır.
6. Extended Key Usages altında kullanım amacını seçin. Kullanıcı veya cihaz kimlik doğrulaması için genellikle Client Authentication EKU’su seçilir. Cloud PKI, aşırı geniş olduğu için Any Purpose (2.5.29.37.0) EKU’sunu desteklemez. Ayrıca yalnızca kök CA’da tanımlı EKU’lar burada seçilebilir. Burada bir kavram karışıklığına dikkat edin. Cloud PKI, Intune’a kayıtlı kullanıcı veya cihaz için SCEP tabanlı yaprak sertifikası üretir. Sertifikanın kullanım amacı seçilen EKU’lara bağlıdır. Wi-Fi ve VPN gibi senaryolarda genellikle Client Authentication kullanılır. Wi-Fi, VPN veya RADIUS sunucusunun TLS kimliğini doğrulayan sunucu sertifikasını Cloud PKI vermez. O sunucu sertifikası ayrı bir CA hizmetinden alınmalı ve ilgili güven zinciri cihazlara ayrıca dağıtılmalıdır.
7. Subject attributes doldurun. Buradaki CN, istemcilerin gördüğü CA adı olur.
8. Gerekirse Scope tags ekleyin.
9. Review + create ile ayarları kontrol edip Create ile oluşturun.

CA oluşturulduktan sonra EKU, subject ve benzeri temel özellikler değiştirilemez. Sonradan yeni bir EKU gerekirse yeni bir CA oluşturmanız gerekir. Bu yüzden EKU planlamasını baştan doğru yapın.

BYOCA farkı. Model 2’de veren CA oluşturma akışı ek adımlar içerir. Root CA source olarak Bring your own root CA seçilir. Geçerlilik süresi portalda seçilmez, süreyi CSR’ı imzalayan özel CA belirler. Anahtar boyutu (RSA 2048, 3072 veya 4096) seçilir. CA oluşturulduğunda durumu Signing required görünür. Bu noktada CA özelliklerinden CSR dosyasını (.req) indirir, kendi özel CA’nızla imzalar ve imzalanmış veren CA sertifikasını ilgili zinciriyle birlikte Intune’a geri yüklersiniz. CA aktif olduktan sonra güven ve SCEP profillerini hazırlarsınız. Yani BYOCA’da güven zinciri sizin mevcut kökünüzden akar ve mevcut özel CA altyapınız korunur.

Adım 3: Güvenilen sertifika profilleri

Cihazların zinciri doğrulayabilmesi için güven çıpasına güvenmesi gerekir.

1. Veren CA’yı açın, Properties‘e gidin.
2. SCEP URI değerini kopyalayıp not edin. SCEP profilinde kullanacaksınız.
3. Sertifikaları ayrı ayrı indirin. Cloud PKI listesinden kök CA’yı açın, Properties > Download ile CA’nın public certificate dosyasını indirin. Sonra listeye dönüp veren CA’yı açın ve aynı işlemle veren CA sertifikasını indirin. İşlemi her CA için tekrarlayın.
4. Hedeflediğiniz her işletim sistemi platformu için kök CA sertifikasına yönelik bir güvenilen sertifika profili (Trusted certificate) oluşturun ve hedef cihazlara atayın. Kök CA güven çıpasıdır ve zorunludur. Microsoft’un Cloud PKI yapılandırma kılavuzu ayrıca veren CA sertifikası için de ayrı bir güvenilen sertifika profili oluşturulmasını tarif eder. Veren CA sertifikası bazı platformlarda AIA üzerinden edinilebilse de zincirin platform davranışına bağımlı kalmaması için dağıtılması önerilir. Android hedeflerinde tam zincirin açıkça dağıtılması özellikle önemlidir.
5. Profilleri hedef cihazlara atayın.

Not: Cloud PKI sertifikalarını doğrulayacak RADIUS, VPN gibi relying party sistemlerinde de kök ve veren CA zincirinin kurulu olması gerekir. Aksi halde cihazda sertifika olsa bile kimlik doğrulama başarısız olur.

Kök CA güvenilen sertifika profili uygulanmadan güven zinciri kurulamaz. Veren CA sertifikasının da ayrıca dağıtılması, ara sertifikanın AIA üzerinden otomatik keşfine olan bağımlılığı kaldırır ve özellikle Android tarafında zincir sorunlarını önler. Bu adım sık atlanır ve dağıtım hatalarının yaygın nedenidir.

Adım 4: SCEP sertifika profili

1. Devices > Manage devices > Configuration > Create yolunu izleyin.
2. Platform olarak cihaz platformunu seçin.
3. Profile olarak SCEP certificate seçin. Gerekirse Templates > SCEP certificate altından bulun.
4. Root Certificate alanında, veren CA’nın bağlı olduğu kök CA için oluşturduğunuz güvenilen sertifika profilini seçin. Veren CA güvenilen sertifika profilinin de aynı hedef cihaz veya kullanıcılara ayrıca atandığından emin olun.
5. Sertifika türü, konu adı formatı, konu alternatif adı (SAN), geçerlilik süresi ve anahtar kullanımını yapılandırın.
6. Extended Key Usage için genelde Client Authentication yeterlidir. Any Purpose EKU’su desteklenmez. Seçtiğiniz EKU’nun veren CA’da tanımlı olduğundan emin olun, aksi halde sertifika verilmez.
7. SCEP Server URLs alanına Adım 3’te kopyaladığınız SCEP URI değerini girin. URI içindeki {{CloudPKIFQDN}} placeholder’ını olduğu gibi bırakın. Intune, profili cihaza gönderirken bu değeri *.manage.microsoft.com ad alanındaki doğru FQDN ile değiştirir. Aynı SCEP profilinde NDES URL’leriyle Cloud PKI URL’lerini karıştırmayın.
8. Profili hedef kullanıcı veya cihaz gruplarına atayın.

Adım 5: Doğrulama

1. Hedef bir test cihazında senkronizasyonu tetikleyin.
2. Sertifika verildikten sonra sertifika deposunu kontrol edin.
3. Yaprak (leaf) sertifikayı açın ve Certification Path sekmesine bakın. Üç sertifikadan oluşan temiz bir zincir görmelisiniz: en üstte kök CA, ortada bulut veren CA, en altta yaprak sertifika. Bu yapı iki katmanlı bir CA hiyerarşisidir.
4. Zincir kırıksa kök veya veren CA güvenilen sertifika profillerinin eksik, yanlış ya da henüz uygulanmamış olup olmadığını kontrol edin. Bu özellikle Android tarafında sık görülür.

Sınırlamalar ve Dikkat Edilecekler

Cloud PKI güçlüdür ama dar kapsamlıdır. Aşağıdaki noktaları mimari kararından önce netleştirin.

• Yalnızca Intune yönetilen cihazlar. Cloud PKI, SCEP sertifikalarını Intune’a kayıtlı cihazlara verir. Intune dışı SCEP cihazları kapsam dışıdır.
• Sunucu uç noktası sertifikaları yok. Cloud PKI, iç web sunucuları, RADIUS sunucuları, VPN gateway’leri veya ağ cihazları için klasik TLS sunucu sertifikası dağıtmaz. Sertifikaları Intune’a kayıtlı kullanıcı ve cihazlara SCEP profilleri üzerinden verir; kullanım amacı CA ve profilde tanımlanan EKU’lara bağlıdır.
• Gelişmiş senaryolar yok. Gelişmiş OCSP yapılandırmaları, ACME otomasyonu ve geniş akıllı kart / YubiKey senaryoları desteklenmez.
• Tenant başına CA kotası. Güncel Microsoft dokümantasyonuna göre tenant başına en fazla üç CA oluşturulabilir. Kök CA, Cloud PKI veren CA ve BYOCA veren CA’ların tamamı aynı kotaya dahildir. Yani bir kök ve iki veren CA oluşturduğunuzda kapasiteyi doldurmuş olursunuz. Bu sınır hem lisanslı hem trial tenant’lar için geçerlidir.
• Data residency seçeneği yok. Cloud PKI için müşterinin veri bölgesi seçebileceği bir data-residency seçeneği şu anda bulunmuyor. Regülasyonlu ortamlar için mimari değerlendirme maddesidir.
• Portalda 1.000 sertifika görünümü. Veren CA’da View all certificates görünümü ilk 1.000 sertifikayı gösterir. Tümünü görmek için Devices > Monitor > Certificates yolunu kullanın.
• Raporlama gecikmesi. Sertifika raporları 24 saatte bir güncellenir. Sertifika cihaza gelmiş olsa da portalda hemen görünmeyebilir.
• CA sonradan düzenlenemez. Oluşturulduktan sonra EKU, subject ve benzeri temel CA özellikleri değiştirilemez. Yeni bir EKU gerekirse yeni CA oluşturmanız gerekir.
• Hizmet bağımlılığı. Sertifika verme ve yenileme sırasında cihazların Intune ve Cloud PKI internet uç noktalarına erişimi gerekir.
• Android Device Owner sınırları. Fully Managed, Dedicated ve Corporate-Owned Work Profile için SCEP profillerinde sertifika raporlaması yoktur. Bu profillerle verilen sertifikalar Intune üzerinden iptal edilemez. İptali harici bir süreçle veya doğrudan CA tarafında yönetmeniz gerekir. Dedicated cihazlarda SCEP sertifikası Wi-Fi, VPN ve kimlik doğrulama için desteklenir ancak uygulama kimlik doğrulaması (app authentication) için desteklenmez.

Gereksinimleriniz bu sınırların içinde kalıyorsa Cloud PKI net bir kazanç sağlar. Daha geniş sertifika kapsamı, Intune dışı cihazlar, ACME veya akıllı kart senaryoları gerekiyorsa üçüncü taraf bir PKI çözümü değerlendirmeniz gerekir.

Sorun Giderme İpuçları

• Sertifika hiç gelmiyor. Önce güvenilen kök profilinin cihaza atanıp atanmadığını doğrulayın. En yaygın kök nedendir.
• Zincir kırık görünüyor. Kök ve veren CA sertifikalarının doğru sırayla dağıtıldığını ve güvenilen profilin en üst kökü işaret ettiğini kontrol edin.
• EKU eksik. Veren CA’da beklediğiniz bir EKU çıkmıyorsa kök CA’da o EKU’nun tanımlı olduğundan emin olun. Kökte tanımlanmayan EKU veren tarafta seçilemez.
• SCEP URI hataları. SCEP profiline girilen URI’nin veren CA Properties ekranındaki değerle birebir aynı olduğunu doğrulayın.

Değerlendirme: Kime Uygun, Kime Değil

Cloud PKI’nin E5’e dahil olması güçlü bir sinyal gibi görünüyor ama burada bir tuzak var. Dahil olması, sizin senaryonuza uygun olması demek değildir. 1 Temmuz’da yetkilendirme açıldı diye her yere yaymak yanlış karar olur. Doğru soru “artık ücretsiz mi” değil, “ihtiyacım Cloud PKI’nin kapsamına giriyor mu”.

Pratikte üç grup var.

Net uygun. Bulut yerel veya sıfırdan başlayan ortamlar. Henüz PKI’niz yoksa ya da NDES ve sertifika bağlayıcısını emekliye ayırmak istiyorsanız Cloud PKI güçlü bir kazanç. İhtiyacınız Intune cihazlarına Wi-Fi, VPN ve cihaz kimliği sertifikası dağıtmakla sınırlıysa daha da net. Sıfır güven mimarisinde cihaz kimliği için doğal seçim. Bu grupta asıl değer “ücretsiz CA” değil, NDES ve bağlayıcı işletme yükünün tamamen kalkması.

Duruma bağlı. Olgun bir şirket içi PKI’si olan hibrit ortamlar. Burada söküp atma refleksi yanlış. Mevcut PKI çalışıyorsa BYOCA modeliyle ilerleyin. Bulut veren CA’yı mevcut kökünüze bağlar, Intune cihazlarını buluttan sertifikalandırır, geri kalan her şeyi mevcut altyapıda tutarsınız. En düşük sürtünmeli yol budur.

Uygun değil. Sunucu sertifikası (RADIUS, iç SSL), Intune dışı cihazlar, akıllı kart ve YubiKey, ACME otomasyonu veya gelişmiş OCSP gerektiren ortamlar. Cloud PKI bunların hiçbirini karşılamaz. Bu senaryolarda ya şirket içi PKI’yi korursunuz ya da daha geniş kapsamlı üçüncü taraf bir çözüme bakarsınız. E5’e dahil olması bu tabloyu değiştirmez.

Özetle benim değerlendirmem şu. Cloud PKI, genel amaçlı kurumsal PKI’nin birebir yerine geçen bir ürün değildir. En güçlü olduğu alan, Intune yönetilen cihazlar için SCEP tabanlı kullanıcı ve cihaz sertifikası dağıtımında CA barındırma, HSM, CRL/AIA, yaprak sertifika verme, yenileme, iptal ve raporlama yükünün büyük bölümünü Microsoft’a devretmesidir. Yani sadece NDES’i değil, o senaryodaki işletme yükünün önemli kısmını kaldırır. Ancak süreç tamamen hands-off değil. Trust tasarımı, EKU tasarımı, güven profili dağıtımı, RADIUS ve VPN relying party yapılandırması, SCEP profilleri ve atamalar, CA yaşam döngüsü ve yenileme işlemleri kurumun sorumluluğunda kalır. Yenilemede Cloud PKI yeni anahtar çiftiyle bir staged CA oluşturur, siz test edip aktive edersiniz ve production SCEP URI korunduğu için profilleri değiştirmeniz gerekmez. Operasyonel yükünüz bu alandaysa ve ihtiyacınız SCEP cihaz kimliğiyle sınırlıysa geçiş kolay ve kârlı. Kapsam bunun dışına çıktıkça değeri düşer. Kararı lisans değil, senaryo vermeli.

Özet

Cloud PKI, Intune’a gömülü iki katmanlı bir sertifika hizmetidir. Tamamen bulut tabanlı modelde, desteklenen Intune SCEP senaryoları için şirket içi CA, NDES ve Certificate Connector ihtiyacını ortadan kaldırabilir. BYOCA modelinde ise mevcut özel PKI güven çıpası korunurken Intune cihazlarına yönelik veren ve SCEP hizmeti buluta taşınır. Kurulum kök CA, veren CA, güvenilen sertifika profilleri ve SCEP profili sırasıyla ilerler. 1 Temmuz 2026’dan itibaren uygun Microsoft 365 E5 tenant’larında ayrı Cloud PKI eklentisi satın alma gereksinimi ortadan kalkmıştır, ancak bu mimari geçiş ve işletme maliyetlerini tamamen sıfırlamaz. Yalnızca Intune yönetilen cihazlara yönelik olması ve sunucu sertifikası vermemesi gibi sınırları mimari kararından önce net değerlendirilmelidir.