通过

Configuring FTP 7.5 with Host Header and SSL

  • 项目

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>

or,

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.

image

Under FTP SSL Settings I have the following configuration as shown below:

image

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.

Till next time, Saurabh

Comments

  • Anonymous
    January 27, 2010
    Saurabh, Good article, I'm looking at applying a wildcard certificate to my FTP servers, does the above article still work, or do I need to change some aspects? Marcus

  • Anonymous
    December 14, 2011
    This article describes my problem but where is the solution? How do I do the following? "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." How do I ensure that a valid SSL Certificate is set both at global and individual FTP? What does that mean?

  • Anonymous
    March 16, 2012
    Yes, this article also describes my problem, but, as Bob says, where is the solution?

  • Anonymous
    June 06, 2012
    Solution, as I found it, was to set the global cert for FTP (on the IIS Manager, click on the hostname part of the tree, and under FTP find "FTP SSL Settings".  Set the SSL certificate).  Then click on the individual ftp and under FTP find "FTP SSL Settings" and set the SSL certificate here as well.  That should satisfy the global and individual levels.  Which for me corrected this error when I encountered it.

  • Anonymous
    July 31, 2012
    If I understand correctly, this means is that in real life, only one SSL certificate can be used on a server using Virtual host headers. It is not possible to have 2 or more FTPs sites with a different domain, unless you are willing to exclude all FTP clients which "expect the same certificate for primary and data connections".