FTP 7.5 comes with new features like supporting Host headers (Virtual host) and SSL. For compatibility purposes, FTP clients can check whether the FTP server supports host headers by sending a FEAT command to check for supported features. An FTP server would respond with HOST being one of the extended features supported by it and from here on client can use this feature.
There are two ways of using this feature currently by the FTP clients:
1. They can send the virtual host name along with the Username while getting authenticated by the FTP server as below:
C:\>ftp ftp.me.com Connected to ftp.me.com. 220 Microsoft FTP Service User (ftp.me.com:(none)): ftp.me.com|<username> 331 Password required for ftp.me.com|<username> Password: 230 User logged in. ftp>
2. They can send the following command to connect to a specific Virtual host name as below:
ftp> quote host ftp.me.com 220 Host accepted. ftp> user Username <username> 331 Password required for <username>. Password: 230 User logged in. ftp>
In this example the test is done through the default ftp.exe that comes bundled with Windows OS. Smart FTP clients can send the HOST seamlessly without the end user knowing about it.
If you are setting up your FTP site on IIS 7 over SSL using the host header there are some caveats you need to remember as discussed below.
I have an FTP site as shown below which is using a Host header and is configured to accept SSL connections.
Under FTP SSL Settings I have the following configuration as shown below:
If we try to access the FTP site using an SSL enabled FTP client it will fail as shown below:
Command: AUTH TLS Response: 534-Local policy on server does not allow TLS secure connections. Response: Win32 error: Access is denied. Response: Error details: SSL certificate was not configured. Response: 534 End Command: AUTH SSL Response: 534-Local policy on server does not allow TLS secure connections. Response: Win32 error: Access is denied. Response: Error details: SSL certificate was not configured. Response: 534 End
*Output from Filezilla FTP client
NOTE: AUTH TLS/SSL Negotiation for Primary connection is done based on the certificate at the global level and uses the certificate installed at the site level for Data connection.
Some FTP clients like FileZilla require the same SSL certificate to be used for both the control and the data channel. If the certificates don’t match the primary connection will be established but the data transfer connection will be aborted as shown below:
Command: LIST Response: 150 Opening BINARY mode data connection. Error: Primary connection and data connection certificates don't match. Error: Transfer connection interrupted: ECONNABORTED - Connection aborted Response: 226 Transfer complete. Error: Failed to retrieve directory listing
*Output from Filezilla FTP client
If we have the SSL Certificate only at the global level and not at the FTP site level we will see an error again as below:
Command: PROT P Response: 431-Failed to setup secure session. Response: Win32 error: Response: Error details: SSL certificate hash has invalid length. Response: 431 End .... .... Command: LIST Response: 534-Protection level negotiation failed. Response: Win32 error: Access is denied. Response: Error details: Protection negotiation failed. PROT command with recognized parameter must precede this command. Response: 534 End Error: Failed to retrieve directory listing
*Output from FileZilla FTP client
So overall, we need to ensure that a valid SSL certificate is set both at the global and the individual FTP site levels. It finally depends upon the FTP client whether to expect the same certificate or different ones for primary and data connections.