Enabling the "Trust all certificates" option does not have the expected behaviour for some forms of SSL failure, specifically a hostname mismatch.

For example for a domain with the following settings:

• Domain name: ad.company.com
• Domain controller: dc.ad.company.com:3268 (with a self-signed certificate)
• Bind DN: user@ad.company.com
• Bind Password: whatever
• TLS Configuration: Trust all certificates
• StartTLS: checked

This results in StartTLS succeeding even though the certificate is self-signed and not trusted:

Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Connecting to ldap://dc.ad.company.com:3268/
Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Connection upgraded to TLS
Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Binding as user@ad.company.com to ldap://dc.ad.company.com:3268/
Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Bound to dc.ad.company.com:3268

However if the domain controller entry is changed to be the IP address of dc.ad.company.com (or any other alternate IP/hostname for that server which does not appear in the TLS certificate) then this still causes an SSL exception even though "Trust all certificates" is selected

Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Connecting to ldap://10.0.0.2:3268/
Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
Failed to start TLS. Authentication will be done via plain-text LDAP
java.security.cert.CertificateException: No subject alternative names matching IP address 10.0.0.2 found at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168) at sun.security.util.HostnameChecker.match(HostnameChecker.java:94) at com.sun.jndi.ldap.ext.StartTlsResponseImpl.verify(StartTlsResponseImpl.java:426)
Caused: javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '10.0.0.2' does not match the hostname in the server's certificate. at com.sun.jndi.ldap.ext.StartTlsResponseImpl.verify(StartTlsResponseImpl.java:447) at com.sun.jndi.ldap.ext.StartTlsResponseImpl.negotiate(StartTlsResponseImpl.java:225) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:684) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:599) at hudson.plugins.active_directory.ActiveDirectoryDomain$DescriptorImpl.doValidateTest(ActiveDirectoryDomain.java:336) 

Expected result:

Since "Trust all certificates" is enabled, Jenkins should not care that the Subject/SAN/IP don't match - since it does receive a usable certificate, it should use it and encrypt the traffic anyway. Alternatively, if this is not possible for some reason, then the "Test Domain" button should show some kind of warning to indicate that even though you have STARTTLS enabled, it was not used for the test (so that the fallback is no longer silent and it at least alerts the adminstrative user to a potential issue to investigate)

Actual result:

The certificate is rejected and the connection silently falls back to plain text without notifying any administrative user to alert them to a problem

Justification:

Encrypting to an untrusted certificate is still encrypting, so offers some (limited) protection against sniffing of credentials off the wire even if you can't guarantee complete end-to-end security. If an administrative user has enabled the "trust all certificates" option they are explicitly saying that they want the traffic to be encrypted even if trust cannot be established, so falling back to plain text seems the wrong thing to do. In my company, somehow the IT team have got some domain controllers serving up certificates with incorrect subjects in response to STARTTLS requests, so my Jenkins server has been silently sending credentials in plain text rather than at least encrypting them with something.