Logstash version (e.g. bin/logstash --version): 8.8
Description of the problem including expected versus actual behavior:
Before the SSL standardization, when this plugin was initialized with the now-deprecated ssl_certificate_verification => true, it provided no:verify ssl option to manticore, resulting in Manticore using DefaultHostnameVerifier.
With the SSL standardization in #1118 ssl_certificate_verification => true results in manticore getting :verify => :strict, which causes it to use a StrictHostnameVerifier.
The StrictHostnameVerifier in the Apache Client lib is deprecated with guidance to use DefaultHostNameVerifier (which is the modern rfc2818-aware implementation):
/**
* The Strict HostnameVerifier works the same way as Sun Java 1.4, Sun
[...]
*
* @deprecated (4.4) Use {@link org.apache.http.conn.ssl.DefaultHostnameVerifier}
*/
@Contract(threading = ThreadingBehavior.IMMUTABLE)
@Deprecated
public class StrictHostnameVerifier extends AbstractVerifier {
Logstash information:
Please include the following information:
bin/logstash --version
): 8.8Description of the problem including expected versus actual behavior:
Before the SSL standardization, when this plugin was initialized with the now-deprecated
ssl_certificate_verification => true
, it provided no:verify
ssl option to manticore, resulting in Manticore usingDefaultHostnameVerifier
.With the SSL standardization in #1118
ssl_certificate_verification => true
results in manticore getting:verify => :strict
, which causes it to use aStrictHostnameVerifier
.The
StrictHostnameVerifier
in the Apache Client lib is deprecated with guidance to useDefaultHostNameVerifier
(which is the modern rfc2818-aware implementation):Relevant portion of the diff is here.