Introduction

A hosting migration can move FTP accounts successfully while FTPES or explicit TLS still presents a certificate for the old hostname. Logins may start, credentials may still be correct, and the server may even be the right machine, but the FTP service keeps advertising a legacy certificate binding that no longer matches the hostname users connect to.

Treat this as a service-certificate problem instead of a general FTP failure. Start by checking which hostname the client uses for explicit TLS and which certificate the FTP service actually presents, because migrated servers often inherit old FTP certificate bindings even after website SSL is already correct.

Symptoms

  • FTP explicit TLS shows a certificate for the old hostname after migration
  • FTP clients warn about hostname mismatch during secure login
  • The server is reachable, but TLS trust warnings appear before file transfer begins
  • Website HTTPS is already correct while FTPES still exposes the previous certificate identity
  • Some users connect only by accepting warnings, while stricter clients refuse the session
  • The issue started after server migration, hostname change, or control panel restore

Common Causes

  • The FTP service still uses a certificate issued for the old hostname
  • The control panel updated website SSL but not the certificate bound to the FTP daemon
  • Users connect with a hostname that no longer matches the FTP service certificate
  • The migrated server retained an older shared certificate for FTP services
  • DNS for the FTP hostname changed, but the certificate assignment for the FTP service did not
  • Migration validation checked website certificates but skipped FTP explicit TLS

Step-by-Step Fix

  1. Test the explicit TLS login and record the hostname the FTP client uses plus the certificate identity presented by the server, because you need to know whether the mismatch comes from the hostname, the certificate, or both.
  2. Compare the certificate subject and hostname with the intended post-migration FTP endpoint, because the server may already be correct while the service certificate still reflects the old hostname.
  3. Check the FTP daemon or hosting control panel certificate binding for FTP services, because website SSL settings and FTP TLS settings are often managed separately.
  4. Verify DNS for the FTP hostname used by clients, because a correct certificate can still look wrong if users connect through a hostname that belongs to the previous environment.
  5. Confirm whether the old server or old certificate is still being served anywhere on the FTP port, because a reachable legacy endpoint can make the migration look partially complete.
  6. Replace or rebind the FTP service certificate to the correct hostname, then retest with a clean client session, because cached certificate decisions can hide whether the actual FTP endpoint is fixed.
  7. Compare one strict client and one permissive client after the change, because certificate problems sometimes appear resolved only on clients that already accepted the old warning.
  8. Verify that both login and file transfer complete without TLS hostname warnings, because the real fix is trusted secure FTP access rather than a bypassed certificate prompt.
  9. Document the final FTP hostname and certificate binding after recovery, because FTP service certificates are easy to overlook during future hosting migrations.