Why host authentication has to check who the certificate belongs to
When using host SSL certificate to authenticate a host's identity, you can't just check that your CA signed the host's certificate; you also have to check that the certificate belongs to the host (usually by checking that the certificate's CN is the hostname, or IP address, or etc). The reason you need to make this additional check of the certificate is that without it, you don't know if the certificate actually came from the host you're trying to authenticate.
Imagine that you have two client machines, A and B. A and B can talk to each other's SSL host authentication service (why not, after all). An attacker wants to impersonate B. If you do not check what host the certificate belongs to, the attack goes like this:
The attacker waits until the real B is down. They configure their impostor machine to have B's IP address, and sets it up to NAT-forward incoming connections on the SSL authentication service's port off to A. Then they make a request that starts an authentication attempt. Your server calls the fake B up to get its SSL certificate; B forwards the request off to A, and passes A's packets back. As far as the server sees, it is talking to B and B is presenting a valid, CA-signed certificate, so the authentication succeeds.
It follows as a corollary that you can't issue generic CA-signed certificates for host authentication; you must issue host-locked ones.
(You can use some additional verification on top of SSL like the host echoing back its hostname to the server, but this is equivalent to checking that the SSL certificate actually belongs to the host.)
I suspect that this is well-known to crypto people, but I didn't realize it until recently. (One moral I draw from this is that designing security protocols is hard and I should do as little of it as possible, just in case.)