• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

FTPS not working after Plesk upgrade

I can only recommend to create a request to support team to do in-depth investigation to find the reason and to fix it. Please create a ticket to support at https://www.odin.com/support/request/ .
You may have free support, please check what kind of Plesk license you use for available support options at http://kb.odin.com/en/121580 .
If there’s no free support in your case, you can order Plesk per-incident support at http://www.odin.com/support/buy-support/ Support team will contact you as soon as purchase is processed, and they will do the best to resolve it.
If it is found that your problem was caused by product bug w/o available solution or workaround from Parallels, then your purchase will be re-funded.
 
It seems that this issue will linger because for some reason I have no support with my full unlimited license and will be required to submit a paid ($74.99) incident report, which is a bit ridiculous when this issue began to occur on its own to begin with. FTPS always worked fine until one day, after several auto-updates, It decided to no longer work.
 
Hi Xavier12,

which is a bit ridiculous when this issue began to occur on its own to begin with. FTPS always worked fine until one day, after several auto-updates, It decided to no longer work.

Igor stated quite clear:
If it is found that your problem was caused by product bug w/o available solution or workaround from Parallels, then your purchase will be re-funded.

Please note, that such a procedure is quite common all over the world, because often enough users declare something as a bug and want free support and often enough it is not at all a bug, but a users misconfiguration, which results in issues/failures/problems.
 
Hi Xavier12,



Igor stated quite clear:


Please note, that such a procedure is quite common all over the world, because often enough users declare something as a bug and want free support and often enough it is not at all a bug, but a users misconfiguration, which results in issues/failures/problems.


Hi UFHH01,

Thanks for the response. Lets track back, I am not and will not blame Igor at all. It isn't his fault.. I am expressing my concern about the process of the technical support a part from you guys.

In my case, there isn't a misconfiguration when firewall and everything else is disabled and absolutely nothing was altered since it worked. I am 100% sure of it. This same setup was done previously on another server that we ran and didn't have this issue.. So this has to be an issue with Plesk or an update itself, unless there is someone else that can chime in to say otherwise.
 
Here is what Proftpd website stated:

Question: My FTPS client has trouble connecting to proftpd using SSL/TLS, with the following error appearing in the TLSLog:

Sep 17 11:03:46 mod_tls/2.1.2[9628]: TLS/TLS-C requested, starting TLS handshake
Sep 17 11:03:46 mod_tls/2.1.2[9628]: unable to accept TLS connection: received EOF that violates protocol
Sep 17 11:03:46 mod_tls/2.1.2[9628]: TLS/TLS-C negotiation failed on control channel
Is this a bug in mod_tls, in the client, or something else?
Answer: There might be several different causes for this error. It could be a bug in the OpenSSL library, in mod_tls, in the FTPS client, or it could be a transient network issue.
Now, one possible thing to try is to use the following in your proftpd.conf file:

TLSOptions NoCertRequest

Transmit and the Fetch applications for the Mac; both state that they can handle FTP over SSL/TLS. Using both of these applications, the user saw the above error. The user, when using Transmit, saw the following error message appear from the client:

Server said:
AUTH TLS successful
error:00000000:lib(0):func(0):reason(0)

And when using Fetch, the error message displayed by that client was:

SSL Error -9844
Server responded: "AUTH TLS successful"

In both causes, using "TLSOptions NoCertRequest" appeared to make those clients happy.


This is the issue that we have going on and after following this procedure, the issue still persists.
 
SSL Error -9844

... indicates, that there might a certificate issue - but the error itself is not clearly defined, so there might be other reasons for the error.

At the moment, you stated only, that the users used MAC and you didn't make clear, if you tried as well FTP over SSL with another operating system - just to control, if the MAC ( and it's software ) might be the initial cause of your issue. Please comment out the additional setting "TLSOptions NoCertRequest", restart xinetd and try a windows system, or a linux system ( and a FTP software, able to use FTP over SSL for these OS ) for test purposes and report back with possible logs here in the thread.

Afterwards, please have a look at "http://fetchsoftworks.com/fetch/messageboard/ssl-error-9844#post-13857", to read the suggestions for further investigations with Fetch on a MAC when you experience issues with the error message "SSL Error -9844". You could investigate the log by yourself, mail it to the suggested eMail-adress from "Fetch", or open a conversation with IgorG or/and me and add the log - file there as attachment, for further investigations.
 
Thanks for reaching back UFHH01

So it seems the problem randomly began with the FTP app Transmit, but works fine with Cyberduck on mac and on Winscp on PC. It seems the tutorial here for Poodle patch isn't working for proftpd server when it comes to Transmit for Mac: http://kb.odin.com/en/123160

My settings for the file /etc/proftpd.d/60-nosslv3.conf are below and have worked before. Now it seems this issue is happening with Transmit for Mac

<Global>

<IfModule mod_tls.c>

TLSEngine on

TLSRequired off

TLSProtocol TLSv1 TLSv1.1 TLSv1.2
TLSCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:!SSLv3

</IfModule>

</Global>
Please advise, thanks.
 
Back
Top