I believe the intent of the parent poster was actually correct. SSL client certificates [1] are a way to securely authenticate (i.e. login) by using a certificate which you control the key to in addition to the normal SSL certificate for the website.
An over-simplified example: if Alice (A), a client with web browser on a compromised computer, wants to access the BigCorp website (B) she sends a challenge, such as a random string, to B, and B sends back the challenge encrypted with the BigCorp SSL certificate. Alice's browser verifies that the signature corresponds to a valid certificate, which it does because BigCorp's certificate is legitimate and signed by a legitimate CA, and then Alice's web browser and the web server negotiate a session key to use for SSL.
If we introduce an attacker, Eve (E), to this, who has the key to a trusted certificate on Alice's machine, Eve can intercept Alice's original challenge and send back an answer to that using the trusted certificate, which Alice thinks is genuine because the certificate is valid in her browser. This is where certificate pinning helps, since if Alice has visited the site before, the certificate does not match and she gets an error. After the negotiation, Eve then has a session key to both A and B, and any data that A sends, Eve decrypts and re-encrypts with the session key for B, passing it seamlessly onto B, and vice versa for traffic going the other way.
SSL client certificates break for a MITM attack for a different reason. When Alice is using an SSL client certificate to authenticate herself, she has her own certificate on her machine which she knows the private key to (it can even be self-signed). The web server knows Alice's public key (stored like a password hash in a database), and can therefore perform a similar challenge for Alice. When Eve intercepts this challenge, she cannot send a valid response back to the server, as the only valid key for Alice's account is stored on Alice's computer. Therefore, sites that let you sign in with an SSL client certificate often just stop working when you are being MITM'd.
An over-simplified example: if Alice (A), a client with web browser on a compromised computer, wants to access the BigCorp website (B) she sends a challenge, such as a random string, to B, and B sends back the challenge encrypted with the BigCorp SSL certificate. Alice's browser verifies that the signature corresponds to a valid certificate, which it does because BigCorp's certificate is legitimate and signed by a legitimate CA, and then Alice's web browser and the web server negotiate a session key to use for SSL.
If we introduce an attacker, Eve (E), to this, who has the key to a trusted certificate on Alice's machine, Eve can intercept Alice's original challenge and send back an answer to that using the trusted certificate, which Alice thinks is genuine because the certificate is valid in her browser. This is where certificate pinning helps, since if Alice has visited the site before, the certificate does not match and she gets an error. After the negotiation, Eve then has a session key to both A and B, and any data that A sends, Eve decrypts and re-encrypts with the session key for B, passing it seamlessly onto B, and vice versa for traffic going the other way.
SSL client certificates break for a MITM attack for a different reason. When Alice is using an SSL client certificate to authenticate herself, she has her own certificate on her machine which she knows the private key to (it can even be self-signed). The web server knows Alice's public key (stored like a password hash in a database), and can therefore perform a similar challenge for Alice. When Eve intercepts this challenge, she cannot send a valid response back to the server, as the only valid key for Alice's account is stored on Alice's computer. Therefore, sites that let you sign in with an SSL client certificate often just stop working when you are being MITM'd.
[1] http://www.symantec.com/connect/blogs/client-certificates-vs...