Share via

7 Appendix B: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

Windows Client Releases

Server Role

Client Role

Windows 2000 Professional operating system

No

Yes

Windows XP operating system

No

Yes

Windows Vista operating system

No

Yes

Windows 7 operating system

No

Yes

Windows 8 operating system

No

Yes

Windows 8.1 operating system

No

Yes

Windows 10 operating system

No

Yes

Windows 11 operating system

No

Yes

Windows Server Releases

Server Role

Client Role

Windows 2000 Server operating system

Yes

Yes

Windows Server 2003 operating system

Yes

Yes

Windows Server 2008 operating system

Yes

Yes

Windows Server 2008 R2 operating system

Yes

Yes

Windows Server 2012 operating system

Yes

Yes

Windows Server 2012 R2 operating system

Yes

Yes

Windows Server 2016 operating system

Yes

Yes

Windows Server operating system

Yes

Yes

Windows Server 2019 operating system

Yes

Yes

Windows Server 2022 operating system

Yes

Yes

Windows Server 2025 operating system

Yes

Yes

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3.2.2: Windows 8.1 and later and Windows Server 2012 R2 and later support key attestation.

<2> Section 1.3.2.3: Windows Server v1803 operating system and later support Certificate Transparency processing. The Certificate Transparency feature is also supported in Windows Server 2016 via the instructions provided in [CertTransp].

<3> Section 1.3.3.1: Certificate templates were first introduced with the release of Windows 2000 Server. The Active Directory schema for this release defined a new class named pKICertificateTemplate (as specified in [MS-ADSC] section 2.222) and the unique attributes for this class. It was technically possible to modify the attributes of these pKICertificateTemplate objects, but such modifications were not supported by Microsoft. The attributes were not documented.

One of the requirements for the release of Windows Server 2003 was to support attribute modifications. To meet this requirement, a schema change was introduced that defined the following new attributes for the pKICertificateTemplate class.

  • msPKI-Template-Schema-Version: This attribute defines the pKICertificateTemplate class version and instructs the client and server as to those processing rules that apply to the object. For example, certificate template version 2 is a pKICertificateTemplate object where the value of msPKI-Template-Schema-Version is 2.

  • msPKI-Template-Minor-Version: With this attribute, the certificate template revision number has two parts (revision and msPKI-Template-Minor-Version). It can be used to identify the minimum revision required in an Windows Client Certificate Enrollment Protocol request.

In addition to the schema change, a new certificate template extension was introduced that can be added to a certificate request and can be used by clients to request a specific revision of a certificate template. For more information, see 2.2.2.7.7.2.

<4> Section 1.3.3.1: The MMC Certificate Templates snap-in that ships with applicable Windows Server releases automatically increments the minor revision value with each modification of a certificate template.

<5> Section 1.3.3.3: Microsoft offers an MMC snap-in to allow a customer to modify templates. However, the customer is not prohibited from using any other application to modify templates.

<6> Section 2.1: Windows XP sets the authentication level to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY (0x05).

<7> Section 2.1: By default, CAs on Windows Server 2012 operating system and later have IF_ENFORCEENCRYPTICERTREQUEST and IF_ENFORCEENCRYPTICERTADMIN auth levels set.

<8> Section 2.1: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTADMIN or IF_ENFORCEENCRYPTICERTREQUEST setting.

<9> Section 2.2.2.5: Windows 8.1 and later and Windows Server 2012 R2 and later support key attestation.

<10> Section 2.2.2.5: Windows 8.1 and later and Windows Server 2012 R2 and later support [TCG-Struct-V2].

<11> Section 2.2.2.7.4: Windows implementations set the value of the Client ID as follows:

Values for client application sending the request

Value

 Internal name

 Meaning

0

ClientIdNone

No information about the client application.

1

ClientIdXEnroll2003

The client application in XEnroll.dll shipped with Windows Server 2003.

2

ClientIdAutoEnroll2003

The client application in the Windows autoenrollment service shipped with Windows Server 2003.

3

ClientIdWizard2003

The client application in the enrollment wizard shipped with Windows Server 2003.

4

ClientIdCertReq2003

The client application in certreq.exe shipped with Windows Server 2003.

5

ClientIdDefaultRequest

The client application that uses Windows Vista and later enrollment classes.

6

ClientIdAutoEnroll

The client application in the Windows autoenrollment service shipped with Windows Vista and later.

7

ClientIdRequestWizard

The client application in the enrollment wizard shipped with Windows Vista  and later.

8

ClientIdEOBO

The client application that makes Enroll On Behalf Of (EOBO) requests.

9

ClientIdCertReq

The client application in certreq.exe shipped with Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10.

1000

ClientIdUserStart

The client application is not adequately described by the preceding entries.

<12> Section 2.2.2.7.7.4: This security extension is supported by the operating systems specified in [MSFT-CVE-2022-26931], each with its related KB article download installed.

<13> Section 2.2.2.7.9: In Windows 2000 operating system, Windows XP, and Windows Server 2003, the hash algorithm used is always set to SHA1. In Windows Vista and later and in Windows Server 2008 and later, the hash algorithm is defined by the certificate template that is used for enrollment. For more information, see section 3.2.2.6.2.1.4.5.4.

<14> Section 2.2.2.7.10: Windows 2000, Windows XP, and Windows Server 2003 do not support the "ExpirationDate" value for the OID szENROLLMENT_NAME_VALUE_PAIR (1.3.6.1.4.1.311.13.2.1).

<15> Section 2.2.2.7.10: To enable this feature for the Microsoft CA, follow the instructions as specified in [MSFT-EXIT].

Windows Server 2003 and later ignore the value of this attribute and instead copy the certificate to the following location:"%system%\certsrv\certenroll". The file name is the request ID with a '.cer' extension.

<16> Section 2.2.2.7.10: The RequestId attribute is available in Windows Server 2012 R2 and Windows Server 2016 only.

<17> Section 2.2.2.7.15: Support for szOID_ENROLL_AIK_INFO is included in Windows 10, Windows Server 2016, Windows Server operating system, and in Windows Server 2019 and later.

<18> Section 2.2.3.1: Applicable Windows Server releases use key recovery certificates that contain the following X.509v3 extensions that are specific to such releases:

  • Application Policies (Policy Identifier = Key Recovery Agent)

  • Certificate Template Name

  • Certificate Template Information

Key recovery certificates, when issued by a Windows enterprise CA, are automatically written to the configuration container of Active Directory. The actual certificates are published to the userCertificate attribute (as specified in [RFC4523]) of the KRA object when issued to a member of the domain administrators group in Active Directory.

<19> Section 3.1: Microsoft implements multiple clients of this protocol, including:

  •  Certificates snap-in for the Microsoft Management Console (MMC)

  •  Certreq.exe tool (see [MSDOCS-certreq] for more information)

  •  Certificate Autoenrollment (see [MSFT-AUTOENROLLMENT] for more information).

<20> Section 3.1.1: Windows clients implement an abstraction layer on top of the interfaces specified in this document. Windows 2000, Windows XP, and Windows Server 2003 support the interfaces documented in [MSDN-XEnroll]. Windows 2000, Windows XP, and Windows Server 2003 do not support the interfaces documented in [MSDN-CertEnroll].

<21> Section 3.1.1.4: Windows 2000 clients do not obtain a supported interface version from the server and always use the ICertRequestD interface.

<22> Section 3.1.1.4.3.1.1: Windows clients use the OS version structure defined in [MSDN-OSVERSIONINFO] to create a string in the format "A.B.C.D", where the A is the value of the dwMajorVersion field, B is the value of the dwMinorVersion field, C is the value of the dwBuildNumber field, and D is the value of the dwPlatformId. All numbers are represented in the decimal format. For example, the string "6.1.7600.2" represents Windows Server 2008 R2.

<23> Section 3.1.1.4.3.1.4: This format was designed by Netscape, and there are no Microsoft tools to create a request in this format. To construct a certificate request using this format, the SPKAC tool can be used (for more information, see [OPENSSL]).

<24> Section 3.1.1.4.3.2.1: Windows 8.1 and later and Windows Server 2012 R2 and later support the processing rules in section 3.1.1.4.3.4.

<25> Section 3.1.1.4.3.2.2: Windows 8.1 and later and Windows Server 2012 R2 and later support the processing rules in section 3.1.1.4.3.4.

<26> Section 3.1.1.4.3.3.1: The Microsoft client allows importing a request file during the enrollment implemented in the certificates snap-in for the MMC in Windows Vista and later and in Windows Server 2008 and later; and during web enrollment in Windows 2000, Windows XP, and Windows Server 2003.

<27> Section 3.1.1.4.3.4: Windows 8.1 and later and Windows Server 2012 R2 and later support key attestation.

<28> Section 3.1.1.4.3.4.1.2: Only Windows Server 2012 R2, Windows Server 2016, Windows Server operating system, and Windows Server 2019 and later support this behavior.

<29> Section 3.1.1.4.3.4.1.2: Windows 8.1 and later and Windows Server 2012 R2 and later support these processing rules.

<30> Section 3.1.1.4.3.4.2: Support for AIK Attestation (subject only) is included in Windows 10, Windows Server 2016, Windows Server operating system, and in Windows Server 2019 and later.

<31> Section 3.1.1.4.3.8.1: Pre-sign certificate processing is supported by the operating systems specified in [MSKB-5017379] and [MSKB-5017381], each with its related KB article download installed.

<32> Section 3.1.1.6: Windows Certificate MMC snap-in has a command to trigger this client.

<33> Section 3.1.1.6.2: Windows 8.1 and later and Windows Server 2012 R2 and later support this behavior.

<34> Section 3.1.2.1: In the Windows implementation, the Client_Intermediate_CA_Certificates collection is stored in the Windows registry using the following registry path:

HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\CA\Certificates\

A unique registry key for each intermediate CA certificate is added using the thumbprint of the certificate as the key name. Each element in Client_Intermediate_CA_Certificates is the BLOB value under the corresponding key (stored as a binary type).

<35> Section 3.1.2.1: In the Windows implementation, the Client_Root_CA_Certificates collection is stored in the Windows registry using the following registry path:

HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\

A unique registry key for each root CA certificate is added using the thumbprint of the certificate as the key name. Each element in Client_Root_CA_Certificates is the BLOB value under the corresponding key (stored as a binary type).

<36> Section 3.1.2.4.2.1: Windows 2000 does not support certificate templates with these versions. Windows XP and Windows Server 2003 do not support certificate templates that have the Certificate.Template.msPKI-Template-Schema-Version datum equal to 3. Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 do not support certificate templates that have the Certificate.Template.msPKI-Template-Schema-Version datum equal to 4.

<37> Section 3.1.2.4.2.1: Windows 8.1 and later and Windows Server 2012 R2 and later support this flag.

<38> Section 3.1.2.4.2.1: Windows 2000 does not process the Certificate.Template.msPKI-Template-Schema-Version datum and treats all templates with a Certificate.Template.msPKI-Template-Schema-Version datum less than 100 as templates that have the Certificate.Template.msPKI-Template-Schema-Version datum set to 1. Windows XP treats templates with the Certificate.Template.msPKI-Template-Schema-Version datum set to 0 the same as templates with Certificate.Template.msPKI-Template-Schema-Version datum set to 1.

<39> Section 3.1.2.4.2.1: Windows 2000 does not support certificate templates with these versions. Windows XP and Windows Server 2003 do not support certificate templates that have the Certificate.Template.msPKI-Template-Schema-Version datum equal to 3. Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 do not support certificate templates that have the Certificate.Template.msPKI-Template-Schema-Version datum equal to 4.

<40> Section 3.1.2.4.2.1: Windows 2000 does not process the Certificate.Template.msPKI-Template-Schema-Version datum and treats all templates with a Certificate.Template.revision datum less than 100 as templates that have the Certificate.Template.msPKI-Template-Schema-Version datum set to 1. Windows XP treats templates with the Certificate.Template.msPKI-Template-Schema-Version datum set to 0 the same as templates with Certificate.Template.msPKI-Template-Schema-Version datum set to 1.

<41> Section 3.1.2.4.2.2: The Microsoft Certificate Services client uses the following values for the Certificate.Template.msPKI-Template-Schema-Version datum:

  • When the datum does not exist: Windows can use this certificate template.

  • When the value = 1: Windows can use this certificate template.

  • When the value = 2: Windows XP, Windows Server 2003, and Windows Vista and later and Windows Server 2008 and later can use this certificate template.

  • When the value = 3: Windows 2000, Windows XP, and Windows Server 2003 cannot use this certificate template.

  • When the value = 4: Windows 8 and later and Windows Server 2012 and later can use this certificate template.

  • For other values, existing Windows clients ignore the certificate template.

<42> Section 3.1.2.4.2.2.1.5: The Microsoft Certificate Services client uses this flag with the cryptographic service provider (CSP) when creating the cryptographic keys.

<43> Section 3.1.2.4.2.2.1.8: Windows XP and later and Windows Server 2003 and later create this extension only if the Certificate.Template.msPKI-Template-Schema-Version datum equals 1 or is not initialized with any value.

<44> Section 3.1.2.4.2.2.1.9: Windows 2000 does not add certificate template OID extension as an attribute of the request.

<45> Section 3.1.2.4.2.2.2.2: Windows 8.1 and later and Windows Server 2012 R2 and later support these flags.

<46> Section 3.1.2.4.2.2.2.2: Windows 8.1 and later and Windows Server 2012 R2 and later support this behavior.

<47> Section 3.1.2.4.2.2.2.5: Windows clients default to RSA.

<48> Section 3.1.2.4.2.2.2.5: Windows clients default to set Read permissions on the key associated with the certificate request for the entity sending the certificate request.

<49> Section 3.1.2.4.2.2.2.5: Windows 8.1 and later and Windows Server 2012 R2 and later support this behavior.

<50> Section 3.1.2.4.2.2.2.5: Windows clients default to Triple Data Encryption Standard.

<51> Section 3.1.2.4.2.2.2.5: Windows clients default to 168.

<52> Section 3.1.2.4.2.2.2.5: Windows clients defaults to SHA1.

<53> Section 3.1.2.4.2.2.2.5: The Microsoft client uses the msPKI-Key-Usage value with the cryptographic service provider (CSP) when creating the cryptographic keys.

<54> Section 3.1.2.4.2.2.2.5: Windows clients default to all key usages.

<55> Section 3.1.2.4.2.2.2.6: CryptoAPI, a Windows cryptographic application programming interface, creates a union of the values in the Extended Key Usage and Application Policy extensions. The combined union will be used as the extended key usages for the certificate as specified in [RFC3280] section 4.2.1.5.

<56> Section 3.1.2.4.2.2.2.7: Windows 7 and later and Windows Server 2008 R2 and later support this flag.

<57> Section 3.1.2.4.2.2.2.8: Windows 8 and later and Windows Server 2012 and later ignore this flag.

<58> Section 3.1.2.4.2.2.2.8: Windows uses the Data Protection API (DPAPI) to protect private keys. For more information, see [MSDN-DPAPI].

<59> Section 3.1.2.4.2.2.2.8: Windows 2000, Windows XP, and Windows Server 2003 do not support this flag.

<60> Section 3.1.2.4.2.2.2.8: Windows 8 and later and Windows Server 2012 and later support this flag.

<61> Section 3.1.2.4.2.2.2.8: Windows 8 and later and Windows Server 2012 and later support this flag.

<62> Section 3.1.2.4.2.2.2.8: Windows 8.1 and later and Windows Server 2012 R2 and later support this flag.

<63> Section 3.1.2.4.2.2.2.8: Windows 8 and later and Windows Server 2012 and later implement the Client_Current_Version ADM element.

<64> Section 3.1.2.4.2.2.2.10: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 ignore the CT_FLAG_OLD_CERT_SUPPLIES_SUBJECT_AND_ALT_NAME flag.

<65> Section 3.2: Windows 2000 Server doesn't implement ICertRequestD2 interface.

<66> Section 3.2: All Microsoft CAs implement selection among the CA modes during setup.

<67> Section 3.2: CAs that run on Windows Server 2003 Datacenter Edition operating system, Windows Server 2003 Enterprise Edition operating system, Windows Server 2008 Datacenter operating system, and Windows Server 2008 Enterprise operating system implement key archival. CAs that run on Windows Server 2003 Standard Edition operating system and on Windows Server 2008 and later do not implement key archival.

<68> Section 3.2.1.1.4: Windows clients use this CA property for diagnostics information only on the operating system that hosts the CA. The Windows Client Certificate Enrollment Protocol does not depend on the value of this property.

CAs running on Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows Server 2008 Enterprise operating system, and Windows Server 2008 Datacenter operating system support key archival and are considered "advanced server". Windows Server 2003 Standard Edition and Windows Server 2008 and later CAs are considered "standard server".

<69> Section 3.2.1.4.2.1: Windows 2000 does not return an error.

<70> Section 3.2.1.4.2.1: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTREQUEST (section 3.2.1.1.4) setting.

<71> Section 3.2.1.4.2.1: If pdwDisposition was request failed (1, or an error code from [MS-ERREF]), the disposition messages include the following:

  • Error archiving private key.

  • Error parsing request.

  • Error verifying request signature or signing certificate.

  • Resubmitted by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was submitted by using the ResubmitRequest method of [MS-CSRA].

If pdwDisposition was request denied (2), the disposition messages include the following:

  • Denied by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was submitted by using the DenyRequest method of [MS-CSRA].

  • Denied by policy module.

  • Denied by policy module, combined with a descriptive error message such as: "Renewing a certificate with the 'xyz' Certificate Template failed because the renewal overlap period is longer than the certificate validity period."

  • Requested by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was formerly in a pending state and was issued by using the ResubmitRequest method of [MS-CSRA].

If pdwDisposition was certificate issued (3), the disposition messages include the following:

  • Requested by {domain\name} where {domain\name} is replaced with the user name of the caller.

  • Issued.

  • Issued, combined with a descriptive informational message from the policy algorithm.

  • Resubmitted by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was formerly in a pending state and was issued by using the ResubmitRequest method of [MS-CSRA].

If pdwDisposition was request pending (5), the disposition messages include the following:

  • Taken under submission.

  • Taken under submission, combined with an informational message from the policy algorithm.

  • The disposition message contains text in the system language of the server.

<72> Section 3.2.1.4.2.1.2: The ExpirationDate value of the OID szENROLLMENT_NAME_VALUE_PAIR (1.3.6.1.4.1.311.13.2.1) is supported in Windows Vista and later and in Windows Server 2008 and later.

<73> Section 3.2.1.4.2.1.2: The ExpirationDate value of the OID szENROLLMENT_NAME_VALUE_PAIR (1.3.6.1.4.1.311.13.2.1) is supported in Windows Vista and later and in Windows Server 2008 and later.

<74> Section 3.2.1.4.2.1.2: Only a Windows 2000 CA publishes the certificate to the location that is provided by the requestor through this attribute.

<75> Section 3.2.1.4.2.1.3: Windows 2000, Windows Server 2003, and Windows Server 2008 CAs will set this value to 0 in this case.

<76> Section 3.2.1.4.2.1.4.1.1: Microsoft standalone CAs will not add a requested extension to the certificate unless it is configured as allowed locally by the administrator. By default when the CA is installed, the following extensions are allowed:

  • 1.2.840.113549.1.9.15 - SMIME Capabilities

  • 1.3.6.1.4.1.311.21.1 - CA Version

  • 1.3.6.1.4.1.311.21.2 - Previous CA Certificate Hash

  • 2.5.29.15 - Key Usage

  • 1.3.6.1.4.1.311.10.9.1 - Cross-Certificate Distribution Points

  • 1.3.6.1.4.1.311.20.2 - Certificate Template Name (Certificate Type)

  • 1.3.6.1.4.1.311.21.7 - Certificate Template Information

  • 1.3.6.1.4.1.311.21.10 - Application Policies

  • 1.3.6.1.4.1.311.21.11 - Application Policy Mappings

  • 1.3.6.1.4.1.311.21.12 - Application Policy Constraints

  • 2.5.29.17 - Subject Alternative Name

  • 2.5.29.30 - Name Constraints

  • 2.5.29.32 - Certificate Policies

  • 2.5.29.33 - Policy Mappings

  • 2.5.29.36 - Policy Constraints

  • 2.5.29.37 - Enhanced Key Usage

<77> Section 3.2.1.4.2.1.4.4: A Windows CA stores these additional values in the Request table.

<78> Section 3.2.1.4.2.1.4.5: If the disposition was Error (30), the disposition messages include the following:

  • Error archiving private key.

  • Error parsing request.

  • Error verifying request signature or signing certificate.

  • Resubmitted by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was submitted by using the ResubmitRequest method of [MS-CSRA].

If the disposition was Denied (31), the disposition messages include the following:

  • Denied by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was submitted by using the DenyRequest method of [MS-CSRA].

  • Denied by policy module.

  • Denied by policy module, combined with a descriptive error message such as "Renewing a certificate with the 'xyz' Certificate Template failed because the renewal overlap period is longer than the certificate validity period."

  • Requested by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was formerly in a pending state and was issued by using the ResubmitRequest method of [MS-CSRA].

If the disposition was Issued (20), the disposition messages include the following:

  • Requested by {domain\name} where {domain\name} is replaced with the user name of the caller.

  • Issued.

  • Issued, combined with a descriptive informational message from the policy algorithm.

  • Resubmitted by {domain\name}, where {domain\name} is replaced with the user name of the caller if the request was formerly in a pending state and was issued by using the ResubmitRequest method of [MS-CSRA].

If the disposition was Pending (9), the disposition messages include the following:

  • Taken under submission.

  • Taken under submission, combined with an informational message from the policy algorithm.

  • The disposition message will contain text in the system language of the server.

<79> Section 3.2.1.4.2.1.4.6: All applicable Windows Server releases support this behavior, with exception of Windows 2000.

<80> Section 3.2.1.4.2.1.4.6: All applicable Windows Server releases support this behavior, with exception of Windows 2000.

<81> Section 3.2.1.4.2.2: Windows 2000 does not return an error.

<82> Section 3.2.1.4.2.2: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTREQUEST (section 3.2.1.1.4) setting.

<83> Section 3.2.1.4.2.2.2: Applicable Windows Server releases implement this property, with exception of Windows 2000.

<84> Section 3.2.1.4.2.3: Windows 2000 does not return an error.

<85> Section 3.2.1.4.2.3: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTREQUEST (section 3.2.1.1.4) setting.

<86> Section 3.2.1.4.3.1.2: Windows 2000, Windows Server 2003, and Windows Server 2008 CAs will set this value to 0 in this case.

<87> Section 3.2.1.4.3.2: Windows 2000 does not return an error.

<88> Section 3.2.1.4.3.2: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTREQUEST (section 3.2.1.1.4) setting.

<89> Section 3.2.1.4.3.2.1: The format of the string is "w.x:y.z" in all applicable Windows Server releases, with the exception of Windows Server 2016, Windows Server operating system, and Windows Server 2019 and later.

<90> Section 3.2.1.4.3.2.1: This string is based on the file version attribute of the certsrv.exe file. For example, in Windows Server 2003, the string is "5.2:3790.0" and in Windows Server 2003 operating system with Service Pack 1 (SP1), the string is "5.2:3790.1830". The string might change to represent servicing changes to the CA binaries.

<91> Section 3.2.1.4.3.2.2: The format of the string is "w.x:y.z" in all applicable Windows Server releases, with the exception of Windows Server 2016, Windows Server operating system, and Windows Server 2019 and later.

<92> Section 3.2.1.4.3.2.2: This string is based on the product version attribute of the certsrv.exe file. For example, in Windows Server 2003, the string is "5.2:3790.0" and in Windows Server 2003 with SP1, the string is "5.2:3790.1830". The string might change to represent servicing changes to the server product.

<93> Section 3.2.1.4.3.2.3: By default, the Microsoft CA returns the value 1 for this CA property.

<94> Section 3.2.1.4.3.2.4: By default, if the requested index is 0, a Microsoft CA returns the value "Windows default".

<95> Section 3.2.1.4.3.2.5: By default, a Windows CA returns the value "Windows default".

<96> Section 3.2.1.4.3.2.8: In Windows 2000 Server and Windows Server 2003 CAs, the Shared Folder feature is disabled and can be enabled through the CA setup wizard. If the feature is enabled, the folder contains a file named "certsrv.txt".

In Windows Server 2008 and later, the Shared Folder feature is also disabled, but it cannot be enabled through the CA setup wizard. If Windows Server 2003 CA has the shared folder enabled and is upgraded to the Windows Server 2008 CA, the folder remains shared.

The "Certsrv.txt" file provides limited ability to publish information about CAs. With the introduction of Active Directory in Windows 2000 Server, the benefit of storing CA information in a shared folder was minimized and use of the technique became rare.

The "Certsrv.txt" file contains one or more lines of text that identifies the location of CAs. Each line has the following form.

Note Line breaks have been added to improve readability. They do not exist in the file.

 CASanitizedCN,
   CASanitizedOU,
     CASanitizedO,
       CASanitizedL,
         CASanitizedS,
           CASanitizedC,
             CAFullDNSMachineName\CASanitizedCommonName,
               ExchangeCertName,
                 SignatureCertName,
                   Description
             

Each field in the preceding string is described in the following table. Optional fields that are not populated contain quotation marks (""). All but the first and seventh fields are optional.

Field

Description

CASanitizedCN

The sanitized CN from the CA certificate subject.

CASanitizedOU

Optional. The sanitized OU from the CA certificate subject.

CASanitizedO

Optional. The sanitized O from the CA certificate subject.

CASanitizedL

Optional. The sanitized L from the CA certificate subject.

CASanitizedS

Optional. The sanitized S from the CA certificate subject.

CASanitizedC

Optional. The sanitized C from the CA certificate subject.

CAFullDNSMachineName\

CASanitizedCommonName

A configuration string that contains the CA Domain Name System (DNS) name and the sanitized common name.

ExchangeCertName

Optional. The file name of the CA exchange certificate. This field is never used and the value is empty.

SignatureCertName

Optional. The file name of the CA signing certificate. For the first CA signing certificate only, this is stored in the %windir%\System32\CertSrv\CertEnroll directory.

Description

Optional. This is the CA description. If specified, this is the sanitized CN from the CA certificate subject.

For more information about sanitized names, see section 1.3.2.5.

The shared folder can also contain the additional files specified as follows:

  • CA signing certificates: The certificate files are encoded by using DER, and the naming convention is "CAComputerDNSName_CASanitizedName(CertIndex).crt". Because the CertIndex value is based on CA certificate renewal, no index value is present for the first certificate.

  • Certificate request files: Subordinate CAs copy the certificate request file to this folder. This file contains data on the certificate that the subordinate CA requests from its parent CA. The file is encoded by using DER, and the naming convention is "CAComputerDNSName_CASanitizedName(CertIndex).req". Because the CertIndex value is based on CA certificate renewal, no index value is present for the first certificate.

    Note No Windows-based clients depend on these certificates being stored in the shared folder.

<97> Section 3.2.1.4.3.2.16: In some cases, the CA signing certificate with "certificate index" zero could be returned instead of the actual signing certificate that issued Current_CA_Exchange_Cert.This behavior can be automatically fixed by restarting the certificate service whenever a new exchange certificate is created.

<98> Section 3.2.1.4.3.2.21: Windows Server 2003 returns the value 40. Windows Server 2008 returns the value 43, Windows Server 2008 R2 returns the value 44, and Windows Server 2012 and later return the value 45.

<99> Section 3.2.1.4.3.2.23: Microsoft Windows 2000, Windows Server 2003, and Windows Server 2008 CAs do not implement CR_PROP_ROLESEPARATIONENABLED property and always return E_INVALIDARG (0x80070057).

<100> Section 3.2.1.4.3.2.24: For more information on the Windows implementation for KRAs and key archival, see [MSFT-ARCHIVE].

<101> Section 3.2.1.4.3.2.33: In some cases, the CA signing certificate with "certificate index" zero could be returned instead of the actual signing certificate that issued Current_CA_Exchange_Cert. This behavior can be automatically fixed by restarting the certificate service whenever a new exchange certificate is created.

<102> Section 3.2.1.4.3.2.41: Windows 2000 and Windows Server 2003 CAs do not implement this property and always return 0x80070057 (E_INVALIDARG).

<103> Section 3.2.1.4.3.2.42: Windows 2000 and Windows Server 2003 CAs do not implement this property and always return 0x80070057 (E_INVALIDARG).

<104> Section 3.2.1.4.3.2.43: Windows 2000 and Windows Server 2003 CAs do not implement this property and always return 0x80070057 (E_INVALIDARG).

<105> Section 3.2.1.4.3.2.44: This property is supported by Windows Server 2008 R2 and later.

<106> Section 3.2.1.4.3.2.45: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows 8 and later clients.

<107> Section 3.2.1.4.3.3: In Windows Server 2003 and later the error is E_ACCESSDENIED (0x80000009). Windows 2000 does not return an error.

<108> Section 3.2.1.4.3.3: The operating systems specified in [MSFT-CVE-2022-37976], each with their related KB article download installed, require that clients MUST connect with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level or the connection to the CA server will be denied, regardless of the IF_ENFORCEENCRYPTICERTREQUEST (section 3.2.1.1.4) setting.

<109> Section 3.2.2.1.2.1: Windows 2000 operating system Service Pack 1 (SP1) and Windows 2000 operating system Service Pack 2 (SP2) set the timeLimit to 300.

<110> Section 3.2.2.1.3.1: Windows 2000 does not support this feature.

<111> Section 3.2.2.3: In Windows 2000, the maximum size of Collection_Of_End_Entity_Object_Query_AD_Connections is always one.

<112> Section 3.2.2.5: Windows 2000 Server only supports templates that do not have msPKI-Template-Schema-Version, or that have msPKI-Template-Schema-Version set to 0x1. Windows Server 2003 only supports templates that do not have msPKI-Template-Schema-Version, or that have msPKI-Template-Schema-Version set to 0x1 or 0x2. Windows Server 2008 and Windows Server 2008 R2 CAs only support templates that do not have msPKI-Template-Schema-Version or that have msPKI-Template-Schema-Version set to 0x1, 0x2, or 0x3.

<113> Section 3.2.2.6.2.1.2.1: Windows Server 2008 and later CAs implement this data.

<114> Section 3.2.2.6.2.1.2.2: Windows 2000 and Windows Server 2003 CAs only attempt to calculate the SHA1 hash.

<115> Section 3.2.2.6.2.1.2.4: These types of requests are supported by Windows Server 2008 R2 and later.

<116> Section 3.2.2.6.2.1.2.5: Windows 8.1 and later and Windows Server 2012 R2 and later support key attestation.

<117> Section 3.2.2.6.2.1.2.5: In the Windows implementation, the value of this string is "Microsoft Platform Crypto Provider".

<118> Section 3.2.2.6.2.1.4.4.1: Windows Server 2008 R2 and later support this flag.

<119> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008 and later support this flag.

<120> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008 R2 and later support this flag.

<121> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008 R2 and later support this flag.

<122> Section 3.2.2.6.2.1.4.5.6: Windows Server 2012 and later support this flag.

<123> Section 3.2.2.6.2.1.4.5.6: Windows Server 2012 and later support this flag.

<124> Section 3.2.2.6.2.1.4.5.7: Flag CT_FLAG_REQUIRE_SAME_KEY_RENEWAL is supported by Windows Server 2012 and later.

<125> Section 3.2.2.6.2.1.4.5.7: This flag is supported by Windows Server 2012 and later.

<126> Section 3.2.2.6.2.1.4.5.7: These flags are supported only in Windows Server 2012 R2 and later.

<127> Section 3.2.2.6.2.1.4.5.7: Windows Server 2012 and later implement the Server_Current_Version ADM element.

<128> Section 3.2.2.6.2.1.4.5.8: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows Server 2012 and later.

<129> Section 3.2.2.6.2.1.4.5.8: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows Server 2012 and later.

<130> Section 3.2.2.6.2.1.4.5.9: Windows Server 2008 and later support the CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS flag.

<131> Section 3.2.2.6.3.1.1: The format of the returned value depends on the Active Directory schema.

For a DC running with a Windows Server 2003 Active Directory schema, a Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 Active Directory Domain Services (AD DS) schema, or Windows Server 2016 Active Directory Domain Services (AD DS) schema, or Windows Server operating system Active Directory Domain Services (AD DS) schema, or a Windows Server 2019 and later Active Directory Domain Services (AD DS) schema:

If the DC is running with a Windows Server 2003 Active Directory schema and at least one Windows Server 2003, Enterprise Edition CA has been installed in the forest, the string returned in the pctbPropertyValue parameter contains the name (cn attribute of the certificate template) and OID (msPKI-Cert-Template-OID) attribute of the certificate template of each configured certificate template and has the following format:

TemplateName1\nTemplateOID1\nTemplateName2\nTemplateOID2\...

Note All certificate templates are represented with their OID and name regardless of the certificate template version.

For a DC running with a Windows 2000 Server Active Directory schema:

If the DC is running with a Windows 2000 Server Active Directory schema or if no Windows Server 2003, Enterprise Edition CA has been installed in the forest, the string returned in the pctbPropertyValue parameter contains the names (cn attribute of the certificate template) of the configured certificate template and has the following format:

TemplateName1\n\nTemplateName2\n\nTemplateName3\n\...