Active Directory 2.1.6
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: email@example.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:
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
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)
The certificate is rejected and the connection silently falls back to plain text without notifying any administrative user to alert them to a problem
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.