5

I get the following error when connecting to our server:

GnuTLS error -48: Key usage violation in certificate has been detected. Could not connect to server

This problem appeared after upgrading to Filezilla v3.24.0 for Windows on a PC running Windows 10 Pro with all updates. The Mac version (also v3.24.0) works normally with no error. No changes have been made to the server recently.

Connection info: Protocol: FTP - File Transfer Protocol Encryption: Require explicit FTP over TLS Login Type: Ask for password

Ftptest.net tested against our server does not show any related issues. Plain FTP (unencrypted) works, but that's not a good idea. I could not find a solution to this problem on Google. Any suggestions?

Improve this question
4
  • Who is certificate authority, that signed issued certificate? Startcom.org/startssl.com?
    – Alex
    Jan 14, 2017 at 22:32
  • It is a self-signed cert issued by the hosting service, LiquidWeb. The cert has not expired and no security changes have been made to the server. This problem just appeared yesterday, and there was no problem using Filezilla two weeks earlier. Nor does the Mac version of Filezilla complain. Could this problem actually be on my PC (client-side)?
    – Sandy Gettings
    Jan 15, 2017 at 13:26
  • I think the problem is with self signed certificate on server side. Check if key usage restriction support "Key Encipherment" and "Critical" , there may be also set incompatible bits in restrictions. Do not assign permission in key usage that is not related to TLS connection
    – Alex
    Jan 16, 2017 at 5:52
  • I've fixed the problem by using our RapidSSL cert for all FTP sites on the server. Before, there was a mix of RapidSSL and self-signed certs for the sites. I also set the top-level FTP settings in IIS to use the RapidSSL cert. After that, Filezilla complained that the cert was unknown, but that's easy to approve. I'm not posting this as an answer, because there are a lot of underlying technical details I'm not fully understanding. But it's up and working again :)
    – Sandy Gettings
    May 7, 2017 at 13:05

2 Answers 2

Reset to default
0

Please refer to this post on Filezilla Forum : https://forum.filezilla-project.org/viewtopic.php?t=42790

Improve this answer
2
  • Links can change and expire and therefore are not good answers. Copy the relevant information into an answer and include the link as reference and you will have a much better answer that will continue to be valuable even if the link itself ceases to function.
    – music2myear
    Feb 1, 2017 at 0:42
  • OP here. I'm flattered that the post you lied to was my conversation with the Filezilla folks. The problem is fixed. See my recent comments in the original post above.
    – Sandy Gettings
    May 7, 2017 at 13:03
8

This is a server-side issue, and it did not appear previously because earlier versions of FileZilla shipped with a GnuTLS version that didn't make this check.

Quoting Tim Kosse's post in the FileZilla forum thread:

In any case, the problem is with your server's X.509 certificate chain: Either the server certificate itself or another certificate in the chain has a key usage restriction that is violated. For example a certificate with a key usage restriction to signing cannot be used to authenticate TLS connections. See section 4.2.1.3 of RFC 5280.

This is a problem with the certificate generation of Microsoft IIS (but may also happen if you incorrectly generated a certificate with another method), as it does not allow the certificates to be used for digital signatures. OpenSSL is much more relaxed about this and won't fail because of it, so it may work with other apps.

On the client side, you can either disable TLS, downgrade to an earlier version of FileZilla (neither of these is recommended due to potential security risks), or use a different client which uses another library such as OpenSSL for now.

How to generate a valid certificate with IIS

This needs to be done on the server side, obviously. If you aren't the admin, forward these instructions to them.

According to a post in the IIS forums, you can generate the certificate with PowerShell instead until the issue is fixed by Microsoft:

New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -dnsname ftp.example.com

Replace ftp.example.com by your server's hostname.

You will get a fingerprint, copy that. Set a password for the private key:

$password = ConvertTo-SecureString -String "password goes here" -Force -AsPlainText

Now export it (you can change C:\cert.pfx to the path you want to save it to, just make sure it ends in .pfx):

Export-PfxCertificate -cert cert:\LocalMachine\My\FINGERPRINT -FilePath C:\cert.pfx -Password $password
Improve this answer
2
  • The newer version of New-SelfSignedCertificate has a flag -KeyExportPolicy Exportable which you might need to set to export it. See MS Documentation
    – lloyd
    Feb 27, 2019 at 8:22
  • thanks a lot for great instructions
    – smoothumut
    Apr 24, 2021 at 8:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .