[dxbjavid]

setEndpointCheckingEnabled(true) only takes effect in sslNegotiation, so the control connection gets HTTPS endpoint identification while the data socket opened for each transfer in _openDataConnection_ completes its handshake without it. With the default trust manager, which checks validity but not the name, an in-path attacker on the data port can present any trusted certificate issued for another name and read or alter listings and file contents, even though the caller asked for endpoint checking (the same gap #404 closed for the HostnameVerifier option).

Switching on the algorithm alone is not enough: the control socket is layered with _hostname_, but the data socket is connected to an address (or accepted in active mode), so the JDK would match the certificate against the peer IP only and every name based certificate fails with "No subject alternative names present" (that is what happens to the existing endpointCheckingEnabled=true tests with only the flag set). The change therefore also passes the control connection host name as the SNI server name, which the JDK trust manager uses for endpoint identification; IP literals are left out since they are not valid SNI names and are matched against the peer address as before.

The new test fails on master (expected: <HTTPS> but was: <null>) and passes with the change; the existing endpoint checking transfer tests exercise the actual name match against the test certificate. The default goal build (mvn) passes: 633 tests, checkstyle, PMD, japicmp and rat clean.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Claude Code (Anthropic) drafted the change, the test and this description; I reviewed the result and ran the build before submitting.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.