Na maioria dos protocolos / aplicativos que usam SSL, o cliente precisa verificar BOTH (1) o servidor apresenta um certificado válido, significando um emitido por uma CA confiável e não expirado, revogado ou violado E (2) esse certificado é para o servidor você quer, não alguém a quem sua conexão foi roteada por engano ou por ataque deliberado. (Existem casos raros em que você não precisa apenas de confidencialidade na autenticação do servidor, mas provavelmente é melhor usar as ciphersuites "anon" ou "aNULL" que explicitamente não são autenticadas.)
O OpenSSL até à data faz (1) mas não (2) , e normalmente suporta apenas certificados de raiz CA no seu truststore; uma raiz da autoridade de certificação pode ser 'responsável' por milhares ou milhões de certificados de servidor e, se, por exemplo, a Verisign emitiu certificados para bigbank.com e localdiner.com , isso não significa que eu queira fornecer minhas contas bigbank ao localdiner. Portanto, o aplicativo precisa fazer (2), em verify_callback ou após o handshake ser concluído, mas antes de enviar dados (confidenciais). A próxima grande versão 1.0.2 está planejada para conter melhorias na validação da cadeia de certificados, e eu acredito também nomear validação em pelo menos alguns casos. Nota para HTTPS usando RFC 2818 ou outros protocolos baseados em TLS usando o RFC 6125, você precisa verificar ambos CommonName no Subject e a extensão SubjectAlternativeNames, se houver.
Eu não sei porque o OpenSSL (e antes disso SSLeay) não o faz . Pode-se dizer que alguns aplicativos SSL / TLS incomuns querem algo diferente do padrão CN / SAN - mas há outras áreas em que o OpenSSL manipula o caso comum e fornece retornos de chamada ou opções para os casos raros. Eu acho que provavelmente foi muito trabalho e poucas pessoas (até bem recentemente).