Resolved PPA_Agent not connecting

[ngrootjen]

Hi all,

This request for support is a wildshot, but I’ll give it a try.

Currently we still have an old environment that is based on Parallels Plesk Automation (PPA). We know this is outdated and working on migrating this.

Since last week we are having problems with the PPA agent because of an expired self-signed PPA certificate. I was hoping to solve this by just generating a new one, or even using our own *.hosting.nl wildcard certificate.

But this was unfortunate not the solution, in the PPA logs on the webserver node I find these errors;

2023-07-03 09:39:46 [AGENT][INFO]: Verifying client connection...
2023-07-03 09:39:46 [AGENT][ERROR]: Untrusted client connection
2023-07-03 09:39:46 [AGENT][ERROR]: [AGENT][SYSTEM ERROR]: Untrusted client connection

Although I’ve installed necessary certificates on management/webservice node so my best guess would be that somehow there is something else we are not thinking off that could help solve this problem.

With kind regards,

Nick Grootjen

 

[ngrootjen]

I have fixed this issue myself, in the end it was simple:

/usr/local/ppa/bin/ppa.agent_certmng –c –type mn –hostid <id> -force

/usr/local/ppa/bin/ppa.agent_certmng –c –type cn –hostid <id> -force

/usr/local/ppa/bin/ppa.agent_certmng –c –type ca –hostid <id> -force

 

[RalfMeyer]

Hi @ngrootjen,

Thank you for posting this, it saved me a lot of time today, trying to fix our legacy system

We had to do the following, which is a bit different from your commands:

We realized with

openssl x509 -in /opt/psa_agent/internal/rootchain.pem -text | grep 'Not After :'

on our service nodes that the Root CA certificate was at fault as it expired.

/usr/local/ppa/bin/ppa.agent_certmng -c -type mn -hostid <id> -force

(We chose a random service node for the ID, but I think hostid is ignored here anyway as this is only for the management node)

/usr/local/ppa/bin/ppa.agent_certmng -c -type ca -hostid <id> -force

(We chose a random service node for the ID, but I think hostid is ignored here anyway as this is only for the management node)

And then to rollout the certificates to the service nodes:

/usr/local/ppa/bin/ppa.agent_certmng -c -type sn -hostid <id> -install

for each service node id. Obviously, here the hostid is relevant.

Afterwards we could see on the service nodes with

openssl x509 -in /opt/psa_agent/internal/rootchain.pem -text | grep 'Not After :'

that the certificate was not expired anymore and the new Root CA certificate has been applied.

Your answer helped me a lot today, so thanks once more.

 

[ngrootjen]

Ah, that's great to hear I'm working on migrating our old PPA environment to new Plesk server(s). Working through this via Plesk migrator via cli (custom hosting) if you ever have some questions about that, let me know. Have a great day further on.

 

[evcilsehri]

Thank you so much for your fixed way.

 

[RalfMeyer]

@ngrootjen @evcilsehri

After we did this, we are now facing a new issue, where when a customer creates a new mailbox, the mailbox is not correctly set up on the mail service node. Only the domain directory as well as the name of the mailbox are created at /var/qmail/mailnames/<DOMAIN>/<NAME> but the directory only contains a .spamassassin folder and is missing the "@attachments" directory and the "Maildir" directory.

When we click on the mailbox on the management node after creating it, we receive an error due to the missing "@attachments" directory.

Since we have a test setup of PPA, where we did not change the certificate, we tried it there as described as well, and now the issue can be reproduced there, too.

Have you maybe faced this as well? Did you find a solution?

 

[RalfMeyer]

For affected customers it can be resolved by going to Change settings in the email tab (where you can enable the catch-all functionality) and just clicking "OK" without changing anything.

Affected broken email addresses have to be deleted before (they never worked anyways) and then recreated afterwards.

We were able to reliably reproduce that this is caused by the certificate change, no idea why this happens though.