In presence of 'trust certificates' & other attributes .. how important is this?Does OpenSSL implement it now & If not why does OpenSSL not implement?
Is validation of CN/Hostname verification against SSL certificate required in openssl & why?
security;openssl
In most protocols/applications using SSL the client needs to check BOTH (1) the server presents a valid certificate, meaning one issued by a trusted CA and not expired, revoked or tampered AND (2) that certificate is for the server you want, not somebody else to whom your connection was routed by mistake or by deliberate attack. (There are rare cases where you don't need server authentication only confidentiality, but then you are probably better off using the anon or aNULL ciphersuites which explicitly do not authenticate.) OpenSSL to date does (1) but not (2), and normally supports only CA root certs in its truststore; one CA root might be 'responsible' for thousands or millions of server certs, and if for example Verisign issued certs to both bigbank.com and localdiner.com that doesn't mean I want to give my bigbank accounts to localdiner. So the application needs to do (2), either in a verify_callback, or after the handshake completes but before sending (sensitive) data. The next major release 1.0.2 is planned to contain enhancements to cert chain validation, and I believe also name validation in at least some cases. Note for HTTPS using RFC 2818 or other TLS-based protocols using RFC 6125, you need to check both CommonName in Subject and the SubjectAlternativeNames extension if present.I don't know why OpenSSL (and before that SSLeay) doesn't do it already. One might say that some unusual SSL/TLS applications want something other than the standard CN/SAN -- but there are other areas where OpenSSL handles the common case and provides callbacks or options for the rare cases. I think it was probably just too much work and not enough people (until very recently).