Cyberducks FTPS should work correctly with CAB best practice certificates

[pkramme]

Describe the bug
The CAB recommends that new certificates omit the CommonName field in certificates, and that only the SAN fields are checked. LetsEncrypt creates such certificates when using the "tlsserver" profile. It is expected that such certificates will become the norm in the next years. Additionally, the LetsEncrypt "shortlived" certificate can be issued for IP addresses.

Cyberduck experiences a few issues ranging from display bugs in the untrusted certificate warning to complete connection failures when dealing with those certificates.

1. The "untrusted certificate" dialogue is missing the SAN fields and shows "unknown" as the CommonName. Not answering that dialogue fast enough causes Cyberduck to not work anymore.
2. Connecting via IP causes Cyberduck to lookup the rDNS record for that domain and connect to that. This fails when the server has certificates only for the IP. If you actually have certificates for the rDNS record, then a certificate warning is shown because the rDNS hostname is not matching the IP address.
3. If the server has a correct certificate for the hostname you connect to, Cyberduck still uses the IP address for the PASV connection. This connection doesn't work, because the certificate still cannot be verified.

• https://letsencrypt.org/docs/profiles/#tlsserver

To Reproduce
Steps to reproduce the behavior:

1. Use a server configured with modern SAN certificates, like those issued by LetsEncrypt with the tlsserver or shortlived profiles.
2. Use Cyberducks FTPS and connect either to the hostname or to the IP address. Both will experience issues preventing you from effectively using it.

Expected behavior

1. Validate certificates based on the SAN fields, including hostnames and IP addresses
2. Use SNI for data connections

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: MacOS
• Version: 26.3.1