How to verify hostname of certificate? and Is it mandatory if client knows the certificate?
I have a reported finding saying that hostname verification is disabled. This can be deduced from this line of code:
final HttpClientBuilder httpClientBuilder = HttpClientBuilder.create();
httpClientBuilder.setSSLContext(sslContext).setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE);
If I want to check the hostname of can I do this? are there several ways to do that? and is that affected by the format of certificate used (ex: x509, PEM, etc ..)
Furthermore I was reading RFC of SSL (https://www.rfc-editor.org/rfc/rfc6125.html) the Server Identity section:
3.1. Server Identity
In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.Matching is performed using the matching rules specified by
[PKIX-OLD]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI
was obtained by clicking on an HTML page which was itself obtained
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it
meets their expectations.
It says that If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. So if in my case the client knows the certificate, can I just ignore this finding, and keep the hostname verification disabled ?
