4.1 Typical Success Scenario

A common scenario is that the client's table of peer certificates contains a certificate for the server, but the server's table no longer contains the client's certificate. If the client attempts a discovery request via content retrieval, the following exchange of messages occurs. (For more information about content retrieval messages, see [MS-BPCR].)

Assume the client computer has a fully qualified domain name (FQDN) of "client.corp.contoso.com", and its account in Active Directory has a SID of S-1-5-21-10-10-10-44. The server computer has a fully qualified domain name (FQDN) of "server.corp.contoso.com", and its domain account has a SID of S-1-5-21-10-10-10-33.

The client's content retrieval layer first opens a TLS connection to the server's content retrieval port, defined in [MS-BPCR] section 1.9. Client and server exchange certificates during TLS connection setup. The client's certificate contains the same string in its subject and issuer fields: "S-1-5-21-10-10-10-44". Similarly, the server's certificate contains "S-1-5-21-10-10-10-33".

The server's content retrieval layer examines the client certificate, discovers it is not in the table of peer certificates, and returns a status of "CertificateNotFound" as defined in [MS-BPCR] section 2.2.1.3.

The client's peer authentication layer creates an RPC binding handle to the server, specifying the Kerberos security provider and enabling mutual authentication. The expected server principal name is "server$.corp.contoso.com".

The client calls the ExchangePublicKeys method in the BitsPeerAuth RPC interface, passing its certificate in ClientKey. The client's Kerberos layer verifies that the server process is executing with the correct identity.

The server's ExchangePublicKeys routine decodes the client certificate. The server's Kerberos layer identifies the RPC client as "S-1-5-21-10-10-10-44"; the server compares the certificate subject to this SID and finds that they match. The server checks the size of its table of peer certificates; the table has only a few entries and so the server adds the certificate to the table without discarding any other rows. The server then encodes its own certificate and returns it in pServerKey.

The client decodes the server certificate. It compares the certificate subject ("S-1-5-21-10-10-10-33") to the SID of the server's Kerberos identity, and finds that they match. The client checks the size of its table of peer certificates; the table has only a few entries and so the client adds the certificate to the table without discarding any other rows.

The client retries the content retrieval request; it succeeds this time because the server finds the client certificate in its table of peer certificates.