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

admin

Ağu 10, 2026 - 20:33

0 1

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

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

Özellikle sunucu Microsoft Azure üzerinde çalışıyorsa, Certificate Templates konsolunda bir 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: Bu ş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 de, yapılan inceleme problemin Azure üzerinde bulunan Microsoft Azure Integrated HSM Key Storage Provider ile 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 ve 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 bir şablon açılıp Cryptography sekmesine gidildiğinde ve:

Provider Category , Legacy Cryptographic Service Provider, Key Storage Provider

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

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

Kerberos Authentication
Web Server
Diğer CNG tabanlı sertifika şablonları

Öncelikle CSP ve 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ı
CSP	KSP
CryptoAPI	CNG
Legacy provider	Modern provider
Geleneksel RSA işlemleri	RSA + ECC gibi modern algoritmalar

Özellikle ECC/ECDSA gibi modern algoritmaların kullanılabilmesi açısından KSP/CNG yapısı önemlidir. Bu 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 ve 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ı da görülebiliyor. İlk etapta bu hata problemin kaynağı gibi düşünülebilir. Fakat yapılan testlerde aynı hata, Azure dışında çalışan ve düzgün çalışan bir Windows Server 2025 sisteminde de 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 bu 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 bu noktada CNG servis tarafında belirgin bir problem bulunmuyor.

Certification Authority Yapısını Kontrol Etmek

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

certutil -getreg CA\CSP

Örneğin:

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

Bu 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 ve Secure Boot Kontrolü

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

Get-Tpm

Örneğin:

TpmPresent : False
TpmReady   : False

Sistem UEFI ile çalışıyor mu 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 de, Microsoft Software Key Storage Provider ve ECDSA işlemlerinin çalışıyor olması sorunun doğrudan TPM kaynaklı olmadığını gösteriyor.

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

Bunu doğrudan test etmek için:

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

komutu kullanılabilir.Ayrıca ECDSA tabanlı bir 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 test.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 bir problem bulunmuyor demektir.

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

Azure ile Standart Windows Server Arasındaki Fark

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

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

Microsoft Azure Integrated HSM Key Storage Provider

Bu 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 bir Hyper-V Windows Server 2025 kurulumunda ise bu DLL bulunmuyor. Bu durum beklenen bir sonuç çünkü Hyper-V üzerindeki sistem Azure Integrated HSM altyapısını kullanmıyor.

Process Monitor ile İnceleme

Sorunun gerçekten bu provider ile 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 mmc.exe tarafından:

C:\Windows\System32\azihsmksp.dll

dosyasının yüklendiği görülebiliyor. Burada önemli bir ayrıntı var: DLL yüklenirken herhangi bir “DLL bulunamadı” veya belirgin bir 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 ile Problemi Kesinleştirmek

Bir 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. Ve 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 bir 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

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

CNG API ile 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()

ve:

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

Bu kod:

NTE_DEVICE_NOT_FOUND

anlamına geliyor. certutil ile de 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’de gördüğümüz:

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

hatasının kaynağı da 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 bu hatayı yalnızca ilgili provider ile 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 da Certificate Templates arayüzünde seçilemiyor.

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

Şu 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 bir uyarı var. Bu işlem resmi bir Microsoft çözümü olarak değerlendirilmemeli.

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

Bu 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.

Bu 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 şu iki test oldukça belirleyici:

NCryptOpenStorageProvider()
→ 0x00000000

ve:

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ı ile algoritma sorgulaması sırasında başarısız olması ve bu hatanın Certificate Templates MMC tarafından uygun şekilde izole edilememesi gibi görünüyor.

Bu nedenle Azure üzerinde Windows Server 2025 ile AD CS / PKI kurulumu yapıyorsanız ve 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 bu bulgunun bir workaround olduğunu, kalıcı ve resmi bir Microsoft çözümü olarak değerlendirilmemesi gerektiğini özellikle belirtmek gerekir. 31 Temmuz 2026 tarihinde benzer davranışla ilişkili bir AziHSM-Guest GitHub issue’suna da dikkat çekilmiştir. Bu nedenle Azure Integrated HSM bileşeninin ilgili davranışının daha geniş bir problemle ilişkili olma ihtimali bulunmaktadır.

Detaylar: michaelwaterman.nl