0

I am trying to manually create a key and CSR for a new Windows AD CS Enterprise Subordinate CA (Windows Server 2019).

I'd like to store the key in the modern Microsoft Software Key Storage Provider.

It fails with Provider type not defined. 0x80090017 (-2146893801 NTE_PROV_TYPE_NOT_DEF).

The command I use is: certreq.exe -new C:\requestconfig.inf C:\certificate.req

The C:\requestconfig.inf file is this:

[Version]
Signature= "$Windows NT$"


[NewRequest]
Subject = "CN=My Subordinate CA"

HashAlgorithm = sha256
KeyAlgorithm = RSA
KeyLength = 2048

ProviderName = "Microsoft Software Key Storage Provider"
KeyContainer = "My Subordinate CA"
ExportableEncrypted = true
MachineKeySet = true
RequestType = PKCS10
SuppressDefaults = true
SecurityDescriptor = "D:P(A;OICI;0xd01f01ff;;;BA)(A;OICI;0xd01f01ff;;;SY)"


[RequestAttributes]
CertificateTemplate = SubCA


[Extensions]
2.5.29.15 = "{critical}{hex}03020186" ; Key Usage (critical): Digital Signature, Certificate Signing, CRL Signing
2.5.29.19 = "{critical}{text}ca=1&pathlength=1" ; Basic Constraints (critical)
1.3.6.1.4.1.311.21.1 = "{hex}020100" ; CA Version V0.0

Troubleshooting Steps

I checked that the CSP is valid by running certutil -csplist:

[...]
Provider Name: Microsoft Strong Cryptographic Provider
Provider Type: 1 - PROV_RSA_FULL

Provider Name: Microsoft Software Key Storage Provider

Provider Name: Microsoft Passport Key Storage Provider
[...]

It does not have a provider type, but nonetheless, I added ProviderType = 0 and ProviderType = 1 to the config, to no avail.

I was able to use a very similar config to create my root certificate:

[Version]
Signature= "$Windows NT$"


[NewRequest]
Subject = "CN=My Root CA"

HashAlgorithm = sha256
KeyAlgorithm = RSA
KeyLength = 4096
;KeyUsage = CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_CERT_SIGN_KEY_USAGE | CERT_CRL_SIGN_KEY_USAGE

ProviderName = "Microsoft Software Key Storage Provider"
KeyContainer = "My Root CA"
ExportableEncrypted = true
MachineKeySet = true
RequestType = Cert
SuppressDefaults = true
SecurityDescriptor = "D:P(A;OICI;0xd01f01ff;;;BA)(A;OICI;0xd01f01ff;;;SY)


[Extensions]
2.5.29.15 = {critical}{hex}03020186 ; Key Usage (critical): Digital Signature, Certificate Signing, CRL Signing
2.5.29.19 = {critical}{text}ca=1&pathlength=None ; Basic Constraints (critical)
1.3.6.1.4.1.311.21.1 = {hex}020100 ; CA Version V0.0

The main difference is that with this config, I create a key and certificate instead of a key and CSR. The differences are: RequestType is Cert and not PKCS10 and it does not have the RequestAttributes section. This config did not fail with NTE_PROV_TYPE_NOT_DEF.

What is causing the sudden failure with the config for my sub CA?

Daniel
  • 6,940
  • 6
  • 33
  • 64

1 Answers1

0

You have to add:

KeySpec=0

to NewRequest section. certreq defaults to AT_EXCHANGE while CNG providers do not support KeySpec.

Just out of curiosity, why you do not use ADCS CA installation wizard to generate the CA request?

Crypt32
  • 6,639
  • 1
  • 15
  • 33
  • Two reasons. (1) It adds the EKU of Client and Server Authentication, which should not be part of a CA certificate, in my opinion. I know that the RFC does permits an EKU. This is a design choice. (2) To add Basic Constraints path length **and** mark the extension as critical. – Daniel Jan 04 '22 at 10:27
  • 1
    Reason (1) is simply incorrect. CA installation wizard does not add any EKU by default. You can add Basic Constraints settings using CAPolicy.inf file. I would strongly recommend to use ADCS CA installation wizard instead of certreq workaround. – Crypt32 Jan 04 '22 at 10:30
  • Seems you are right with (1). I probably made a mistake setting up my test lab. As for (2), the docs state that all settings defined in the file [are applied to a root CA certificate and all certificates issued by the root CA](https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file). So when I add the critical flag to the KeyUsage extension, this will always also be critical on any issued certificate? So I should use that setting and that file on the root CA instead of the subordinate CA that also issues end-entity certs? – Daniel Jan 05 '22 at 10:37
  • 1
    You should set critical flag in all certificates explicitly. For CA certs via CAPolicy.inf and via request/cert template setting for end entity certs. – Crypt32 Jan 05 '22 at 11:03