HostnameVerifier vs TrustManager?

Question

Under what circumstances would one use a HostnameVerifier over a TrustManager in Java? Is one recommended over the other? Looking at the Java docs (Interface HostnameVerifier and Interface TrustManager), I can't tell when its best to use either (though the TrustManager seems more versatile).

In the past, I have always used a custom TrustManager. However, I noticed Heartbleed exploit in java uses both (but I don't think its correct).

EDIT: when using HostnameVerifier, are the other customary X509 checks performed, like path building and expiration and revocation (if configured)? I think I am essentially asking if HostnameVerifier supplements the other checks (rather than replacing them).

For example, suppose a dev server is at dev.example.com and its signed by an internal CA. There's one DNS name in dev.example.com's certificate, and its dev.example.com. Further, suppose I connect to it as 192.168.1.10. Could I use a HostnameVerifier to allow both dev.example.com and 192.168.1.10? In this scenario, is the additional name allowed and are the other customary X509 checks are performed?

Answer 1

Under what circumstances would one use a HostnameVerifier over a TrustManager in Java?

Never. They do different things. TrustManage authenticates certificates as part of SSL. HostnameVerifier verifies host names as part of HTTPS. They're not in competition.

Is one recommended over the other?

No.

EDIT

• The TrustManager runs during the TLS handshake. If it indicates failure, the handshake is aborted and the connect fails.
• The HostnameVerifier runs after the TLS handshake, over a TLS connection that is already valid from the TLS point of view, so at that point you know that the certificate is valid, signed by a trusted issuer, non-expired (?), etc., and all you have to do is decide (a) whether it's from the correct server and (b) whether you trust that server. You might do (b) inside a TrustManager, but far more commonly you wouldn't provide your own TrustManager at all.