Your principles are correct, but the particulars can be a devil to set right.
Indeed, the general schema is that:
The client needs to validate the certificate from the server, i.e. verify that the certificate has been issued (signed) by a trusted CA, and that the alleged server certificate contains the name of the server.
Similarly, the server needs to validate the certificate from the client, i.e. verify that the certificate has been issued (signed) by a trusted CA, and then obtain the "client name" from the certificate.
So both client and server need to trust some root CA certificate -- not necessarily the same (but it does not hurt that they both trust the same). Moreover, both client and server can be a bit picky about what they find in their own certificate, and in the certificate from the peer. The server certificate will have to contain the server name as prescribed by RFC 2818 (section 3.1). If you include the
Extended Key Usage extension, then IIS and Internet Explorer will tend to require the "server authentication" key usage (188.8.131.52.184.108.40.206.1). For the client certificate, IE and IIS will again want to see a specific key usage, namely "client authentication" (220.127.116.11.18.104.22.168.2).
The server (IIS) must also make something out of what it finds in the client certificate. There are several methods. "Account mapping" is about associating the client certificate with a client account, accounts being the notion of identity which prevails within a Windows operating system. If an Active Directory domain is in force, the mapping can be direct (the certificate is mapped to the account which, on the AD server, contains a copy of the certificate) or indirect (the certificate contains a copy of the User Principal Name of the account, in its
Subject Alt Name extension). Non-mapped authentication is possible, too, in which case the application is responsible for making sense of the certificate.
Certificate revocation can be a problem, too. Conceptually, a CA who has issued a certificate can "express remorse", and announce to the World at large that a given certificate, though seemingly all signed and signed and valid, must nonetheless be rejected. This supports emergency situations such as a stolen private key. This announcement uses a Certificate Revocation List, a short-lived object signed by the CA. Both the server and the client may want to obtain a fresh CRL which covers the certificate they are trying to validate. Your homemade PKI does not publish CRL regularly, so if the client or the server gets into its head to verify revocation status, things will fail.
Whether IIS and/or IE will engage into revocation check depends on what they find in the certificates, but that's not documented with the utmost clarity. IIS can be configured to disregard revocation checks. For Internet Explorer, this can also be done, apparently on a zone basis (IE categorizes servers in "zones", such as "local intranet" or "Internet", and can apply different security settings for each zone, one of which being "enforce revocation status check").
This blog post seems to cover your situation. I suggest you follow its indications. Don't fiddle with revocation unless you get some error messages stating that some revocation status check could not be obtained, in which case you may have to build a CRL and push it on both client and server (with
mmc.exe), or deactivate revocation checks (as indicated above).