Use the FTPS server's cert hostname, not the DNS alias

The pitfall: I pointed curl --ssl-reqd at ftp.swz.gg (my Namecheap account's user-facing FTP host) and got a hard fail:

curl: (60) schannel: SNI or certificate check failed:
SEC_E_WRONG_PRINCIPAL (0x80090322)

The shared-host FTPS server doesn't present a cert for ftp.swz.gg. It presents a wildcard cert for *.web-hosting.com — the cPanel reseller's actual hostname. The DNS alias resolves to the same IP, but TLS verification compares hostnames, not IPs.

Do this: look up the server's real hostname and connect to that.

# What's the cert actually for?
openssl s_client -connect ftp.swz.gg:21 -starttls ftp \
  -servername ftp.swz.gg </dev/null 2>&1 | grep -E 'subject=|DNS:'
# subject=CN=*.web-hosting.com

# What hostname does the IP belong to?
nslookup 63.250.38.72
# Name: premium92-2.web-hosting.com

# Now connect via the verified name:
curl --ssl-reqd --user "engine@example.com:$PASS" \
  "ftp://premium92-2.web-hosting.com/"

Don't do this: -k / --insecure. The cert mismatch is a real symptom that a smarter system can flag. Using -k to ignore it removes that signal — and a sandbox that catches credential exfiltration risks (see the harness rejection in the curl docs link) will refuse anyway.

The reason this matters is operational: when you discover the right hostname once and pin it in your make publish target, your script no longer cares about your DNS provider, your domain registrar, or whether the alias still points at the same box six months later. The cert tells you the truth about who you're talking to. The alias is a convenience for humans.

If you're running into this on a different shared host, run the openssl s_client snippet above. The cert's CN tells you what to put in your script.