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