Partager via

3.1.3 Initialization

  • Article

Interface Initialization: On startup, the CA MUST ensure that remote clients have permissions to activate and call DCOM objects on the CA. Subsequently, DCOM object and interface initialization is performed by the DCOM object exporter in response to an activation request from the DCOM client. The Certificate Services Remote Administration Protocol client calls the DCOM client to initiate the activation request to the server. As a result, the DCOM server returns an object reference to the DCOM client, and the Certificate Services Remote Administration Protocol client can use this client object reference to make calls to the Certificate Services Remote Administration Protocol server methods specified in this document. The details of DCOM object initialization on the server, in response to client activation requests and ORPC calls, are specified in [MS-DCOM] sections 3.1.1.3, 3.1.1.5.1, and 3.1.1.5.4.<14>

Cryptographic Initialization: The CA MUST validate each of the CA signing certificate(s) represented by the Signing_Cert_Certificate column in the Signing_Cert Table (section 3.1.1.11). The certificates are validated in the order in which they occur in the Signing_Cert Table from first to last, with the latest Signing_Cert entry evaluated last.

The certificate path validation MUST be performed in accordance with the algorithm specified in [RFC3280] section 6.1. To invoke this algorithm, the CA MUST use the following inputs as defined in [RFC3280] section 6.1.1.

  • Prospective certification path: This is the path from the CA signing certificate (Signing_Cert_Certificate column from the Signing_Cert Table) to a root certificate. The path is passed in to the algorithm. Certificates needed to build this path SHOULD be obtained either from the location specified in the Authority Information Access extension (as specified in [RFC3280] section 4.2.2.1) in the signing certificate, or from local storage, if certificates have previously been cached as described in [RFC3280] section 3.1.

    • For every certificate in the path starting with the signing certificate, its issuer certificate is determined either by matching its Authority Key Identifier (as specified in [RFC3280] section 4.2.1.1) with the Subject Key Identifier (as specified in [RFC3280] section 4.2.1.2) of the issuer certificate, or by matching its issuer field (as specified in [RFC3280] section 4.1.2.4) with the subject field (as specified in [RFC3280] section 4.1.2.6) of the issuer certificate.

  • Current date and time: This is the current system date and time.

  • User-initial-policy set: The user-initial-policy-set contains the value any-policy.

  • Trust Anchors: The set of root certificates that are passed in to the algorithm from implementation-specific local storage.

  • Initial-policy-mapping-inhibit: This input parameter is not set.

  • Initial-explicit-policy: This input parameter is not set.

  • Initial-any-policy-inhibit: This input parameter is not set.

Based on the above inputs, the algorithm is followed as specified in the other subsections of section 6.1 of [RFC3280]. The Microsoft CA does not check for optional certificate extensions such as the policy mapping extension, which is consistent with the standard specified in section 6.1 of [RFC3280].

If none of the CA signing certificates in the Signing_Cert table passes Certificate Path Validation (see [RFC3280] section 6) based on any of the trust anchors, the CA MUST NOT start processing messages. For example:

  • If there are six certificates and only one passes, the CA starts.

  • If there are six certificates and five pass, the CA starts.

  • If there are six certificates and none of them passes, the CA MUST NOT start processing messages.

Database Initialization: The CA MUST ensure that the database is available for use and that the tables and fields that are defined in section 3.1.1 exist. If the database is not available, the CA MUST NOT start processing messages.

Configuration Initialization: The CA MUST initialize the configuration data elements defined in section 3.1.1.10. Each element defined in section 3.1.1.10 as "OnNextRestart_{Config_Element_Name}" will be used to initialize the corresponding data element "{Config_Element_Name}" upon CA startup. <15>

If the CA fails to complete any of the initialization steps, the CA MUST NOT start.