GnuTLS error -48: Key usage violation in certificate has been detected.

[sandygettings]

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. 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 solutions to this problem on Google. Any suggestions?

[botg]

Different TLS library versions explain the different observed behavior.

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.


In the coming days I'll work on updating ftptest.net so that it will also correctly fail on your broken server.

[sandygettings]

Thanks for the tip, but I'll have to do more research to understand what to do. Please let me know when you've updated the test, as any assistance is appreciated.

Also, any idea why the FileZilla version for Mac (also 3.24.0) doesn't complain, and the Windows version does?

[botg]

ftptest.net has been updated, it should now fail as well.

Also, any idea why the FileZilla version for Mac (also 3.24.0) doesn't complain, and the Windows version does?

Different TLS library versions explain the different observed behavior.

The version of GnuTLS used by the OS X client, as well as previously ftptest.net, unfortunately does not detect key usage violations.

[stevia]

I experienced the same GnuTLS Error 48 after having upgraded to the latest version 3.24.0 version (Windows 10).
At that point in time I did not have the time to mess with this so I downgraded to version 3.23.0.2 which solved the problem.

I'm using a self signed certificate for FTP.
Does this mean that I now need to use a "real" third party signed certificate for all coming versions?

[botg]

I downgraded to version 3.23.0.2 which solved the problem.

No, this does not solve the problem, it merely hides it.

I'm using a self signed certificate for FTP. Does this mean that I now need to use a "real" third party signed certificate for all coming versions?

No. It merely means that the self-signed certificate has been created incorrectly: Wrong key usage flags have been specified during creation.

Essentially there's a set of flags in your certificate that boil down to "You cannot use this certificate for TLS connections".

[stevia]

Thanks for this information.
I created a new self signed certificate in IIS manager (Windows Server 2012 R2), however, there are no options to specify key usage flags
(in fact there are no options at all except where to store the certificate).
When i tried this new certificate with the new version 3.24.0 I got the same GnuTLS Error 48.
Could it be that these flags for some reason are intentionally set in IIS self signed certificates in order to disable TLS?

Anyway I switched to a CA signed certificate and then it worked error free.
So now I'm up on the 3.24.0 version again.

[sandygettings]

(Crap, my post was discarded, so I'm retyping.)

@botg: Thanks for the suggestions. I'm highly technical, but SSL isn't my area of experience. I'm using a wildcard cert (*.adacare.com from RapidSSL). I installed it some months ago per RapidSSL's instructions. I'm not sure if the issue is due to the cert, or if the problem is my server configuration (Win Server 2008 R2 Standard). Also, I'm seeing the same problem on two different PCs, so I don't think it's due to the PC. The server has two SSL site configured (one for each disk) and I normally connect FTP by IP address, but I see the same problem when I connected by ftp.adacare.com.

Can you suggest any tools to help pinpoint the problem? Any assistance is much appreciated!

[tbm24019]

I continue to have the same problem as described, after the upgrade to FileZilla 3.24.0. I am using GnuTLS 3.5.8. All worked fine until the upgrade, and now I am not able to connect to the desired server. I am not overly familiar with the components. I haven't done anything with GnuTLS. When I first downloaded FileZilla, I got all working without changing anything.

Yesterday I downloaded WinSCP, and all works fine. But, I would like to correct the FileZilla issue.

Directions on what to do?

Thanks.

[botg]

I see the same problem when I connected by ftp.adacare.com.

Thank you for posting the hostname. I had more detailed look at the certificate your server sends.

Code: Select all

gnutls-cli -p 21 --crlf -s ftp.adacare.com -V --insecure
Processed 0 CA certificate(s).
Resolving 'ftp.adacare.com:21'...
Connecting to '67.227.183.103:21'...

- Simple Client Mode:

- Received[27]: 220 Microsoft FTP Service
AUTH TLS
- Sent: 10 bytes
- Received[49]: 234 AUTH command ok. Expecting TLS Negotiation.
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 749783a9d7326d8c47dbb61a1ec34de2
        Issuer: CN=H2-ADACARE.win.liquidweb.com
        Validity:
                Not Before: Sun Apr 24 15:30:12 UTC 2016
                Not After: Mon Apr 24 00:00:00 UTC 2017
        Subject: CN=H2-ADACARE.win.liquidweb.com
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: Medium (2048 bits)
                Modulus (bits 2048):
                        00:bc:56:84:ce:23:13:e9:db:00:8b:de:5a:b1:35:99
                        da:18:40:f1:1d:2f:62:6c:88:1f:43:63:5a:a2:55:f3
                        0d:4d:99:f2:69:9b:ab:20:f7:ae:26:de:13:d0:a0:e3
                        a2:10:2a:84:c0:6b:39:b7:90:6d:80:32:0e:5b:61:6f
                        2b:b2:d2:c0:b8:26:ba:ae:df:51:19:46:88:14:d2:ed
                        a0:c4:66:30:25:2f:dc:3a:66:ef:17:31:92:6a:d5:19
                        dc:90:76:d5:49:2f:80:23:d2:28:06:d3:0d:58:36:11
                        d1:65:e9:3f:b1:da:8c:ad:17:6e:2c:0b:d3:f8:6e:26
                        b8:76:d5:23:83:9d:81:e3:65:a6:cc:46:e4:d7:fb:ae
                        a6:2b:2e:ea:ec:c8:72:5d:96:0f:90:a5:19:87:ee:d2
                        72:d8:6d:1a:b5:53:01:fa:18:7a:4c:ec:aa:e8:f8:d6
                        96:40:aa:44:5f:71:a7:53:17:a2:b8:fc:02:0f:ee:01
                        17:82:63:a7:91:59:8c:2e:f9:aa:9e:0e:5a:9d:54:97
                        13:4d:41:8b:f9:df:5d:f5:ab:16:f1:fd:fc:2c:3b:45
                        8e:cc:5d:8b:93:22:b6:f0:d0:8e:a2:6a:84:a8:ea:50
                        08:2d:96:af:0b:98:0b:12:ad:b8:b5:be:38:cd:99:a2
                        af
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Key Usage (not critical):
                        Key encipherment.
                        Data encipherment.
                Key Purpose (not critical):
                        TLS WWW Server.
        Signature Algorithm: RSA-SHA1
        Signature:
                76:ed:95:af:29:ca:17:7a:bf:b2:be:02:58:6c:ae:e8
                c3:1b:b2:dd:76:30:28:f9:8d:ad:a7:f9:d1:2b:b9:ac
                6f:2b:63:2d:6f:e6:97:25:a2:7f:6b:be:e4:da:65:f1
                0a:41:d3:c6:b5:90:f7:2d:a3:34:a1:0e:70:e6:eb:2b
                80:b6:4c:56:72:ab:3f:89:cd:c8:92:bc:f2:e4:3c:54
                59:7f:f8:53:0e:56:47:86:b1:19:34:60:24:aa:bb:8e
                06:2a:f6:9e:fe:07:7c:29:9d:cc:24:d0:e4:d7:f9:71
                40:8f:5c:e0:a1:a7:89:56:0a:2d:b7:40:e2:6e:f1:2e
                78:51:0a:16:de:b0:e5:3d:73:e3:23:13:bf:b1:85:14
                45:0c:65:0c:19:8a:96:18:15:27:14:43:44:fa:7c:2b
                2d:7a:84:91:fb:81:3a:e0:ac:45:73:bd:9d:be:fe:15
                a4:1a:1a:c7:1a:4a:d3:eb:4e:43:f5:d4:15:6e:e4:5d
                ee:7c:ae:e6:51:15:a4:b3:ca:ae:24:b6:c3:64:ba:a5
                27:df:6f:b9:55:ef:52:d9:89:75:f4:85:41:29:22:bb
                16:85:0d:5d:47:c9:92:78:4a:a2:cb:33:6c:10:cb:3c
                6a:bb:be:33:99:3b:5e:e8:d2:75:8f:00:0b:fa:ab:d8
Other Information:
        Fingerprint:
                sha1:ac6541db524a5ed1bdc98b98de4644c0464024f2
                sha256:cb773528fe716368531f2b2df4d8465c7eddc8fd903104e73cf0ab8ddb8e4cd4
        Public Key ID:
                sha1:a5709aefdca1ef55df3530cd72e3edf70ebab55f
                sha256:1c8a6657094d46b3e858bc9c2371763ccb45e485332933575b1c1dada292bfc4
        Public key's random art:
                +--[ RSA 2048]----+
                |                 |
                |              o  |
                |      . . .  + = |
                |       = o    * o|
                |      o S     .oo|
                |       .     . o+|
                |        . . . o E|
                |       o o o o o+|
                |        +o+ o..o+|
                +-----------------+


-----BEGIN CERTIFICATE-----
MIIC/DCCAeSgAwIBAgIQdJeDqdcybYxH27YaHsNN4jANBgkqhkiG9w0BAQUFADAn
MSUwIwYDVQQDExxIMi1BREFDQVJFLndpbi5saXF1aWR3ZWIuY29tMB4XDTE2MDQy
NDE1MzAxMloXDTE3MDQyNDAwMDAwMFowJzElMCMGA1UEAxMcSDItQURBQ0FSRS53
aW4ubGlxdWlkd2ViLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALxWhM4jE+nbAIveWrE1mdoYQPEdL2JsiB9DY1qiVfMNTZnyaZurIPeuJt4T0KDj
ohAqhMBrObeQbYAyDlthbyuy0sC4Jrqu31EZRogU0u2gxGYwJS/cOmbvFzGSatUZ
3JB21UkvgCPSKAbTDVg2EdFl6T+x2oytF24sC9P4bia4dtUjg52B42WmzEbk1/uu
pisu6uzIcl2WD5ClGYfu0nLYbRq1UwH6GHpM7Kro+NaWQKpEX3GnUxeiuPwCD+4B
F4Jjp5FZjC75qp4OWp1UlxNNQYv53131qxbx/fwsO0WOzF2LkyK28NCOomqEqOpQ
CC2WrwuYCxKtuLW+OM2Zoq8CAwEAAaMkMCIwCwYDVR0PBAQDAgQwMBMGA1UdJQQM
MAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQB27ZWvKcoXer+yvgJYbK7o
wxuy3XYwKPmNraf50Su5rG8rYy1v5pclon9rvuTaZfEKQdPGtZD3LaM0oQ5w5usr
gLZMVnKrP4nNyJK88uQ8VFl/+FMOVkeGsRk0YCSqu44GKvae/gd8KZ3MJNDk1/lx
QI9c4KGniVYKLbdA4m7xLnhRChbesOU9c+MjE7+xhRRFDGUMGYqWGBUnFENE+nwr
LXqEkfuBOuCsRXO9nb7+FaQaGscaStPrTkP11BVu5F3ufK7mURWks8quJLbDZLql
J99vuVXvUtmJdfSFQSkiuxaFDV1HyZJ4SqLLM2wQyzxqu74zmTte6NJ1jwAL+qvY
-----END CERTIFICATE-----

- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.
*** PKI verification of server certificate failed...
|<1>| Peer's certificate does not allow digital signatures. Key usage violation detected.
*** Fatal error: Key usage violation in certificate has been detected.
*** Handshake has failed

[/size]


The important bits are these:

Code: Select all

        Issuer: CN=H2-ADACARE.win.liquidweb.com
        [...]
        Subject: CN=H2-ADACARE.win.liquidweb.com

Code: Select all

              Key Usage (not critical):
                        Key encipherment.
                        Data encipherment.

It's a self-signed certificate, however the key usage extension only has the flags for key enciphernment and data enciphernment set, it is lacking the keyCertSign flag, meaning that the key cannot be used to sign certificates.

[botg]

Yesterday I downloaded WinSCP, and all works fine. But, I would like to correct the FileZilla issue.

It's not a FileZilla issue, it is an issue with your server's certificate.

[sandygettings]

@botg: Your results looked odd, because you saw a self-signed cert when I had explicitly specified a RapidSSL cert for one of our FTP sites on this server. So I set the cert for the other SSL site to the RapidSSL cert. 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.

Short version: I was using RapidSSL in some places but not others within IIS for FTP. Now it's working fine. Thanks big-big for your help!

[bazbg]

same problem: 3.24 broken access to every IIS self signed FTPS.

Why not an option to disable this new check that user can select to avoid troubles? We worked until yesterday and now if someone updates the client nothing works. And it's really more complex to find a way to publish FTPS on IIS creating "perfect" certificates...

[bazbg]

Yes.
If you upgrade to 3.24 it stops working. If you downgrade to 3.23, it starts working again.

If Filezilla will mantain this strict new policy, I think that IIS self signed will not work anymore.

[botg]

If IIS creates bad certificates then you need to contact Microsoft to have IIS fixed. Alternatively use a different program to create proper self-signed certificates.

Why not an option to disable this new check that user can select to avoid troubles?

Very simple reason: Then these broken certificates will never get fixed.