7 Appendix B: Product Behavior

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

  • Windows 2000 Server operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support key attestation.

<2> 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.221) 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.

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

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

<5> Section 2.1: All Windows clients set the authentication level to RPC_C_AUTHN_LEVEL_PKT_PRIVACY. On the server side, if IF_ENFORCEENCRYPTICERTREQUEST or IF_ENFORCEENCRYPTICERTADMIN are set (see section 3.2.1.1.4) and the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level is not specified from the client, the CA refuses to establish a connection with the client by returning a nonzero error. By default, however, Windows CAs do not require the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level. That is, neither IF_ENFORCEENCRYPTICERTREQUEST nor IF_ENFORCEENCRYPTICERTADMIN are set.

<6> Section 2.2.2.5: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support key attestation.

<7> Section 2.2.2.5:  Support for [TCG-Struct-V2] was added in Windows 8.1 and Windows Server 2012 R2, and is available in subsequent product versions according to the applicability list at the beginning of this section.

<8> 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, Windows 7, Windows 8, Windows 8.1, and Windows 10 enrollment classes.

6

ClientIdAutoEnroll

The client application in the Windows autoenrollment service shipped with Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10.

7

ClientIdRequestWizard

The client application in the enrollment wizard shipped with Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10.

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.

<9> Section 2.2.2.7.9: In Windows versions except Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the hash algorithm used is always set to SHA1. In Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, 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.

<10> Section 2.2.2.7.10: The "ExpirationDate" value for the OID szENROLLMENT_NAME_VALUE_PAIR (1.3.6.1.4.1.311.13.2.1) is supported by Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

<11> 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 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.

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

<13> Section 2.2.2.7.15:  Support for szOID_ENROLL_AIK_INFO was added in Windows 10 and Windows Server 2016, and is available in subsequent product versions according to the applicability list at the beginning of this section.

<14> Section 2.2.3.1: A Windows–based server will use key recovery certificates that contain the following X.509v3 extensions specific to Windows:

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

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

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

  •  Certreq.exe tool (see [MSFT-ADVCERT] for more information)

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

<16> Section 3.1.1: A Windows-based client implements an abstraction layer on top of the interfaces specified in this document. Windows Server 2003, Windows 2000 operating system, Windows XP, and Windows NT operating system support the interfaces documented in [MSDN-XEnroll]. Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support the interfaces documented in [MSDN-CertEnroll].

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

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

<19> 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]).

<20> Section 3.1.1.4.3.2.1: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support processing rules in section 3.1.1.4.3.4.

<21> Section 3.1.1.4.3.2.2: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support processing rules in section 3.1.1.4.3.4.

<22> 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, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016; and during the web enrollment for Windows 2000, Windows Server 2003, and Windows XP.

<23> Section 3.1.1.4.3.4: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support key attestation.

<24> Section 3.1.1.4.3.4.1.2: Only Windows Server 2012 R2 and Windows Server 2016 supports this behavior.

<25> Section 3.1.1.4.3.4.1.2: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support these processing rules.

<26> Section 3.1.1.4.3.4.2:  Support for AIK Attestation (subject only) was added in Windows 10 and Windows Server 2016, and is available in subsequent product versions according to the applicability list at the beginning of this section.

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

<28> Section 3.1.1.6.2: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this behavior.

<29> 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).

<30> 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).

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

<32> Section 3.1.2.4.2.1: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this flag.

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

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

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

<36> 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, Windows Server 2003 R2 operating system, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 can use this certificate template.

  • When the value = 3: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 can use this certificate template.

  • When the value = 4: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 can use this certificate template.

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

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

<38> Section 3.1.2.4.2.2.1.8: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 create this extension only if the Certificate.Template.msPKI-Template-Schema-Version datum equals 1 or is not initialized with any value.

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

<40> Section 3.1.2.4.2.2.2.2: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support these flags.

<41> Section 3.1.2.4.2.2.2.2: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this behavior.

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

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

<44> Section 3.1.2.4.2.2.2.5: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this behavior.

<45> Section 3.1.2.4.2.2.2.5: Windows client defaults to Triple Data Encryption Standard.

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

<47> Section 3.1.2.4.2.2.2.5: Windows client defaults to SHA1.

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

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

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

<51> Section 3.1.2.4.2.2.2.7: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this flag.

<52> Section 3.1.2.4.2.2.2.8: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 ignore this flag.

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

<54> Section 3.1.2.4.2.2.2.8: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support this flag.

<55> Section 3.1.2.4.2.2.2.8: This flag is supported by Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

<56> Section 3.1.2.4.2.2.2.8: This flag is supported by Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

<57> Section 3.1.2.4.2.2.2.8: These flags are supported in Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

<58> Section 3.1.2.4.2.2.2.8: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 implement the Client_Current_Version ADM element.

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

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

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

<62> 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 do not implement key archival.

<63> 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 CAs are considered "standard server".

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

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

<66> 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, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

<67> 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, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

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

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

<70> 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

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

<72> Section 3.2.1.4.2.1.4.4: 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.

<73> Section 3.2.1.4.2.1.4.5: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this behavior.

<74> Section 3.2.1.4.2.1.4.5: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this behavior.

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

<76> Section 3.2.1.4.2.2.2: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 implement this property.

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

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

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

<80> Section 3.2.1.4.3.2.1: In Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, the format of the string is "w.x:y.z".

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

<82> Section 3.2.1.4.3.2.2: In Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, the format of the string is "w.x:y.z".

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

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

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

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

<87> 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, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016, 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.4.

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.

<88> 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, Windows Server 2012 returns the value 45, Windows Server 2012 R2 returns the value 45, and Windows Server 2016 returns the value 45.

<89> 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).

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

<91> 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).

<92> 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).

<93> 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).

<94> Section 3.2.1.4.3.2.44: This property is supported by Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

<95> Section 3.2.1.4.3.2.45: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows 8, Windows 8.1, and Windows 10.

<96> Section 3.2.1.4.3.3: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016, the error is E_ACCESSDENIED (0x80000009). Windows 2000 does not return an error.

<97> 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 timeLimit to 300.

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

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

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

<101> Section 3.2.2.6.2.1.2.1: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 CAs implement this data.

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

<103> Section 3.2.2.6.2.1.2.4: These types of requests are supported by Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

<104> Section 3.2.2.6.2.1.2.5: Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 support key attestation.

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

<106> Section 3.2.2.6.2.1.4.4.1: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<107> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<108> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<109> Section 3.2.2.6.2.1.4.5.6: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<110> Section 3.2.2.6.2.1.4.5.6: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<111> Section 3.2.2.6.2.1.4.5.6: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support this flag.

<112> Section 3.2.2.6.2.1.4.5.7: Flag CT_FLAG_REQUIRE_SAME_KEY_RENEWAL is supported by Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

<113> Section 3.2.2.6.2.1.4.5.7: This flag is supported by Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

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

<115> Section 3.2.2.6.2.1.4.5.7: Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 implement the Server_Current_Version ADM element.

<116> Section 3.2.2.6.2.1.4.5.8: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

<117> Section 3.2.2.6.2.1.4.5.8: The CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST flag is supported by Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

<118> Section 3.2.2.6.2.1.4.5.9: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 support the CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS flag.

<119> 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 or a Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 Active Directory Domain Services (AD DS) schema, or Windows Server 2016 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\...

Show: