Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Interoperability with ProFTP TLSOptions NoCertRequest option. Client certificate prompt keeps showing up #9674

Closed
cyberduck opened this issue Aug 30, 2016 · 13 comments
Closed

Interoperability with ProFTP TLSOptions NoCertRequest option. Client certificate prompt keeps showing up #9674

cyberduck opened this issue Aug 30, 2016 · 13 comments
Assignees
@ylangisc
Labels
bug ftp-tls FTP (TLS) Protocol Implementation worksforme
Milestone
5.3

Comments

@cyberduck
Copy link
Collaborator

5b20b26 created the issue

Yesterday, I updated Cyberduck to the newest version (Version 5.1.0 (20872). Unfortunately, I don’t know which version I updated from, I hadn’t used (or updated) Cyberduck for a few weeks.

Anyway, everything used to work fine and now, it doesn’t: when I ftps into my server (psa-proftpd 1.3.4c-debian7.0.build115130626.18), Cyberduck keeps asking:

The server requires a certificate to validate your identity. Select the certificate to authenticate yourself to [domain of server]

After clicking Disconnect I’m successfully logged into the server, but I’m being asked for a certificate almost every time I want to upload some file, which makes editing remote files utterly exhausting.

In the server config TLSVerifyClient is set to off. Setting TLSOptions NoCertRequest doesn’t change anything

The contents of Cyberduck's log drawer and the complete debug log are attached below.

Attachments
@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you let us know the IP address which will allow us to debug the SSL handshake that causes the prompt for the client certificate.

@cyberduck
Copy link
Collaborator Author

5b20b26 commented

Replying to [comment:2 dkocher]:

Can you let us know the IP address which will allow us to debug the SSL handshake that causes the prompt for the client certificate.


`178.254.6.69`, Port `21`

@cyberduck
Copy link
Collaborator Author

@dkocher commented

osaka:~ dkocher$ /usr/local/Cellar/openssl/1.0.2h_1/bin/openssl  s_client -starttls ftp -connect 178.254.6.69:21
CONNECTED(00000003)
depth=0 OU # Domain Control Validated, OUPositiveSSL, CN = www.scheurle.info
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU # Domain Control Validated, OUPositiveSSL, CN = www.scheurle.info
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.scheurle.info
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgIQUOU5fY9KMo0UbbkCRqJkMDANBgkqhkiG9w0BAQsFADCB
kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV
BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xNTA5MDEwMDAwMDBaFw0xNjEwMTAyMzU5NTlaMFUxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxGjAY
BgNVBAMTEXd3dy5zY2hldXJsZS5pbmZvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAqFzYPQDMaJpr6VZadrEjaIn8iqJy4LxA3RhnfIVh3DMTivZGl1kq
NhRd/YcdBg8IZYvNfVqKWVQ8LfXAY917FTQRg56jS+yxifJ7qRKMEIAYcp1S9hfT
OlebxEWLc2ZV2iELG3R1okwX9+S3Wc1rJJO3RAN+jdza+CQfSwuxsmU5IVwBuDPW
VNIy8ANTCIUDhwLJly6Q4ms1tDpwIFsm39/xC/E92ZiUwaK12G8KiW3Xh96plmSB
nc3rYIioRpjPEmVpaDRnqZM8WDW4LrP+5q9DzXmB8RiGnRf0cgZ+2MRsqkVNyzNR
OwXMQKnifpaweWnoNV3jaK8apQp7QZegVwIDAQABo4IB3TCCAdkwHwYDVR0jBBgw
FoAUkK9qOpRaC9iQ6hJWc99DtDoo2ucwHQYDVR0OBBYEFK5i8l8lm7enbmDsB/dK
lSEAS8aTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysGAQQBsjEBAgIHMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5jb20vQ1BTMAgGBmeB
DAECATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D
T01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3JsMIGFBggr
BgEFBQcBAQR5MHcwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t
L0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcnQwJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTArBgNVHREEJDAighF3
d3cuc2NoZXVybGUuaW5mb4INc2NoZXVybGUuaW5mbzANBgkqhkiG9w0BAQsFAAOC
AQEAWeqqlc1mOsvcdEfFZjbFXravzLNh8p82dpc0r9dDnMmbmeaUtls+ko9laqS9
cbA2YMjgkTNEjtVIHfm7AgONHiZuj0C2jzlBP6xI4Rc4HTFw0+Vz5ey137JtlUWm
6n3YoUm26077GO/QVh4OLwEVe4aCDG+qhVfVg5GcRbuu11AOUfjlASpCkpSdlU49
vyFt4TKSM5BV9w3o7qL6PnsFuSIf/HNF+OSXJmP6dyS2D5l3udO8wu/5tg/ty3LG
zpNgHnNTRTPCTOpqy7d/pp/hhOvpFH28f+9STvtUjKQPtfxahS/PCRZtdMjX9fOx
XOv1a6FsKW6PPOaO6gmmEvjJPA==
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.scheurle.info
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 2139 bytes and written 528 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 89312068D145B98832FB81BB21D1C789D2A6DE64C3692999E3AD718FF898E8DF
    Session-ID-ctx: 
    Master-Key: 24C4AF644087391AA29F94A486F2B8CB9EAC90ED43C8FD730FFCC79D26A810DDC747F2EDA0FF1658DE7BFB2734A97B02
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Compression: 1 (zlib compression)
    Start Time: 1473238237
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
220 178.254.6.69 FTP server ready

@cyberduck
Copy link
Collaborator Author

@dkocher commented

The server is misconfigured and asking for a client certificate to authenticate

SSL_connect:SSLv3 read server certificate request A

Please contact the server adminstrator.

@cyberduck
Copy link
Collaborator Author

5b20b26 commented

Replying to [comment:8 dkocher]:

The server is misconfigured and asking for a client certificate to authenticate.
Please contact the server adminstrator.

I am the administrator. And, after tripple-checking every configuration line, I can assure you: the server's configured quite fine.

To be honest, I don't know much about FTP, about TLS or where the heck that line you're citing above came from. But the way I understand it: No. The server is not asking for a certificate, it's just offering to read one, in case there is any. I fixed the issue server side using TLSOptions NoCertRequest. Quoting from the ProFTPD docs:

-Some FTP clients* are known to be buggy when handling a server's certificate request. This option causes the server not to include such a request during an SSL handshake.

So, i.m.h.o. this is a bug. And since TLS mutual authentication has been in Cyberduck for over 2 years, yet the bug started showing up just now, it's a regression.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Milestone renamed

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Ticket retargeted after milestone closed

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Milestone renamed

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Ticket retargeted after milestone closed

@cyberduck
Copy link
Collaborator Author

@ylangisc commented

Replying to [comment:4 c_scheurle]:

Replying to [comment:2 dkocher]:

Can you let us know the IP address which will allow us to debug the SSL handshake that causes the prompt for the client certificate.


`178.254.6.69`, Port `21`

IP address does not seem to be reachable anymore. Any chance to provide a valid IP or open the firewall for our IP? I would like to track down this issue.

@cyberduck
Copy link
Collaborator Author

5b20b26 commented

Replying to [comment:14 yla]:

Replying to [comment:4 c_scheurle]:

Replying to [comment:2 dkocher]:

Can you let us know the IP address which will allow us to debug the SSL handshake that causes the prompt for the client certificate.


`178.254.6.69`, Port `21`

IP address does not seem to be reachable anymore. Any chance to provide a valid IP or open the firewall for our IP? I would like to track down this issue.

Unfortunately, my server isn't of any use in testing this issue: [comment:9 c_scheurle] wrote: > I fixed the issue server side using `TLSOptions NoCertRequest`.
I'm doing a lot of work on the server right now (remote-editing files), so I'm afraid switching this off again is not an option (apart from the fact that the server belongs to my production system, is protected by a dynamic firewall and uses geo-blocking, so no idea how useful it'd be, anyway). :/
=> Can't you use XAMPP (at least the version on my Mac included ProFTP) for local testing?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

NoCertRequest. Some FTP clients are known to be buggy when handling a server's certificate request. This option causes the server not to include such a request during an SSL handshake.

You possibly need to unset the TLSCACertificateFile and/or TLSCACertificatePath options to make the server not request a client certificate from the client in the SSL handshake.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Milestone renamed

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@ylangisc ylangisc

Labels
bug ftp-tls FTP (TLS) Protocol Implementation worksforme
Projects
None yet
Milestone
5.3
Development

No branches or pull requests
2 participants
@ylangisc @cyberduck