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

 

[trialotto]

@tessa67

This quote

- 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).

does not add value for a Plesk forum member that encounters issues with verification (of SSL or hostnames), even though default value is "enabled" - it raises more questions that can only be answered by investigating the simple fact that Plesk uses its own implementations of packages.

This quote

The libcurl documentation explicitly warns: "disabling verification of the certificate allows bad guys to man-in-the-middle the communication without you knowing it".

is still true, even when hostname or certificate validation / verification is allowed : FTPS + libcurl (and certainly Plesk's implementation) are prone to MITM !


In general, both aforementioned quotes are barely relevant, since PMM-RAS (Plesk Migration Manager Repository Access Service - with emphasis on Plesk Migration Manager) work differently as they "appear" and the inner working of PMM-RAS also depends on what you use : Migration Manager Tool, Plesk Backup with full remote backups, Plesk Backup with incremental backup and so on.

It really is a mix-and-match between rsync and some other protocols. Do not ask me why, do not ask me whether I agree with this implementation.


This quote

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.

is entirely correct : Plesk simply adds it's own implementation of OpenSSL and uses that, with the big drawback that bugs are not being fixed at all or not in time.

Then, there is a problem when testing with OpenSSL commands from the command line : these commands DO use the packages that are installed with the OS, IF (and only if) specific packages (included with the OS) are kept on the server (and not deleted when the packages from Plesk are installed).

So, there might be a discrepancy in the results obtained from specific types of testing and the results one would like to see when testing Plesk.


This quote

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.

is not very relevant, since Plesk communicates with port 21 and then switches to passive ports - at least, it should do so, unless configured otherwise.

In my humble opinion, the "continue anyway" can safely be ignored and can be due to many factors (not limited to certificate related issues alone).


This quote

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.

is INTERESTING - if true, then a very very very old bug has re-entered the certificate generation process.

Again, not uncommon, certainly when companies (like Plesk) are inclined to create there own packages.

Nevertheless, not a severe bug.


This quote

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.

is creating false hope that Plesk will actually tackle this alleged issue via a support ticket.

This Plesk forum contains and/or supports reporting alleged bugs - these bug reports are dealt with fast and professionally.

Moreover, it is highly social and useful for other Plesk forum users to see the reported bug and the response of Plesk staff !


This quote

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.

is indeed an opinion.

The libcurl documentation is not a bible of truth, but simply a suggestion - just like my suggestion to improve security is.

To be honest, one should treat libcurl the same as PHP and its documentation likewise : there are many issues with these types of software that are not dealt with and not spoken off, even though some of these issues are severe bugs that exists for dozen of years (without any resolution).

So, yes, please have the opinion that it is a fact that certificate validation is the way to go.

And ignore the fact that certificates can be weak (and are certainly weak with X509-based certs and/or are certainly weak or problematic when using certs that are generated with buggy OpenSSL) and/or that certificates simply do not work in some cases (when the cert is wrongly generated).

Also ignore the fact that any weak or even any strong certificate cannot prevent MITM attacks.

The simple truth is that firewall rules can restrict access to (storage or backup) servers to a limited set of IPs that are, in advance, considered trustworthy.

The simple truth is also that, even with firewall rules in place, "trustworthy" is not enough : data transfer should be protected with certificates.

Consider this comparison : when driving a safe care like a Volvo, then that does not mean that you should drive 250 km per hour - at that speed, any accident will be deadly, irregardless of the safety of that Volvo brand.

Stated differently, secure everything, everywhere - if and only if meaningful and effective (and look for other solutions otherwise).

In this case, local backups are safer (and faster) and rsyncing them to a remote server is faster (and safer).

That way, there is no need for discussions about libcurl / OpenSSL / FTPS file transfers that can be intercepted ("hacked") by any script kiddy nowadays.


This "conclusion"

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.

can be - as in most cases with Plesk - simply be answered by assumptions that are close to truth, but that are also never (or hardly) verifiable (due to the fact that Plesk does not share source code by policy - quite odd, given the fact that most of the packages are effectively open source).

My educated guess with respect to the certificate is that Plesk uses the default certificate shipped with Plesk : it is a messy one, so that could explain a lot of the issues encountered.

If that educated guess is correct, than all should be resolved by installing a proper paid-for certificate : just buy one and test with that new certificate (and if none of the issues remain, then one can safely conclude that the default Plesk certificate is causing havoc).

Normally, I would not guess and simply spin up a Plesk test server, but I am restricted in the number of development licenses.

My educated guess with respect to the "continue anyway" notification is that it is a workaround from a far away past that was implemented in order to prevent that connections were not established (and hence backups were not made) in the good old days where there were a lot of Plesk related issues.

If that educated guess is correct, then one should acknowledge the fact that the workaround would already be removed by Plesk team if that is possible.


My bottom line is this.

@tessa67 .......... I like your style and your responses.

However, the problem is that you are knowledgeable and also give answers that often do redirect Plesk forum members to solutions that will not work or that will cause havoc in the near future, when Plesk decides to implement updates.

In my experience, it is not always the best idea to tackle one problem by providing general solutions that might not actually fit the root cause of the problem (and this root cause often differs across OSes and configurations of Plesk, especially those custom configs applied by individual Plesk users).

Nevertheless, keep doing the good and valuable work!

Kind regards....

 

[tessa67]

Hi @trialotto,

thanks for the detailed reply, and for the kind words. I like your style too, and I'm glad we can disagree on a few things without it getting ugly.

First, some things I think you got right:

• The point that the openssl command line can use different libraries than the ones Plesk ships is a good one. If pmm-ras really brings its own TLS stack, a successful test with the system's openssl doesn't tell us much about what pmm-ras does. That's exactly why I suggested checking which CA files it actually opens.
• Your warning that a general fix doesn't always fit the root cause is fair, and I agree it's worth keeping in mind. That's also why I only suggested read-only tests first.
• Local backups plus rsync is a solid setup, and server-side backup encryption is a good additional layer. I just see those as a different topic from the question Flachzange asked.

A few places where I see it a bit differently:

1. "Continuing anyway": you may well be right that it's an old workaround. But the log in #1 shows the verify result and right after it "SSL certificate verification failed, continuing anyway!". Whatever the reason is, the transfer went on without a verified server. That's why I'd rather find out what's behind it than ignore it.
2. The Plesk certificate: Flachzange wrote in #1 that his OpenSSL tests against the storage hostname validated chain and hostname successfully. So the certificate in question is the one the storage server presents, not the Plesk panel certificate, and I don't think a new cert on the Plesk side would change that.
3. I read your remark in #6 that "trustworthy" isn't enough and the transfer should be protected with certificates as very close to my point: encryption alone doesn't authenticate the server. So I think we're closer than it looks.

And a correction on my side: in #5 I wrote that the other user's test "confirms" an embedded implementation and called it "documented". That was too strong. A user in the Plesk forum suggests, based on readelf and the strings in the binary, that pmm-ras may embed libcurl. That's an observation, not official documentation. And that thread is about TLS session resumption in 18.0.80, not about certificate verification.

None of this settles which CA store pmm-ras uses, so the strace and s_client tests are still the next step. @Flachzange, if you run them, please post the filtered lines.

Regards
Tessa

 

[trialotto]

@tessa67,

As a general note, it is - in most cases - best to first ask the Plesk forum member about the OS, the Plesk version, custom config etc.

These questions avoid assumptions, educated guesses and certainly can provide clarity about the root cause of the problem (that often is the remarkable result of some odd or custom config implemented by the Plesk user).


I agree with

But the log in #1 shows the verify result and right after it "SSL certificate verification failed, continuing anyway!". Whatever the reason is, the transfer went on without a verified server. That's why I'd rather find out what's behind it than ignore it.

since it is quite interesting. Not only from a security perspective, but also from the perspective of "flawed design infrastructure".

Nevertheless, it is worthwhile to find out whether this is the endresult of kind-of-legacy FTPS (which exhibited identical or similar behavior in the past) and/or that another problem is present.

I think that you are mistaken with

Flachzange wrote in #1 that his OpenSSL tests against the storage hostname validated chain and hostname successfully. So the certificate in question is the one the storage server presents, not the Plesk panel certificate, and I don't think a new cert on the Plesk side would change that.

and for two reasons : (1) the hostname validation is an "independent process" and (2) server hostnames should be validated (which hostnames use the default server SSL certificates that can be either the Plesk cert, a LE cert or another cert installed) against their certs.

One should be able to test this by creating a specific remote (!!!) backup domain (or subdomain) of an existing domain that is not equal to the hostname.

By default, this specific backup domain (or subdomain) should use a LE cert (and not Plesk default cert), so you have a "partially clean testing environment".

That is, on the target server (and not on the local server).

If error notifications are not present anymore, then the root cause of the problem was a cert related issue on the target server.

If error notifications persist, then one could try to add a LE cert to the Plesk local server and retry again - if there are no error notifications after switching on the local server to the LE cert (from the Plesk default cert to any LE cert), then it is highly likely (but not certain) that the Plesk default cert is causing havoc.

If error notifications persist anyway (after doing the above), then there is - very likely - a mismatch between the hostname and the associated cert.

However, the aforementioned mismatch can have many causes ........ so eliminating some of these causes by assigning good LE certs is the first step to do.

This first step gives a clear indication WHERE to test and WHERE the problem originates (local server or target server or both).

In case one finds out that the problem originates on both the local and target server, then the issues are often related to buggy packages.

A strong indication thereof is the co-existence of identical packages on both the local and target server.


This statement

encryption alone doesn't authenticate the server. So I think we're closer than it looks.

is not entirely correct, but also not wrong.

The terms "authentication" or the verb "to authenticate" refers to a process (of connecting to a server that authenticates as valid).

The term "trustworthy" - as used by me - refers to a definition (a trustworthy server).

Authentication and trustworthy are not the same : even authenticated servers and/or server connections can be "untrusted".

Nevertheless, all of the above barely scratches the topic of "encryption", since this is a term that simply indicates the layer of security added to connections (between trusted or untrusted servers, it does not matter) and this added layer is always required : even if servers are trusted and/or authenticated, it still is the case that the server connection (between trusted/authenticated servers) requires protection (for instance, against MITM).


This remark

And a correction on my side: in #5 I wrote that the other user's test "confirms" an embedded implementation and called it "documented". That was too strong. A user in the Plesk forum suggests, based on readelf and the strings in the binary, that pmm-ras may embed libcurl. That's an observation, not official documentation.

is actually a complaint about failures in backup processes.

In essence, I quote this remark because it indicates that "very very old bugs" can re-enter the Plesk provided packages : the readelf bug is old !!!

However, again there is a symptom (backups not working properly and/or the readelf bug), but the root cause of the problem is entirely different.

If I am recalling it correctly, the readelf "bug" was more an issue than a bug : it could not deal properly with certs that were not properly defined in terms of time definitions (read: start and end date of the cert).

This was not a readelf bug but a (backwards) compatibility issue that was related to an OpenSSL bug that caused lack of (new) RFC compliance (concerning the start and end dates of the cert).

So, unless I am mistaken about the readelf "bug", this is a typical example of (a) old bugs can and will revive and (b) the root cause of the problem should be found (and symptoms are not the benchmark and/or the issue to resolve).

Nevertheless, it seems to be the case that the current symptoms (as reported by @Flachzange and as investigated by @tessa67) are very similar to the ones presented by the readelf "bug" : the error code 13 (issue with "notBefore field") are a strong indication !!


One should not make life complicated.

In general, in order to come to STR (Steps To Reproduce an issue), one should first eliminate some of the potential culprits.

In this case, if (and only if) the error notifications (reported by @Flachzange ) are related to (a) bad certs or (b) readelf or OpenSSL related bugs, then assigning "good certs" like those of LE should resolve any error notification.

If these "good certs" do, then you have an unbiased STR (that can be presented to Plesk as a bug report) and you will also have a VALID WORKAROUND.


Kind regards......