Issue Server-wide backup invalidates SSL cert when deployed on back-up server

[PrimeSites]

Server operating system version

Ubuntu 22.04.3 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.56 Update #2

Hi Guys,

I have a 2-server set-up where the primary server's whole-server back-up is copied to the secondary server nightly, and a restoration triggered manually.

However, the restoration on the secondary server invalidates the SSL cert for Plesk access and requires logging via IP address to fix. Going into Tools & Settings > SSL/TLS Certificates > Certificate for securing Plesk > [Change], then just hitting OK with (already-selected) correct cert, fixes the problem and restores the cert.

I've attempted to re-apply the cert after the restoration has completed on the secondary server with cli, but it has no effect:

plesk bin certificate --assign-cert "Lets Encrypt (sweet-almeida)" -admin -ip [server-ip-address]

Could you perhaps suggest a way of automating the re-application of the correct/default Certificate for securing Plesk? This would enable me to append a command to restore the cert at the end of the back-up restoration script.

Alternatively, is it possible to exclude specific areas (hostname | default certificate) from the primary/source server back-up, which would avoid the secondary/target server's cert being invalidated?

Thanks

 

[Peter Debik]

The certificate is domain-validated. As the domain can only be reached on one server, how can the certificate be valid on another server?

 

[PrimeSites]

The certificate is domain-validated. As the domain can only be reached on one server, how can the certificate be valid on another server?

Hi Peter,
I should have been clearer. Each server has initially been set-up with its own certificate. E.g.
- Primary server has Lets Encrypt (primary-server) applied
- Secondary server has Lets Encrypt (sweet-almeida) applied

After restoration both the certificates are present on the secondary/target server as one might expect, but the Lets Encrypt (sweet-almeida) is still (seemingly) applied.
However It requires a manual save in Tools & Settings > SSL/TLS Certificates > Certificate for securing Plesk > [Change] to re-apply before the Plesk interface becomes accessible again.

I hope that clarifies but let me know if I'm missing something.

Thanks

 

[Peter Debik]

I still don't get the issue. If the server has a different hostname and you do a full restore to that server, it is expected that some configurations from the state before restoring won't match. They cannot match if it's a different host with a different name.

 

[PrimeSites]

I still don't get the issue. If the server has a different hostname and you do a full restore to that server, it is expected that some configurations from the state before restoring won't match. They cannot match if it's a different host with a different name.

Hi Peter,

I was hoping that there was perhaps way of automating the re-application of the correct/default certificate for securing Plesk on the secondary server. This would enable me to append a command to restore the cert at the end of the back-up restoration script.

I've attempted the below with no effect:
plesk bin certificate --assign-cert "Lets Encrypt (sweet-almeida)" -admin -ip [server-ip-address]

Alternatively, is it perhaps possible to exclude specific areas (hostname | default certificate) from the primary/source server back-up, which would avoid the secondary/target server's cert being invalidated?