Question FTPS backup security: Does pmm-ras disable certificate validation by default?

[Flachzange]

Server operating system version

Ubuntu 24.04

Plesk version and microupdate number

18.0.82

Hello Plesk team,

while reviewing our backup logs, we noticed that pmm-ras reports the following during FTPS connections:

OpenSSL verify result: 13
SSL certificate verification failed, continuing anyway!

The operation nevertheless completes with exit code 0. This occurs both during backup operations and during a direct metadata retrieval using --get-ftp-dump-info. We did not supply any option to disable certificate verification.

The client reports curl 8.22.0. Its source code indicates that this message is emitted when peer certificate verification is disabled. Independent OpenSSL tests against the same storage hostname successfully validate both the certificate chain and hostname over IPv4 and IPv6.

Environment: Ubuntu 24.04, Plesk Obsidian 18.0.82. Installed plesk-backup-utilities package: 18.0-v.ubuntu.24.04+p18.0.82.1+t261027.1556.

Could you please clarify:

1. Does pmm-ras disable certificate chain verification by default for FTPS backups?
2. Is hostname verification enabled independently?
3. Is there a supported setting to enforce both checks and abort the transfer if validation fails?
4. If mandatory validation is currently unavailable, is a change planned?

Since backups contain sensitive data, I would expect FTPS connections to authenticate the remote server as well as encrypt the transfer. A clear explanation of the current behavior and supported configuration would be appreciated.

Thank you.

 

[tessa67]

Hi Flachzange,

nice catch! "Continuing anyway" is the TLS version of "this is fine" while the room is on fire. Quick disclaimer: I'm just another user, not Plesk staff, so below is what I can back up, and then what only Plesk can answer.

What I can back up

1. Your reading of the message matches curl's own output. In a public curl bug report (curl 8.17.0, run with -k), the verbose log shows "SSL Trust: peer verification disabled", then the verify result, then "SSL certificate verification failed, continuing anyway!". So that line does appear when peer verification is off. I only saw this for 8.17.0, not for your 8.22.0.

2. The "13" is most likely hex, not decimal. Other users' logs show "OpenSSL verify result: 14" right next to the same error as "(20)", so curl prints that number in hex. 0x13 is 19, and another curl log shows 19 as "self signed certificate in certificate chain". If you read 13 as decimal, you would go looking for the wrong problem.

3. As far as I know, error 19 means: OpenSSL could build a chain from the certificates the server sent, but the root at the end is not in the trust store it looked at. Together with your OpenSSL test passing, that points to "pmm-ras and your test don't use the same trust store", and not necessarily to a broken certificate. That is a pointer, not a conclusion.

4. If I read the log right, it says two things at once: peer verification is off, and with verification on, this check would currently fail. That's worth knowing before asking for enforcement, because switching it on without sorting out the trust store could break your backups.

Cheap read-only tests (nothing to change)

a) See what pmm-ras logged around the message:

grep -rn -B 20 "continuing anyway" /var/log/plesk/PMM/

Look for a line with "SSL Trust" and for the "certificate verify locations / CAfile / CApath" lines that curl prints before the handshake. If they are in your logs, they show which CA store pmm-ras uses and what it says about peer verification.

b) See which CA files pmm-ras actually opens (strace may need to be installed first):

strace -f -e trace=file -o /tmp/pmm-ras.strace <your pmm-ras command, exactly as before>
grep -E "ca-cert|ssl/certs|\.pem|\.crt" /tmp/pmm-ras.strace | sort -u

Please don't post the raw strace file, only the filtered lines.

c) See what the storage server sends:

openssl s_client -connect <storage-host>:21 -starttls ftp -servername <storage-host> -showcerts </dev/null

Check the "Certificate chain" part: does the server also send the root (a certificate where s: and i: are identical)? That would match error 19. For implicit FTPS on port 990, use -connect <storage-host>:990 and leave out -starttls ftp.

Your four questions

I can't answer them from the outside: whether this is by design, whether hostname verification is independent, whether a supported enforce option exists, and whether a change is planned. I'd put a ticket in with the pmm-ras package version, the log lines, the "13 is hex = 19" detail and the results of a) to c). For "is a change planned", features.plesk.com is the place for a request.

Please keep us posted!

Regards
Tessa

 

[tessa67]

Hi Flachzange,

a short addendum to my post above. I can't edit it anymore, and after thinking about it some more (and trying a few things on a test chain) I want to tighten two spots.

Replaces point 3

Error 19 means: the server sent a self-signed certificate at the end of its chain, and that certificate is not in the trust store the client used. I checked this with OpenSSL 3.0.13 on a test chain: if the server sends leaf + root and the client trusts only an unrelated root, you get 19. If the server sends only the leaf, you get 20 instead. With the root in the trust store you get 0. So my earlier wording ("the root is missing from the trust store") was too loose: 19 says the server did send a self-signed cert at the end.

Together with your OpenSSL test passing, that points to "pmm-ras and your test don't use the same trust store", and not necessarily to a broken certificate. That is still a pointer, not a conclusion.

Replaces test c)

openssl s_client -connect <storage-host>:21 -starttls ftp -servername <storage-host> -showcerts </dev/null

Check the "Certificate chain" part: does the server also send a self-signed root (a certificate where s: and i: are identical)? If yes, that matches error 19. If the chain ends with an intermediate, error 19 would be unexpected. For implicit FTPS on port 990, use -connect <storage-host>:990 and leave out -starttls ftp.

What I did not verify

- The "13 is hex" part still rests on other users' logs, where "OpenSSL verify result: 14" appears next to "(20)". The curl I tested with (8.5.0) still prints the older format in plain decimal, so I can't reproduce the hex output myself.
- I could not run the strace command from test b), so its syntax is untested on my side.
- Whether pmm-ras really uses a different trust store is still unconfirmed until someone runs test a) or b) on the server.

Sorry for the extra post, but I'd rather correct it than leave a half-right explanation standing.

Regards
Tessa

 

[trialotto]

@Flachzange

In order to answer your questions about FTPS on Plesk, one should first answer some general questions about FTPS in general.

In essence, FTPS should be read as "FTP first, then the S of security" : it is the FTP protocol first, afterwards projected on and ported to a kind-of-legacy SSL and/or TLS "secure" connection.

In a backup environment, a similar translation exists : "backup first, security second", implying that backup systems are designed to make the backup anyway, assuming (as part of the backup design infrastructure) that backups are more relevant than secure connections.

Combined together, this results in behavior that does not seem logical, but it is actually designed to be that way - it is expected behavior : backups and remote backups should not stop in the case of, for instance, bad code (of local or remote clients and of ssl related code) and invalidated ssl (expired or incompatible ssl).

Security of backups can only be obtained by server-side encryption (on the local, not the target server) : Plesk has that.

Security of backup transfer (!) can primarily be obtained by using passive ports (for FTPS) and secondarily by setting firewall rules : Plesk supports this.

And please note that the passive ports are also part of the backup design infrastructure : FTPS was deliberately designed with passive ports to increase speed and performance, but also to increase security of backup transfer - most people tend to forget the latter part.


Now, one can answer your questions in a more detailed way.

Does pmm-ras disable certificate chain verification by default for FTPS backups?

No, not really. FTPS does, but pmm-ras does not.

There is no simple way and/or it does not make sense to work around that : if already possible, it would result in a high number of failed remote backups.

Is hostname verification enabled independently?

To be honest, a wrong question.

One should not try to resolve hostnames : it is ineffective, not reliable and it does not make any sense.

When using remote backups, simply use a firewall rule on both the local and the target server that only allow connections between local and target server.

Is there a supported setting to enforce both checks and abort the transfer if validation fails?

If I am not mistaken, this setting can be allowed with a workaround, but one will end up with most backups not being made.

I would again advise to use appropriate firewall rules on both the local and target server.

If mandatory validation is currently unavailable, is a change planned?

Probably not.

In essence, Plesk allows for passive ports with FTPS and that is sufficient, when using passive ports with appropriate firewall rules and server-side encryption on the local server.


To conclude, please note the following.

In general, the FTP protocol and hence a huge part (but not all) of the FTPS protocol is "rock-solid-but-legacy".

The main issues with respect to code and security are often found in and/or related to OpenSSL.

As a result, trying to "secure FTPS on the SSL-side" is a bit like mission impossible, certainly when issues with OpenSSL are not resolved or bug fixed.

In general, certificate validation and hostname resolving are associated with performance penalties, certainly when using passive ports (as Plesk does).

Moreover, when OpenSSL issues are related to certificate validation issues, then certificate validation is not meaningful at all.

In addition, a secure FTP server setup is recommended to have settings that disallow hostname resolving to a high degree.

In short, focusing on hostnames and certificates is a bit problematic and not recommended at all.

One should really focus on secure FTP server setups (on the local and remote FTP server), with FTPS over passive ports and firewall rules in place.

The best way to secure FTPS is simply : allow one (trusted) connection, disallow all others.

And, finally, with respect to server-side encryption on the local server, please note that it is associated with performance penalties and some drawbacks (like backups that cannot be restored in some cases) : one should make life more easy!

I can only recommend to make full backups on the local server and create a script that uses rsync to transfer backups (highly securely) to a remote server (and remove old backups with a specific retention rate).

Why? Local server backups are the fastest (without drawbacks) and the rsync transfer gives you all backup transfer security that you need (and mostly cannot obtain with FTPS).


I hope the above helps.

Kind regards.....


PS Plesk backup process uses rsync and FTPS in a way that can be deemed to be okay. However, in my humble opinion, it is an odd approach. So, I will not discuss that here, since that would be rather off-topic in comparison to your questions.

In general, my post should be read as a post to give you "easy of mind" (trust the Plesk backup process) and to give you tips to increase the security of backup transfer (passive ports, firewall rules etc).

 

[tessa67]

Hi @Flachzange

I'll keep this strictly to what is directly documented and verifiable, because a lot of what's been claimed in this thread (including in post #4) goes beyond what the evidence supports.

What is 100% certain from official documentation
libcurl, the library pmm-ras appears to embed, treats certificate chain verification and hostname verification as two separate things:

- CURLOPT_SSL_VERIFYPEER verifies the certificate chain. Its documented default is 1 (enabled). When enabled and verification fails, "the connection fails".
- CURLOPT_SSL_VERIFYHOST verifies that the certificate matches the hostname you're connecting to. Its documented default is 2 (enabled, strict).
- The libcurl documentation explicitly warns: "disabling verification of the certificate allows bad guys to man-in-the-middle the communication without you knowing it".

So the claim in post #4 that hostname verification is "a wrong question" or "ineffective" has no basis in the actual behavior of the library pmm-ras is built on. Hostname verification is an independent, documented, default-on security control in libcurl.

What is documented specifically about pmm-ras
A controlled A/B test in the Plesk forum isolated an FTPS regression to the pmm-ras binary itself. The test showed:

- The system curl on the same Ubuntu server worked correctly with the same FTPS server.
- pmm-ras contains an embedded/static libcurl implementation, not a dynamic link to the system libcurl.
- Swapping only the pmm-ras binary between 18.0.79.5 and 18.0.80.x changed whether FTPS worked or failed, with no other configuration changes.

This confirms pmm-ras is not simply using the system's curl/OpenSSL stack. It carries its own implementation. That is relevant to your situation: the trust store or verification settings used by pmm-ras may differ from what your independent OpenSSL test used.

What is NOT proven (and I will not claim it)
I cannot prove from available documentation that pmm-ras disables verification by default, nor that it uses a specific different CA store. The "continuing anyway" message you saw is consistent with verification being disabled or non-fatal, but I have no official Plesk source confirming the exact code path.

I also cannot confirm what "result 13" means in the context of pmm-ras specifically. Public sources list OpenSSL result codes where 13 (decimal) is "format error in certificate's notBefore field", but whether pmm-ras prints hex or decimal is not documented. My hex theory (13 = 19 = self-signed in chain) is plausible but unverified for this specific binary.

What you can actually do with certainty
1. Check what CA bundle pmm-ras is using. Run your pmm-ras command with strace and filter for CA files:

strace -f -e trace=file -o /tmp/pmm.strace <your pmm-ras command>

grep -E "ca-cert|ssl/certs|\.pem|\.crt" /tmp/pmm.strace | sort -u

If it opens a different or empty CA path than your successful OpenSSL test, that explains the mismatch.

2. Verify what the server sends (My corrected test c):

openssl s_client -connect <storage-host>:21 -starttls ftp -servername <storage-host> -showcerts </dev/null

Check whether the server includes a self-signed root in the chain (s: and i: identical). If yes, result 19 (if hex) would fit. If the chain ends at an intermediate, result 19 would not fit.

3. Ask Plesk specifically: Does pmm-ras provide a supported option to (a) point at the system CA store, and (b) abort the transfer on verification failure instead of continuing? That is a question they can answer with documentation or a ticket.

On the firewall argument in post #4
Firewall rules and passive ports are useful defense in depth, but they do not perform certificate validation. A firewall rule controls which IPs can connect. It cannot verify that the server on the other end of an allowed connection is the server named in the certificate. The libcurl documentation is explicit that encryption alone without verification is insufficient because "you cannot be sure that you are communicating with the correct end-point". That is a documented fact, not an opinion.

Bottom line
The defaults of the library pmm-ras appears to embed are verification-on for both chain and hostname. The fact that you see "continuing anyway" means something in pmm-ras is overriding or bypassing those defaults. The A/B test evidence shows pmm-ras has its own embedded implementation. The next step is to find out which CA store that implementation actually uses, using the strace and openssl commands above, and then take that specific finding to Plesk.

Regards
Tessa