3.2.5.2 Message Validation
The server MUST request that the client provide a certificate as detailed in [RFC2246] section 7.3. In this TLS negotiation, the server provides the "Local Certificate" exposed by [MS-BPAU] section 3.1.1.1. The server MUST verify that the client certificate has the following characteristics:
It was provided by the client.
It is within its period of validity.
It contains the id-kp-clientAuth extended key usage (EKU), specified in [RFC3280] section 4.2.1.13.
The issuer and subject names are in the form of a security identifier (SID) representing a machine account in the recipient host's Active Directory domain.
If any verification test fails, the server MUST reject the request as detailed in [RFC2246] section 7.3.
The server MUST validate the following aspects of a received message before determining the message type:
The HTTP version MUST be 1.1.
The HTTP verb must be one of the values in the first column of the table that follows.
If the HTTP version check fails, the server MUST reply with an HTTP error response, as specified in section 3.2.5.1, using an HTTP status code of 505.
|
HTTP verb |
Message type |
|---|---|
|
POST |
|
|
GET |
|
|
HEAD |
Once the initial validation has succeeded, the server uses the HTTP verb to determine the message type, and processes the message as appropriate. For specific actions for each message type, see the following sections.
The server MAY impose limits on the number of messages processed simultaneously.<21> If an incoming message surpasses the server limits, the server SHOULD reply with an HTTP error response, as specified in section 2.2, using an HTTP status code of 503.