Windows Server 2025 Azure AD CS: Key Storage Provider Seçim Sorunu ve Çözümü

Windows Server 2025 üzerinde yeni Active Directory Certificate Services (AD CS) ortamı kurarken ilginç problemle karşılaşabilirsiniz.

Özellikle sunucu Microsoft Azure üzerinde çalışıyorsa, Certificate Templates konsolunda sertifika şablonunun Cryptography sekmesine girip:

Provider Category > Key Storage Provider seçildiğinde aşağıdaki hata alınabiliyor: The device that is required by this cryptographic provider is not found on this system. Türkçe karşılığıyla: şifreleme sağlayıcısı tarafından gerekli olan cihaz sistemde bulunamadı.

İlk bakışta sorun CNG, TPM, AD CS veya sertifika şablonuyla ilgili gibi görünse yapılan inceleme problemin Azure üzerinde bulunan Microsoft Azure Integrated HSM Key Storage Provider ilişkili olduğunu gösteriyor.

Problem Nasıl Ortaya Çıkıyor?

Windows Server 2025 üzerinde AD CS kurulumu tamamlandıktan sonra standart sertifika şablonları oluşturulabiliyor sertifika üretimi başarılı şekilde gerçekleştirilebiliyor.

Örneğin mevcut yapı içerisinde:

• AD CS çalışıyor.
• Certification Authority sağlıklı.
• CNG çalışıyor.
• Microsoft Software Key Storage Provider mevcut.
• RSA sertifikaları oluşturulabiliyor.
• ECDSA sertifika isteği oluşturulabiliyor.

Ancak Certificate Templates konsolunda şablon açılıp Cryptography sekmesine gidildiğinde

Provider Category Legacy Cryptographic Service Provider, Key Storage Provider

değerine çevrildiğinde konsol hata veriyor. nedenle Microsoft Software Key Storage Provider gibi çalışan sağlayıcılar dahi seçilemiyor.

Sorun farklı şablonlarda tekrarlanabiliyor. Örneğin:

• Kerberos Authentication
• Web Server
• CNG tabanlı sertifika şablonları

Öncelikle CSP KSP Kavramlarını Anlamak

Windows’ta kriptografik işlemler uzun yıllar Cryptographic Service Provider (CSP) mimarisi üzerinden gerçekleştirildi. Daha sonra Microsoft, Cryptography API: Next Generation (CNG) mimarisini geliştirdi.

CNG tarafında ana bileşenlerden biri, Key Storage Provider (KSP) yapısıdır.

Basitçe:

Eski yapıYeni yapıCSPKSPCryptoAPICNGLegacy providerModern providerGeleneksel RSA işlemleriRSA + ECC gibi modern algoritmalar

Özellikle ECC/ECDSA gibi modern algoritmaların kullanılabilmesi açısından KSP/CNG yapısı önemlidir. nedenle AD CS ortamlarında mümkün olduğunda modern CNG tabanlı yapıların kullanılması tercih edilebilir.

İlk Kontrol: Cryptographic Provider’lar

İlk olarak sunucuda bulunan CSP KSP’leri kontrol edebiliriz:

certutil -csplist

Azure üzerindeki Windows Server 2025 sisteminde aşağıdaki gibi provider’lar görülebilir:

Microsoft Software Key Storage Provider Microsoft Azure Integrated HSM Key Storage Provider Microsoft Passport Key Storage Provider Microsoft Platform Crypto Provider Microsoft Smart Card Key Storage Provider

Burada dikkat çeken provider:

Microsoft Azure Integrated HSM Key Storage Provider

oluyor. Ancak komutun sonunda:

CertUtil: -csplist command FAILED: 0x80090030 NTE_DEVICE_NOT_READY

hatası görülebiliyor. İlk etapta hata problemin kaynağı gibi düşünülebilir. Fakat yapılan testlerde aynı hata, Azure dışında çalışan düzgün çalışan Windows Server 2025 sisteminde görülebiliyor. Özellikle TPM bulunmayan sistemlerde Microsoft Platform Crypto Provider nedeniyle NTE_DEVICE_NOT_READY görülmesi mümkün. Dolayısıyla hata tek başına asıl problemin kaynağı değil.

CNG Key Isolation Servisini Kontrol Edelim

CNG’nin kullandığı Key Isolation servisinin çalıştığını kontrol ediyoruz:

Get-Service KeyIso

Beklenen sonuç:

Status Name DisplayName ------ ---- ----------- Running KeyIso CNG Key Isolation

Servis çalışıyorsa noktada CNG servis tarafında belirgin problem bulunmuyor.

Certification Authority Yapısını Kontrol Etmek

CA’nın hangi provider’ı kullandığını kontrol etmek gerekiyor:

certutil -getreg CA\CSP

Örneğin:

Provider Microsoft Software Key Storage Provider ProviderType 0 CNGPublicKeyAlgorithm RSA CNGHashAlgorithm SHA256 MachineKeyset 1

durumda CA’nın kendisi legacy CSP kullanmıyor. Dolayısıyla sorunun CA’nın kriptografik yapılandırmasından kaynaklanmadığını söyleyebiliriz.

TPM Secure Boot Kontrolü

Azure VM üzerinde TPM bulunup bulunmadığı kontrol edilebilir:

Get-Tpm

Örneğin:

TpmPresent False TpmReady False

Sistem UEFI çalışıyor diye:

Get-ComputerInfo | Select-Object BiosFirmwareType

Secure Boot kontrolü:

Confirm-SecureBootUEFI

Burada TPM veya Secure Boot’un kullanılmıyor olması ilk bakışta şüpheli görünse Microsoft Software Key Storage Provider ECDSA işlemlerinin çalışıyor olması sorunun doğrudan TPM kaynaklı olmadığını gösteriyor.

Microsoft Software KSP Gerçekten Çalışıyor ?

Bunu doğrudan test etmek için:

certutil -csp "Microsoft Software Key Storage Provider" -key

komutu kullanılabilir.Ayrıca ECDSA tabanlı sertifika isteği oluşturulabilir.

Örneğin:

[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=ECDSA Test" KeyAlgorithm = ECDSA_P256 ProviderName = "Microsoft Software Key Storage Provider" MachineKeySet = TRUE Exportable = TRUE RequestType = PKCS10 HashAlgorithm = SHA256

Daha sonra:

certreq -new ecdsa.inf.req

çalıştırılır. İşlem başarılı oluyorsa:

• CNG çalışıyor,
• Microsoft Software KSP çalışıyor,
• ECDSA çalışıyor,
• Windows’un kriptografik altyapısında genel problem bulunmuyor demektir.

durumda problem doğrudan Certificate Templates MMC tarafında aranmalıdır.

Azure Standart Windows Server Arasındaki Fark

İncelemenin en önemli noktalarından biri Azure üzerindeki Windows Server 2025 temiz Hyper-V Windows Server 2025 kurulumunun karşılaştırılması.

certutil -csplist çıktıları karşılaştırıldığında Azure sunucusunda bulunan ancak standart Windows Server kurulumunda bulunmayan önemli provider ortaya çıktı:

Microsoft Azure Integrated HSM Key Storage Provider

provider’ın registry kaydı incelendiğinde:

HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\ Microsoft Azure Integrated HSM Key Storage Provider

altında bulunduğu görülüyor. Provider’ın kullandığı DLL ise:

azihsmksp.dll

olarak karşımıza çıkıyor.

azihsmksp.dll Nereden Geliyor?

Registry üzerinden provider incelendiğinde:

Microsoft Azure Integrated HSM Key Storage Provider └── UM ├── Image = azihsmksp.dll └── 00010001 ├── Flags = 1 └── Functions = KEY_STORAGE

yapısı görülüyor. Azure VM üzerinde DLL:

C:\Windows\System32\azihsmksp.dll

altında bulunuyor. Dosyanın versiyonu örneğin:

FileVersion 3.2.57-0 ProductVersion 3.2.57-0

şeklinde. Temiz Hyper-V Windows Server 2025 kurulumunda ise DLL bulunmuyor. durum beklenen sonuç çünkü Hyper-V üzerindeki sistem Azure Integrated HSM altyapısını kullanmıyor.

Process Monitor İnceleme

Sorunun gerçekten provider ilişkili olup olmadığını anlamak için Process Monitor (ProcMon) kullanılarak Certificate Templates MMC işlemi izlenebilir.

Certificate Templates açılıp hata oluşturulduğunda.exe tarafından:

C:\Windows\System32\azihsmksp.dll

dosyasının yüklendiği görülebiliyor. Burada önemli ayrıntı var: DLL yüklenirken herhangi “DLL bulunamadı” veya belirgin dosya erişim hatası görülmüyor.

Yani problem:

DLL eksik

şeklinde değil. Provider yükleniyor ancak provider’ın daha sonraki CNG işlemlerinde problem ortaya çıkıyor.

A/B Testi Problemi Kesinleştirmek

sonraki adım provider’ın registry kaydını geçici olarak kaldırarak test etmek. Öncelikle mevcut yapı yedekleniyor:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Azure Integrated HSM Key Storage Provider" C:\Temp\AzureHSMKSP.reg

Daha sonra provider kaydı kaldırılıyor:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Azure Integrated HSM Key Storage Provider" /f

Sunucu yeniden başlatılıyor. sonuç oldukça ilginç Certificate Templates artık çalışıyor. Key Storage Provider seçilebiliyor.

Provider’ı Geri Getirdiğimizde Ne Oluyor?

Şimdi aynı registry kaydını geri yükleyelim:

reg import C:\Temp\AzureHSMKSP.reg

Sunucu yeniden başlatılıyor. Sonuç: Problem tekrar ortaya çıkıyor.

Yani çok net A/B testi elde ediyoruz:

Azure Integrated HSM KSP kayıtlı ↓ Certificate Templates çalışmıyor Provider kaydı kaldırıldı ↓ Certificate Templates çalışıyor Provider kaydı geri getirildi ↓ Certificate Templates tekrar çalışmıyor

test problemin Azure Integrated HSM KSP ilişkisini oldukça güçlü şekilde ortaya koyuyor.

CNG API Provider’ı Doğrudan Test Etmek if (-not ("NCryptEnumTest" -as [type])) { Add-Type @" using System; using System.Runtime.InteropServices; public static class NCryptEnumTest { [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] public struct NCryptAlgorithmName { [MarshalAs(UnmanagedType.LPWStr)] public string pszName; public int dwClass; public int dwAlgOperations; public int dwFlags; } [DllImport("ncrypt.dll", CharSet = CharSet.Unicode)] public static extern int NCryptOpenStorageProvider( out IntPtr phProvider, string pszProviderName, int dwFlags ); [DllImport("ncrypt.dll")] public static extern int NCryptEnumAlgorithms( IntPtr hProvider, int dwAlgOperations, out int pdwAlgCount, out IntPtr ppAlgList, int dwFlags ); [DllImport("ncrypt.dll")] public static extern int NCryptFreeBuffer( IntPtr pvInput ); [DllImport("ncrypt.dll")] public static extern int NCryptFreeObject( IntPtr hObject ); } "@ } function ConvertTo-HexStatus { param ( [Parameter(Mandatory)] [int]$Status ) $unsignedStatus = [BitConverter]::ToUInt32( [BitConverter]::GetBytes($Status), 0 ) return ('0x{0:X8}' -f $unsignedStatus) } $providerName = "Microsoft Azure Integrated HSM Key Storage Provider" $provider = [IntPtr]::Zero $algorithmList = [IntPtr]::Zero $count = 0 $openResult = [NCryptEnumTest]::NCryptOpenStorageProvider( [ref]$provider, $providerName, 0 ) $openResultHex = ConvertTo-HexStatus -Status $openResult Write-Host "" Write-Host "NCryptOpenStorageProvider" -ForegroundColor Cyan Write-Host "Provider $providerName" Write-Host "Result $openResultHex" Write-Host "Result decimal $openResult" Write-Host "Provider open $($provider -ne [IntPtr]::Zero)" Write-Host "" if ($openResult -ne 0) { throw "NCryptOpenStorageProvider failed with $openResultHex" } try { $enumResult = [NCryptEnumTest]::NCryptEnumAlgorithms( $provider, 0, [ref]$count, [ref]$algorithmList, 0 ) $enumResultHex = ConvertTo-HexStatus -Status $enumResult Write-Host "NCryptEnumAlgorithms" -ForegroundColor Cyan Write-Host "Result $enumResultHex" Write-Host "Result decimal $enumResult" Write-Host "Algorithm count $count" Write-Host "Buffer returned $($algorithmList -ne [IntPtr]::Zero)" Write-Host "" if ( $enumResult -eq 0 -and $algorithmList -ne [IntPtr]::Zero -and $count -gt 0 ) { $structType = [NCryptEnumTest+NCryptAlgorithmName] $structSize = [Runtime.InteropServices.Marshal]::SizeOf($structType) Write-Host "Supported algorithms" -ForegroundColor Cyan Write-Host "" for ($i = 0; $i -lt $count; $i++) { $itemPointer = [IntPtr]::Add( $algorithmList, $i * $structSize ) $algorithm = [Runtime.InteropServices.Marshal]::PtrToStructure( $itemPointer, $structType ) [PSCustomObject]@{ Name = $algorithm.pszName Class = $algorithm.dwClass Operations = ('0x{0:X8}' -f $algorithm.dwAlgOperations) Flags = ('0x{0:X8}' -f $algorithm.dwFlags) } } } elseif ($enumResult -eq 0) { Write-Warning "NCryptEnumAlgorithms succeeded but returned no algorithms." } else { Write-Warning "NCryptEnumAlgorithms failed with $enumResultHex" } } finally { if ($algorithmList -ne [IntPtr]::Zero) { [void][NCryptEnumTest]::NCryptFreeBuffer($algorithmList) } if ($provider -ne [IntPtr]::Zero) { [void][NCryptEnumTest]::NCryptFreeObject($provider) } }

Son aşamada provider’ın Windows CNG API üzerinden nasıl davrandığını doğrudan test etmek mümkün.

Burada iki önemli API kullanılıyor:

NCryptOpenStorageProvider()

NCryptEnumAlgorithms()

İlk API provider’ın açılıp açılamadığını kontrol ediyor. İkinci API ise provider tarafından desteklenen algoritmaları listeliyor.

İlk işlem başarılı:

NCryptOpenStorageProvider Result 0x00000000 Provider open True

Yani:

Provider açılabiliyor.

Ancak algoritmaları listelemeye çalıştığımızda:

NCryptEnumAlgorithms Result 0x80090035 Algorithm count 0 Buffer returned False

sonucunu alıyoruz. Buradaki kritik hata kodu:

0x80090035

kod:

NTE_DEVICE_NOT_FOUND

anlamına geliyor. certutil doğrulanabilir:

certutil -error 0x80090035

Sonuç:

NTE_DEVICE_NOT_FOUND The device that is required by this cryptographic provider is not found on this platform.

İşte Certificate Templates MMC’ gördüğümüz:

The device that is required by this cryptographic provider is not found on this system.

hatasının kaynağı burada ortaya çıkıyor.

Asıl Problem Nedir?

Özetlemek gerekirse Azure üzerinde bulunan Windows Server 2025 image’ında ek olarak:

Microsoft Azure Integrated HSM Key Storage Provider

kayıtlı geliyor.

Provider Windows tarafından başarıyla yüklenebiliyor:

NCryptOpenStorageProvider() → SUCCESS

Ancak provider desteklediği algoritmaları listelemeye çalıştığında:

NCryptEnumAlgorithms() → 0x80090035 → NTE_DEVICE_NOT_FOUND

hatası oluşuyor. Sorun burada başlıyor. Certificate Templates MMC’nin hatayı yalnızca ilgili provider sınırlı tutmak yerine genel provider seçim sürecini etkilediği görülüyor.

Sonuç olarak aslında sorunsuz çalışan:

Microsoft Software Key Storage Provider

gibi provider’lar Certificate Templates arayüzünde seçilemiyor.

Çözüm / Geçici Çözüm

an için pratik çözüm, Microsoft Azure Integrated HSM Key Storage Provider registry kaydını kaldırmak.

Öncelikle mutlaka yedek alın:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Azure Integrated HSM Key Storage Provider" C:\Temp\AzureHSMKSP.reg

Ardından:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Azure Integrated HSM Key Storage Provider" /f

Sunucuyu yeniden başlattıktan sonra Certificate Templates MMC tekrar açıldığında:

Cryptography → Provider Category → Key Storage Provider seçeneğinin normal şekilde çalışması bekleniyor.

Geri Alma İşlemi

Yaptığımız değişikliği geri almak istersek:

reg import C:\Temp\AzureHSMKSP.reg

komutu kullanılabilir. Ancak burada önemli uyarı. işlem resmi Microsoft çözümü olarak değerlendirilmemeli.

Azure Integrated HSM provider’ının registry kaydının kaldırılması, provider’a ihtiyaç duyan başka uygulama veya servisleri etkileyebilir.

nedenle üretim ortamında değişiklik yapmadan önce:

• Provider’ın kullanılıp kullanılmadığı kontrol edilmeli,
• Registry yedeği alınmalı,
• Değişiklik mümkünse test ortamında doğrulanmalı,
• Azure HSM kullanan uygulamalar varsa etkileri değerlendirilmelidir.

problem ilk bakışta:

• AD CS problemi,
• Certificate Template problemi,
• CNG problemi,
• TPM problemi,
• Secure Boot problemi

gibi görünebilir. Ancak yapılan kontroller sonucunda:

AD CS → Çalışıyor CNG → Çalışıyor Software KSP → Çalışıyor ECDSA → Çalışıyor CA Configuration → Normal TPM → Asıl neden değil Certificate Templates → Azure KSP kayıtlıyken hata veriyor Azure Integrated HSM KSP → NCryptEnumAlgorithms başarısız

sonucuna ulaşılıyor. Özellikle iki test oldukça belirleyici:

NCryptOpenStorageProvider() → 0x00000000

NCryptEnumAlgorithms() → 0x80090035 → NTE_DEVICE_NOT_FOUND

Dolayısıyla problem, Azure image içerisinde kayıtlı olan Microsoft Azure Integrated HSM Key Storage Provider’ın mevcut cihaz/altyapı algoritma sorgulaması sırasında başarısız olması hatanın Certificate Templates MMC tarafından uygun şekilde izole edilememesi gibi görünüyor.

nedenle Azure üzerinde Windows Server 2025 AD CS / PKI kurulumu yapıyorsanız Certificate Templates içerisinde Key Storage Provider seçeneğini açarken: The device that is required by this cryptographic provider is not found on this system. hatasıyla karşılaşıyorsanız, ilk kontrol edilmesi gereken noktalardan biri:

Microsoft Azure Integrated HSM Key Storage Provider

olmalıdır. Ayrıca bulgunun workaround olduğunu, kalıcı resmi Microsoft çözümü olarak değerlendirilmemesi gerektiğini özellikle belirtmek gerekir. 31 Temmuz 2026 tarihinde benzer davranışla ilişkili AziHSM-Guest GitHub issue’suna dikkat çekilmiştir. nedenle Azure Integrated HSM bileşeninin ilgili davranışının daha geniş problemle ilişkili olma ihtimali bulunmaktadır.

Detaylar: michaelwaterman.nl