• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

FTPS not working after Plesk upgrade

Xavier12

Regular Pleskian
Hey guys,

For some reason FTPS is no longer working as it used to before plesk upgraded. At this point, I am not sure which Plesk upgrade caused this since I do not FTPS or ftp in general often. its enabled as it was before, even disabled and re-enabled it again. Still gives a "could not establish connection". Restarted the service via command Line with "service xinetd restart". still isnt working

Please advise, thanks.
 
For testing purposes have you tried to see if plain FTP works by changing the option in the Plesk Panel and then changing your FTP client to see if it can connect without using FTPS?
 
For testing purposes have you tried to see if plain FTP works by changing the option in the Plesk Panel and then changing your FTP client to see if it can connect without using FTPS?

ok, lets start from here:

- FTP works, FTPS does not work. FTPS gives the error as previously mentioned on transmit ftp for mac
- In FTPS Usage policy within Tools & Settings / Security Policy. I've disabled and re-enabled by choosing the "Allow Both" then "Allow only secure ftps, etc".
- Right after, tried the following in command line: "Service psa restart" and "Service xinetd restart"

After these steps, FTPS (aka secure ftp) isn't working and results in the same error mentioned previously.
 
Guys,

Is there any fix or update for this? This is a serious security issue. It seems one of our customers were hacked because of using non-secure FTP...
 
Bumping this again. Still trying to understand why this issue isn't being resolved or addressed..
 
After more than 15 days this issue and post seems to be completely ignored with no resolution, acknowledgement/response.
 
Make sure that you have the same options in your /etc/proftpd.conf:

<IfModule mod_tls.c>
# common settings for all virtual hosts
TLSEngine on
TLSRequired off

TLSLog /var/log/plesk/ftp_tls.log

TLSRSACertificateFile /usr/local/psa/admin/conf/httpsd.pem
TLSRSACertificateKeyFile /usr/local/psa/admin/conf/httpsd.pem

# Authenticate clients that want to use FTP over TLS?
TLSVerifyClient off

# Allow SSL/TLS renegotiations when the client requests them, but
# do not force the renegotations. Some clients do not support
# SSL/TLS renegotiations; when mod_tls forces a renegotiation, these
# clients will close the data connection, or there will be a timeout
# on an idle data connection.
TLSRenegotiate none

# As of ProFTPD 1.3.3rc1, mod_tls only accepts SSL/TLS data connections
# that reuse the SSL session of the control connection, as a security measure.
# Unfortunately, there are some clients (e.g. curl) which do not reuse SSL sessions.
TLSOptions NoSessionReuseRequired
</IfModule>

Any differences? Do you really have cert /usr/local/psa/admin/conf/httpsd.pem ? Any detalis in /var/log/plesk/ftp_tls.log?
 
Hi Igor,

Thanks for responding and for the support. All settings mentioned are the same. Here is the error received in the log

2015-05-23 04:57:12,968 mod_tls/2.6[567356]: starting TLS negotiation on data connection
2015-05-25 15:17:45,311 mod_tls/2.6[865258]: TLS/TLS-C requested, starting TLS handshake
2015-05-25 15:17:45,389 mod_tls/2.6[865258]: unable to accept TLS connection: protocol error:
(1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2015-05-25 15:17:45,389 mod_tls/2.6[865258]: TLS/TLS-C negotiation failed on control channel
2015-05-26 00:49:11,507 mod_tls/2.6[897178]: TLS/TLS-C requested, starting TLS handshake
2015-05-26 00:49:11,625 mod_tls/2.6[897178]: unable to accept TLS connection: protocol error:
(1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2015-05-26 00:49:11,625 mod_tls/2.6[897178]: TLS/TLS-C negotiation failed on control channel
 
Do you have enabled firewall on your server? Have you tried check ftps connection with disabled firewall? Try to check ftps connection inside and outside server with

# openssl s_client -connect xxx.xxx.xxx.xxx:21 -starttls ftp
CONNECTED(00000003)
......
 
Hi there,

Thanks for reaching back. Here is the output:

depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = subdomain.mydomain.com

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = subdomain.mydomain.com

verify error:num=27:certificate not trusted

verify return:1

depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = subdomain.mydomain.com

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

0 s:/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=subdomain.mydomain.com

i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

---

Server certificate

-----BEGIN CERTIFICATE-----

CERTIFICATE INFO HERE
-----END CERTIFICATE-----

subject=/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=subdomain.mydomain.com

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

Server Temp Key: DH, 1024 bits

---

SSL handshake has read 2229 bytes and written 461 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1.2

Cipher : DHE-RSA-AES256-GCM-SHA384

Session-ID: SESSION ID HINFO HERE

Session-ID-ctx:

Master-Key: MASTER KEY INFO HERE

Key-Arg : None

Krb5 Principal: None

PSK identity: None

PSK identity hint: None

Start Time: 1432619392

Timeout : 300 (sec)

Verify return code: 21 (unable to verify the first certificate)

---

220 ProFTPD 1.3.5 Server (ProFTPD) [xxx.xxx.xxx.xxx]

421 Login timeout (300 seconds): closing control connection

closed
 
What is output of command

# ls -la /usr/local/psa/admin/conf/httpsd.pem
 
Hi, yes, here is the output:

-r-------- 1 root root 5143 May 26 02:11 /usr/local/psa/admin/conf/httpsd.pem
 
For some reason you have non-Parallels default certificate. On my test server I see:

[root@ppu12-0 ~]# openssl s_client -connect 127.0.0.1:21 -starttls ftp
CONNECTED(00000003)
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify error:num=10:certificate has expired
notAfter=Sep 27 01:03:39 2012 GMT
verify return:1
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
notAfter=Sep 27 01:03:39 2012 GMT
verify return:1
---
Certificate chain
0 s:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
i:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
......
 
Sorry Igor,

Just changed it back to plesk for a moment to see if the issue was my current ssl. Just switched it back. You can test again. It is now the actual one being used.

Also, I am confused. How would you connect if you do not have my IP Address? I removed my IP Address and real domain name for privacy purposes. Do you need me to send you the exact information via private message?
 
Back
Top