cluster: use old and new fingerprint on master

when triggering a fingerprint update on master right after reloading
pmgproxy as we do for ACME certificates it can happen that the
connection is made against the old pmgproxy process (with the old
fingerprint). Simply trusting both fingerprints in that case seems
acceptable from a security perspective and makes the fingerprint
update more robust

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>

diff --git a/src/PMG/Cluster.pm b/src/PMG/Cluster.pm
index e7bf2660c39cb023be5f5f51be905cd61f1dd3d9..acaea8d28b5616cb690255039227b049e0d4b402 100644 (file)
--- a/src/PMG/Cluster.pm
+++ b/src/PMG/Cluster.pm
@@ -316,11 +316,13 @@ sub trigger_update_fingerprints {
     my ($cinfo) = @_;
 
     my $master = $cinfo->{master} || die "unable to lookup master node\n";
-    my $master_fp = $master->{fingerprint};
+    my $cached_fp = { $master->{fingerprint} => 1 };
 
     # if running on master the current fingerprint for the API-connection is needed
+    # in addition (to prevent races with restarting pmgproxy
     if ($cinfo->{local}->{type} eq 'master') {
-       $master_fp = PMG::Cluster::read_local_ssl_cert_fingerprint();
+       my $new_fp = PMG::Cluster::read_local_ssl_cert_fingerprint();
+       $cached_fp->{$new_fp} = 1;
     }
 
     my $ticket = PMG::Ticket::assemble_ticket('root@pam');
@@ -330,10 +332,8 @@ sub trigger_update_fingerprints {
        csrftoken => $csrftoken,
        cookie_name => 'PMGAuthCookie',
        host => $master->{ip},
-       cached_fingerprints => {
-           $master_fp => 1,
-       },
-    );
+       cached_fingerprints => $cached_fp,
+       );
 
     $conn->post("/config/cluster/update-fingerprints", {});
     return undef;