Quando você usa a autenticação de certificado de cliente, no final do handshake, o cliente envia um % co_de Mensagem% TLS onde assina com sua chave privada a concatenação de todas as mensagens TLS que foram trocadas entre o cliente e o servidor: algo comumente conhecido por ambos.
Isso independe do fato de o certificado do cliente ser confiável ou não. O servidor ainda verifica a assinatura em relação à chave pública apresentada no certificado do cliente. Se falhou, o handshake falharia.
No final do handshake, se o servidor confia ou não no que o certificado afirma, ou seja, na ligação entre a chave pública, o identificador e vários outros atributos, saberá pelo menos que o cliente tem a chave privada. para a chave pública neste certificado (o resto pode ou não ser verdade).
Se você tiver uma lista predefinida de chaves públicas conhecidas (como chaves públicas configuradas para uma conexão SSH, por exemplo), poderá executar a autenticação dessa maneira. O que você sente falta é a PKI: toda a infraestrutura para ajudá-lo a gerenciar as chaves e a quem elas pertencem. Como a maioria das definições de configuração é destinada para uso em uma PKI, isso também pode exigir mais trabalho (incluindo programação adicional).
Todas as outras propriedades da conexão TLS estão intactas: a criptografia ainda é garantida da mesma forma que no contexto de uma PKI. Não tenho certeza do que o @WesleyDavid está falando em sua resposta sobre este assunto. De qualquer forma, trata-se de certificados de clientes, para que a criptografia entre o cliente e o servidor ocorra de qualquer forma, seja ou não apresentado um certificado de cliente (desde que seja usado um conjunto de criptografia com criptografia não nula, é claro).