3

I am using System.Net.FtpClient to download FTP files. I've run into an odd issue on Windows Server 2012, where I am getting the following exception:

System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The message received was unexpected or badly formatted\r\n --- End of inner exception stack trace ---\r\n at System.Net.FtpClient.FtpSocketStream.ActivateEncryption(String targethost, X509CertificateCollection clientCerts)\r\n at System.Net.FtpClient.FtpClient.OpenPassiveDataStream(FtpDataConnectionType type, String command, Int64 restart)\r\n at System.Net.FtpClient.FtpClient.OpenDataStream(String command, Int64 restart)\r\n at System.Net.FtpClient.FtpClient.GetListing(String path, FtpListOption options)\r\n at System.Net.FtpClient.FtpClient.GetListing(String path)\r\n at Service.Ftp.Workflows.Download.Actions.DownloadFilesAction.Execute(Workflow workflow) in e:\Development\source\Service.Ftp\Workflows\Download\Actions\DownloadFilesAction.cs:line 45\r\n

When this exception occurs, I am using System.Net.FtpClient as follows:

ftpClient.ValidateCertificate += delegate(FtpClient control, FtpSslValidationEventArgs e) { e.Accept = true; };
ftpClient.Host = "host";
ftpClient.Credentials = new NetworkCredential("username", "password");
ftpClient.EncryptionMode = FtpEncryptionMode.Explicit;
ftpClient.DataConnectionEncryption = true;
ftpClient.Connect();
List<FtpListItem> remoteFiles = ftpClient.GetListing("/RemoteFolder/").ToList();

The interesting thing is that the Connect() call works - it's the GetListing() that fails.

The above code works perfectly on WIndows 7 and Windows Server 2008 R2, but fails on Windows Server 2012.

If anyone has any ideas, I'd love to hear them.

Matt Salmon
  • 81
  • 6
  • Did you figure this out? It looks like maybe your process user doesn't have rights to access your local certificate store for a client certificate. It's maybe trying to use SSPI to see if the user/machine has a client cert it can use for the block cipher use to encrypt the data stream. – user326608 Sep 05 '15 at 11:10
  • 1
    Nope, never managed to figure this out - I eventually had to install the service onto a Win2008 server which was less than ideal. Your comment may be right though - that's something I hadn't thought of. Can you elaborate on what permissions I would need to set? Oh, and I did make the process user a local admin on the box and that also didn't work. – Matt Salmon Sep 06 '15 at 16:37
  • OK; looks more like a handshake issue in System.Net.FtpClient - see http://stackoverflow.com/questions/29712207/a-call-to-sspi-failed-see-inner-exception-using-filezilla-server-and-system-net and https://netftp.codeplex.com/workitem/388 – user326608 Sep 07 '15 at 22:57
  • How come it works on a Win2008 server and not Win2012 though? Same code, different server - one works, the other doesn't? Is it due to to cert support on 2012 possibly? – Matt Salmon Sep 09 '15 at 09:54
  • It's the channel security I think - either way it's a bug in someone's DLL that you're using. e.g. the destination server you're connecting to is older tech, and is offering (say) SSLv2 in the handshake. On Server 2008, SSPI offers that in the client handshake to start with, so no problem. On 2012, SSLv2 is probably deprecated somewhat; so it's not in the initial handshake offer from SSPI, probably just SSLv3 and TLS. System.Net.FtpClient has to process the extra handshake roundtrip to downgrade the channel security, which SSPI will (reluctantly) agree to. cont -> – user326608 Sep 09 '15 at 14:15
  • When processing that extra step, System.Net.FtpClient (or, the piece it references in order to do SSL) soils itself. It might also just be bad flags passed to SSPI to begin with, that the SSPI implementation on 2008 processed in spite of itself, that SSPI on 2012 no longer honors. – user326608 Sep 09 '15 at 14:19
  • Here's some obscure reading if you're interested in the mechanics: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374782%28v=vs.85%29.aspx – user326608 Sep 09 '15 at 14:28
  • Briliant explanation, thank you. "Soils itself" made me laugh. It's going to take me a while to be able to get back to this code now but it makes perfect sense, I'm pretty sure you've cracked it here. – Matt Salmon Sep 12 '15 at 05:16

0 Answers0