это проблема на стороне сервера, и она не появлялась ранее, потому что более ранние версии FileZilla поставлялись с версией GnuTLS, которая не выполняла эту проверку.
цитирую Тим Коссе в FileZilla форум тема:
в любом случае проблема с цепочкой сертификатов X. 509 вашего сервера: либо сам сертификат сервера, либо другой сертификат в цепочке имеет ограничение на использование ключа, которое нарушается. Например сертификат с ограничением использования ключа для подписи не может использоваться для проверки подлинности подключений TLS. См. раздел 4.2.1.3 RFC 5280.
это проблема с генерированием сертификатов Microsoft IIS (но может также произойти, если вы неправильно сгенерировали сертификат другим методом), поскольку это не позволяет сертификатам использоваться для цифровых подписей. OpenSSL гораздо более расслаблен в этом и не подведет из-за этого, поэтому он может работать с другими приложения.
на стороне клиента, вы можете либо отключить TLS, понизить до более ранней версии FileZilla (ни один из них не рекомендуется из-за потенциальных угроз безопасности), или использовать другой клиент, который использует другую библиотеку, такую как OpenSSL на данный момент.
как создать действительный сертификат с IIS
это должно быть сделано на стороне сервера, очевидно. Если вы не являетесь администратором, перешлите им эти инструкции.
согласно сообщению в the форумы IIS, вы можете создать сертификат с помощью PowerShell, а пока проблема не будет устранена корпорацией Майкрософт:
New-SelfSignedCertificate -CertStoreLocation cert:LocalMachineMy -dnsname ftp.example.com
заменить ftp.example.com на имя хоста вашего сервера.
вы получите отпечатки, понял. Установите пароль для закрытого ключа:
$password = ConvertTo-SecureString -String "password goes here" -Force -AsPlainText
теперь экспортируйте его (вы можете изменить C:cert.pfx на пути вы хотите сохранить его, просто убедитесь, что он заканчивается .pfx):
Export-PfxCertificate -cert cert:LocalMachineMyFINGERPRINT -FilePath C:cert.pfx -Password $password
Moderator: Project members
-
sandygettings
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-14 18:29
- First name: Sandy
- Last name: Gettings
GnuTLS error -48: Key usage violation in certificate has been detected.
#1
Post
by sandygettings » 2017-01-14 18:39
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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
- Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#2
Post
by botg » 2017-01-14 19:07
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
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-14 18:29
- First name: Sandy
- Last name: Gettings
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#3
Post
by sandygettings » 2017-01-15 02:32
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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
- Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#4
Post
by botg » 2017-01-15 10:34
ftptest.net has been updated, it should now fail as well.
sandygettings wrote:Also, any idea why the FileZilla version for Mac (also 3.24.0) doesn’t complain, and the Windows version does?
botg wrote: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
- 500 Command not understood
- Posts: 2
- Joined: 2017-01-16 10:17
- First name: Mare
- Last name: Nostrum
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#5
Post
by stevia » 2017-01-16 10:34
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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
- Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#6
Post
by botg » 2017-01-16 10:45
stevia wrote:I downgraded to version 3.23.0.2 which solved the problem.
No, this does not solve the problem, it merely hides it.
stevia wrote: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
- 500 Command not understood
- Posts: 2
- Joined: 2017-01-16 10:17
- First name: Mare
- Last name: Nostrum
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#7
Post
by stevia » 2017-01-17 09:28
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
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-14 18:29
- First name: Sandy
- Last name: Gettings
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#8
Post
by sandygettings » 2017-01-17 15:46
(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
- 500 Command not understood
- Posts: 1
- Joined: 2017-01-17 16:48
- First name: Todd
- Last name: Marshall
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#9
Post
by tbm24019 » 2017-01-17 16:55
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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
- Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#10
Post
by botg » 2017-01-17 18:04
sandygettings wrote: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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
-
Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#11
Post
by botg » 2017-01-17 18:09
tbm24019 wrote: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
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-14 18:29
- First name: Sandy
- Last name: Gettings
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#12
Post
by sandygettings » 2017-01-17 23:36
@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
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-16 08:41
- First name: topogigio
- Last name: topogigio
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#13
Post
by bazbg » 2017-01-19 10:19
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
- 500 Command not understood
- Posts: 4
- Joined: 2017-01-16 08:41
- First name: topogigio
- Last name: topogigio
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#14
Post
by bazbg » 2017-01-19 14:23
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
- Site Admin
- Posts: 34969
- Joined: 2004-02-23 20:49
- First name: Tim
- Last name: Kosse
- Contact:
Re: GnuTLS error -48: Key usage violation in certificate has been detected.
#15
Post
by botg » 2017-01-19 14:29
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.
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:LocalMachineMy -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:LocalMachineMyFINGERPRINT -FilePath C:cert.pfx -Password $password
Прочитано:
2 904
Все знают или должны знать что работа через протокол FTP увеличивает риски по перехвату передаваемых аутентификационных данных, т. к. отсутствуют какие-либо средства его защиты, т. е. Имеется реальная возможность перехвата логина и пароля на подключение. Чтобы защитить Ваш FTP сервер я бы порекомендовал настроить работу FTP через SSL или использовать связку FTP через SSH (SFTP). Ладно, ранее я показал и сам использую развернутый FTP сервис, как на Windows серверных системах, таких как Server 2008 R2 & Server 2012 R2 & Ubuntu Server. В самом последней системе я использую защиту, а вот как это сделать до сегодняшней заметки я не знал применительно к Windows системам, но задокумментировав все шаги по этому исправлению текущей ситуации я покажу Вам как это сделать.
В данной заметке все действия будут ориентированы на серверную систему Windows Server 2012 R2
Устанавливаем роль IIS (это будет версия: 8.5.9600.16384) с компонентами FTP см. предыдущую заметку, за исключение что для роли IIS потребуется поставить компоненты — я бы поставил все, дабы потом не искать чего не хватает. Но это мое мнение.
Win + X — Control Panel — Administrative Tools — Internet Information Service (IIS) Manager — SRV-HOST (SRV-HOSTAdministrator) — Server Certificates, далее запускаю действия по созданию самоподписанного сертификата: Create Self-Signed Certificate
- Specify a friendly name for the certificate: FTP over SSL
- Select a certificate store for the new certificate: выбираю Web Hosting
Такими вот простыми действиями создается Ваш первый самоподписанный сертификат сроком на один год, как это проверить, он появился в элементе настройки Server Certificates
Теперь если вспомнить, когда создавали Ваш первый FTP ресурс не важно на базе Windows Server 2008 R2 или Server 2012 R2 в мастере присутствовала настройка выбора, как будет осуществляться защита ресурса, но т. к. у меня не было сертификата (я тогда даже не знал насколько просто создать свой собственный самоподписанный), я выбирал: SSL: No SSL, но теперь я смело указываю, что в роли защиты использовать:
Если FTP ресурс имеется: Sites — srv-host — FTP SSL Settings —
- SSL Certificate: выбираю FTP over SSL
- SSL Policy: Require SSL Connections
и нажимаю Apply
Если FTP ресурса нет, то на этапе настройки безопасности все шаги выше идентичны.
Когда настройки применены должна быть надпись: The changes have been successfully saved.
Теперь проверяю, когда кто-либо подключается к FTP ресурсу, то при обычном вводе параметров подключения: ftp:\IP&DNS в ответ получает лишь:
C:UsersAdmin>ftp IP&DNS
Связь с IP&DNS.
220 Microsoft FTP Service
Пользователь (IP&DNS:(none)): ftpuser1
534 Policy requires SSL.
Сбой входа.
Ftp>
или через утилиту telnet пробуем подключиться к FTP сервису с Windows 7 рабочей станции:
C:UsersAdmin>telnet 10.7.8.177 21
220 Microsoft FTP Service
user ftpuser1
534 Policy requires SSL.
С текущей серверной части где развернут сервис FTP:
C:UsersAdministrator>ftp 10.7.8.177
Connected to 10.7.8.177.
220 Microsoft FTP Service
User (10.7.8.177:(none)): ftpuser1
534-Policy requires SSL.
Win32 error: Access is denied.
Error details: SSL policy requires SSL for control channel.
534 End
Login failed.
Если с помощью программы FileZilla (версия: 3.25.1) происходит подключение, параметры нового соединения следующие с рабочей станции под управлением Windows 7 Pro SP1:
Пуск — Все программы — FileZilla FTP Client — FileZilla — Файл — Менеджер сайтов — Новый сайт:
- Хост: 10.7.8.177
- Порт: ничего не указываем
- Протокол: FTP — Протокол передачи файлов
- Шифрование: Требовать FTP через TLS (явный)
- Тип входа: нормальный
- Пользователь: ftpuser1
- Пароль: Aa1234567@!
- После нажимаю Соединиться
Но мой клиент FileZilla отказывается подключаться, в ответ пишет:
Ошибка GnuTLS -48: Key usage vilation in certificate has been detected.
Невозможно подключиться к серверу
А чтобы подключить с Ubuntu Trusty Server через консоль командной строки:
ekzorchik@srv-mail:~$ ftp 10.7.8.177 21
Connected to 10.7.8.177.
220 Microsoft FTP Service
Name (10.7.8.177:ekzorchik): ftpuser1
331 Password required
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls
200 PORT command successful.
125 Data connection already open; Transfer starting.
03-24-17 04:44PM <DIR> dfdf
226 Transfer complete.
ftp> quit
221 Goodbye.
Как видно подключение происходит без проблем, это если в настройках FTP ресурса стоит политика SSL Policy в значении: Allow SSL Connections, а если выставить в Require SSL Connections, то как раз происходит уведомление, что требуется подтверждение использования сертификата:
ekzorchik@srv-mail:~$ ftp 10.7.8.177 21
Connected to 10.7.8.177.
220 Microsoft FTP Service
Name (10.7.8.177:ekzorchik): ftpuser1
534 Policy requires SSL.
Login failed.
Remote system type is Windows_NT.
Раз так, то значит мне нужен клиент ftp для работы с сертификатами, ставлю его:
ekzorchik@srv-mail:~$ sudo apt-get install ftp-ssl -y
На заметку: устанавливая пакет ftp-ssl удаляется пакет ftp, т. е. Если это обычный ftp то подключиться уже к нему будет нельзя.
ekzorchik@srv-mail:~$ ftp-ssl 10.7.8.177
Connected to 10.7.8.177.
220 Microsoft FTP Service
Name (10.7.8.177:ekzorchik): ftpuser1
234 AUTH command ok. Expecting TLS Negotiation.
[SSL Cipher ECDHE-RSA-AES256-SHA384]
331 Password required
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls
200 PORT command successful.
534 Policy requires SSL.
ftp> ls
200 PORT command successful.
534 Policy requires SSL.
ftp> mkdir 1
257 "1" directory created.
ftp> quit
221 Goodbye.
Подключение с Ubuntu системы прошло успешно.
Итого делаю вывод, что сервис настроенный на Windows с поддержкой самоподписанного сертификата работает, но вот подключиться к нему можно только с Linux системы, с рабочей станции при использовании пакета FileZilla не представляется возможным, почему-то пишет ошибку:
Ошибка GnuTLS -48: Key usage vilation in certificate has been detected.
Невозможно подключиться к серверу
Повторил еще раз данную заметку, если отключаю профили брандмауэера на Server 2012 R2 то могу подключиться с Ubuntu системы через утилиту ftp-ssl, а с Windows систем подключиться не могу. Бред. Нет не бред, это косяк клиента FileZilla самой последней версии (3.25.1) по другому я бы не сказал. Если поставить раннюю версию, к примеру: 3.2.7, то при подключении: File — Site Manager — New Site
вкладка: General
- Host: 10.7.8.177
- Servertype: FTPES — FTP over explicit TLS/SSL
- Logontype: Normal
- User: ftpuser1
- Password: Aa1234567@!
нажимаю «Connect» и вот то окно которое должно сопровождать подключение свидетельствующее что FTP сервис защищен самоподписанным сертификатом и без него к нему нельзя будет подключиться.
На этой информации по сертификату видна дата окончания (через 1 год) и тип шифрования. Для следующего подключения дабы данное окно о сертификате не показывалось следует отметить галочкой настройку: Always trust certificate in future sessions и нажать кнопку Ok
Вот теперь работает. А все проблемы были из-за клиента под Windows, в частности самого последнего клиента утилиты FileZilla, только почему так. А потому я бы все же развернул FTP сервер на Ubuntu системе проблем бы с подключением было бы на порядок меньше. Но не важно, мне же главное иметь представление, как и что нужно сделать дабы защитить подключение клиента и сервера от перехвата и посягательств. На этом я прощаюсь, заметка выполнена, с уважением автор блога Олло Александр aka ekzorchik.
Это проблема на стороне сервера, и она не появлялась ранее, поскольку более ранние версии FileZilla поставлялись с версией GnuTLS, которая не выполняла эту проверку.
Цитирую сообщение Тима Коссе в ветке форума FileZilla:
В любом случае проблема заключается в цепочке сертификатов X.509 вашего сервера: либо сам сертификат сервера, либо другой сертификат в цепочке имеет ограничение на использование ключа, которое нарушается. Например, сертификат с ограничением использования ключа для подписи не может использоваться для аутентификации соединений TLS. См. Раздел 4.2.1.3 RFC 5280.
Это проблема с созданием сертификата Microsoft IIS (но может также произойти, если вы сгенерировали сертификат неправильно с другим методом), так как это не позволяет использовать сертификаты для цифровых подписей. OpenSSL гораздо более раскован по этому поводу и не потерпит неудачу из-за этого, поэтому может работать с другими приложениями.
На стороне клиента вы можете либо отключить TLS, либо перейти на более раннюю версию FileZilla (ни одна из них не рекомендуется из-за потенциальных угроз безопасности), либо использовать другой клиент, который сейчас использует другую библиотеку, например OpenSSL.
Как создать действительный сертификат с IIS
Это должно быть сделано на стороне сервера, очевидно. Если вы не являетесь администратором, отправьте им эти инструкции.
Согласно сообщению на форумах IIS, вы можете генерировать сертификат с помощью PowerShell, пока проблема не будет устранена Microsoft:
New-SelfSignedCertificate -CertStoreLocation cert:LocalMachineMy -dnsname ftp.example.com
Замените ftp.example.com на имя хоста вашего сервера.
Вы получите отпечаток пальца, скопируйте это. Установите пароль для закрытого ключа:
$password = ConvertTo-SecureString -String "password goes here" -Force -AsPlainText
Теперь экспортируйте его (вы можете изменить C:cert.pfx на путь, по которому вы хотите его сохранить, просто убедитесь, что он заканчивается на .pfx):
Export-PfxCertificate -cert cert:LocalMachineMyFINGERPRINT -FilePath C:cert.pfx -Password $password