How to Configure Windows Server Key Storage Provider (KSP) via PowerShell

The Cryptographic Software Limitation

In a traditional Windows Server environment, when an application like Microsoft IIS (Internet Information Services) needs an SSL certificate to host an HTTPS website, that certificate’s private key is stored in the software-based Windows Certificate Store. The problem with software-based key storage is that if a hacker gains local Administrator privileges on the server, they can use tools like Mimikatz to extract the private key directly from the hard drive, allowing them to perfectly impersonate your web server.

To prevent this, high-security environments use hardware cryptography, such as a physical Trusted Platform Module (TPM) chip on the motherboard, or a network-attached Hardware Security Module (HSM). When a private key is generated inside an HSM, it is physically impossible to extract it. The hardware literally will not allow the key to be exported.

To tell Windows Server to stop using the software-based Certificate Store and instead route all cryptographic operations down into the physical TPM or HSM hardware, you must configure a Key Storage Provider (KSP) via PowerShell.

Understanding CNG vs. CryptoAPI

Before configuring a KSP, you must understand the architecture. Older versions of Windows used the Legacy Cryptography API (CAPI), which relied on Cryptographic Service Providers (CSPs). Modern Windows Server editions use Cryptography API: Next Generation (CNG), which relies on Key Storage Providers (KSPs).

Microsoft provides the Microsoft Platform Crypto Provider (which routes to the physical TPM chip) and the Microsoft Software Key Storage Provider (the default software storage). If you purchase a network HSM (like a Thales or SafeNet device), you will install a custom KSP driver provided by the manufacturer.

Step 1: Listing Available Key Storage Providers

Before generating a key, you must identify exactly which KSPs are registered on your server. Open an elevated PowerShell session and execute:

certutil -csplist

Look for providers explicitly labeled as “Key Storage Provider.” You should see Microsoft Platform Crypto Provider if your server has an active, enabled TPM chip.

Step 2: Generating a Hardware-Backed Private Key

We will generate a 2048-bit RSA private key, but we will explicitly force Windows to generate it inside the physical TPM chip, making it non-exportable.

# Define the KSP to point to the TPM chip
$KSP = "Microsoft Platform Crypto Provider"

# Define the name of the new key container
$KeyName = "SecureWebServerKey"

# Instruct certutil to generate a new RSA 2048 key inside the TPM
certutil -csp $KSP -key -generate $KeyName RSA 2048

The terminal will output Signature test passed. The private key now exists, but it physically resides inside the silicon of the TPM chip. Windows only possesses a “pointer” to the key.

Step 3: Creating a Certificate Signing Request (CSR)

Now that the hardware key exists, you must generate a CSR to send to your Certificate Authority (like an internal Active Directory CA, or a public CA like DigiCert) so they can issue the public certificate.

Create a simple text file named request.inf with the following configuration:

[NewRequest]
Subject = "CN=secure-app.corp.local"
KeyContainer = "SecureWebServerKey"
ProviderName = "Microsoft Platform Crypto Provider"
MachineKeySet = true
Exportable = false
KeySpec = 1
KeyLength = 2048
HashAlgorithm = sha256
RequestType = PKCS10

(Notice that we explicitly reference the exact KeyContainer we generated in the TPM).

Now, execute the native Windows tool to generate the CSR based on that text file:

certreq -new request.inf request.csr

You now have a request.csr file. Send this to your CA.

Step 4: Binding the Certificate to the Hardware Key

When the Certificate Authority issues your final .cer public certificate (e.g., secure-app.cer), you must import it into Windows and mathematically bind it to the hidden hardware key.

certreq -accept secure-app.cer

The certreq engine will automatically scan the certificate, recognize the public key, look in its KSP database, find the matching private key container (SecureWebServerKey) inside the TPM, and fuse them together in the Windows Certificate Store.

If you open the IIS Manager and bind this new certificate to port 443, the web server will function perfectly. However, if a hacker gains root access and tries to export the certificate to a .pfx file, the “Export Private Key” option will be permanently grayed out. The server is completely secure against private key exfiltration.