Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Following these instructions I managed to configure my FTP server for SSL on a windows server 2008 (IIS 7) while enabling Require SSL connections. However I'm not able to connect to the FTP server over SSL.

Troubleshooting done
-disabled firewall on server
-did nmap to the server which reported the below ports:

21/tcp    open  ftp
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
443/tcp   open  https
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
1433/tcp  open  ms-sql-s
1723/tcp  open  pptp
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-term-serv
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown
49155/tcp open  unknown
49157/tcp open  unknown
49158/tcp open  unknown
49159/tcp open  unknown

-based on this list of TCP port I was expecting to see either FTPS (990) or SFTP (22) opened. If I go to the FTP Bindings... settings, the only one list is fto (21) and there aren't any other FTP-related choices I can add. If I try to add HTTPS

-tried filezilla as a client and did following tests over port 21:
FTP mode -> fails with Response: 534 Policy requires SSL.
SFTP mode -> client happy after receiving Response: 220 Microsoft FTP service
FTPS mode -> client sending what looks like a client hello, fails with Response: 451 The parameter is incorrect.

Q: How can I troubleshoot this issue further (ultimate goal is to be able to force client of secured FTP)?

Additional troubleshooting

I'm really stuck at this point. I've tried every protocol Filezilla is offering me (FTPS, SFTP, FTPES): either Filezilla starts talking clear-text FTP and IIS returns Response: 534 Policy requires SSL, or it tries to initiate a secure connection and I get responses such as Response: 451 The parameter is incorrect or Response: 431 Failed to setup secure session.

I'm sniffing traffic with wireshark and I can see that filezilla is properly using the port I'm setting. I've added several ports to the FTP binding on IIS (e.g. 21,22,990..., TCP-handshake is properly established in every case) and I get the same behaviour whatever I try.

I also had a look at the FTP logs in c:\inetpub\logs\LogFiles and all I get are useless messages such as ControlChannelOpened, ControlChannelClosed, AUTH TLS, AUTH SSL which don't help with understanding why things are actually failing.

Q: How can I troubleshoot this further (is there a debug mode for the ISS FTP) ?

share|improve this question
up vote 5 down vote accepted

Your test worked. What you are setting up is actually FTPS, or FTP-Secure, and Filezilla noted this with a successful 220 response in your test. Despite the similar name, SFTP is a totally different animal, which transmits files over an SSH (Linux standard) connection.

Ports are agnostic, that is, they don't particularly care if the traffic you send through is encrypted or not, and they only require that the same port is being used for both the sender (the server) and the receiver (the client) of traffic. So, if you know that you will only send your traffic over port 21, just remember that the server requires an SSL connection.

If you do not control the client, and which ports they are allowed to connect to, you should change your IIS FTP port from the default of 21 to the industry standard 990. Changing the port in IIS is quite simple, in step 4 of the tutorial that you used, just change the default port of 21, as seen in the image below, to the FTPS port of 990. screen shot of IIS control panel

Remember to reset your firewall to port 990 as well, and to restart your IIS server for the changes to take effect.

UPDATED (Now with Filezilla client instructions)

I think that we may be going a bit haywire with figuring out the problem, so rather than changing more settings and possibly creating more issues, I created a test server using localhost on my Windows 7 laptop, and connected to it with Filezilla. Because you showed me your tutorial on creating an FTP site, and you were able to create a non-secured connection without any problems, I am going to gloss over that and concentrate on the Filezilla session, where the problem has a better chance of occurring.

First, I set up my default FTP site, called "Test." Remember, I am running Windows 7, so even though the steps are the same, they may look different than your server. IIS managment screen As I said before, the port is not important, the only requirement is that the server and client use the same one. But, to keep with convention, I will continue to use port 990.

I tell IIS to require an SSL connection (the default allow is okay, but we want to force clients to use SSL, so we make is clear that is what we want). And, because we are testing, we will use the default IIS Express Development Certificate as in the screenshot below. In real life, you should get an SSL certificate from a reputable source, but if you do not, you probably will be able to connect, but the client will give a warning. (disclosure: I am not terribly familiar with securing sites with SSL, so I would confirm your settings before releasing your site to the public) SSL Settings screen

Once the site is started, confirm that you are connecting to your server using the prefix ftps://. This is how the FTP client knows you need to create a secure connection, and why I keep repeating that the port number is irrelevant. Continue to use your username and password as you've set it up (I am using anonymous and no password), and insert your port number at the end, though if you are using the FTPS default of 990, Filezilla tends to erase it when you connect. My log is shown in the screenshot below. Filezilla log screen

The last gotcha that comes to mind is this: be sure that the clock is set correctly between the server and the client. It can be a few hours off, but SSL uses the timestamp to validate the security, and often a computer is set to the default California timezone, and the user naively resets the time to the local time without correcting the timezone. This would create an enormous variation in the times, and may account for odd SSL errors.

Let me know how your logs look, and I'll see if I can help you from there!

share|improve this answer
The names are actually backwards, SFTP is FTP over SSH, and FTPS is FTP over SSL. It happens all the time. More information on FTP/S and firewalls:… – KJ-SRS Feb 8 '12 at 18:31
I had thought that they were backwards, but I was following what the original poster had said rather than looking up the proper abbreviations. -1 for me. – Simon Hova Feb 8 '12 at 20:08
I guess by to the SFTP port of 990 you meant to the FTPS port of 990 – Max Feb 10 '12 at 9:16
I've done additional troubleshooting and need further assistance, please see updated question. – Max Feb 10 '12 at 10:22
Issue fixed. I don't know what I was doing wrong before (because it was some time ago) but following your steps fixed the issue. We did have another issue with our wildcard certificate being 4096 which was causing SSL handshake to fail. Replacing it with a self-signed solved that problem, which is OK since the FTP is for internal-use only. – Max Mar 13 '12 at 11:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.