This behavior was introduced as a part of bz1158577.

Pcsd offers high available web UI for managing clusters. To use this feature, create a virtual IP (VIP) cluster resource and connect to it on pcsd port (2224 by default) using your web browser. If the node the VIP is running on goes down, the cluster automatically moves the VIP to another node so the pcsd web UI is still available on the same IP. In order to prevent web browsers from displaying warnings that SSL certificate changed for the IP address, pcsd synchronizes its certificates across cluster nodes. The synchronization happens when "pcs cluster setup", "pcs cluster node add" or "pcs pcsd sync-certificates" commands are executed. The certificate is synchronized amongst full stack nodes only (nodes running corosync), remote and guest nodes are never involved in the synchronization. Therefore the pcsd web UI VIP should be limited by constraints not to run on remote and guest nodes. (bz1158577)

The issue is that after the synchronization the CN matches one node only. Our preliminary plan to resolve this is to regenerate pcsd certificate during the synchronization and put names of all full stack nodes in it. There would also be an option in /etc/default/pcsd config file which would allow to 'disable', 'enable' or 'enable only for pcsd certificates (O and OU equals to pcsd)' this SSL certification regeneration.

Be aware, even if this is implemented, the pcsd generated certificates will still be self-signed. It is recommended for customers to create their own certificates signed by their internal or public CA trusted by their web browsers and configure pcsd to use them with "pcs pcsd certkey" command.

> Our preliminary plan to resolve this is to regenerate pcsd certificate
> during the synchronization and put names of all full stack nodes in it.

Note that pcs itself could possibly define it's own CA that one can
then one-off entrust (appears close to impossible with self-signed
certificates, see the reference in the linked bug) and there's then
no strict necessity to overload a single certificate this heavily;
just node's identification(s) + VIP(s), if any, per cert?
[bug 1671659]

Of course, this CA pair would need to be shared amongst the nodes for
the arrangement to be meaningfully dynamic going forward.

It's similar to what administrators should do when sticking with their
own CA + certificates, except there's no automatism like in the case of
adding VIP dedicated for pcs possible, so it's up for deliberation
what's the best trade-off incl. convenience for particular deployment.

(In reply to Tomas Jelinek from comment #5)
> Our preliminary plan to resolve this is to regenerate pcsd certificate
> during the synchronization and put names of all full stack nodes in it.
> There would also be an option in /etc/sysconfig/pcsd config file which would
> allow to 'disable', 'enable' or 'enable only for pcsd certificates (O and OU
> equals to pcsd)' this SSL certification regeneration.

If we implemented this, web browsers would complain each time the certificate changes. The whole point of synchronizing the certificates is to avoid such warnings. Therefore this is not a way to go.

Instead, we will provide a configuration option in /etc/sysconfig/pcsd to disable certificates synchronization completely. This will resolve the original issue of CN not matching hostname. It will be up to the users to set their own certificates if they are not happy with the default ones.

Created attachment 1548631 [details]
proposed fix

Test:
* certificate sync is enabled by default
* add PCSD_SSL_CERT_SYNC_ENABLED=false to /etc/sysconfig/pcsd
* check that 'pcs cluster setup' and 'pcs cluster node add' do not overwrite pcsd SSL certificate on target nodes
* remove, comment out or set PCSD_SSL_CERT_SYNC_ENABLED=true in /etc/sysconfig/pcsd
* check that in all cases 'pcs cluster setup' and 'pcs cluster node add' do overwrite pcsd SSL certificate on target nodes

After Fix:

[kid76 ~] $ rpm -q pcs
pcs-0.9.168-1.el7.x86_64

>Note time of /var/lib/pcsd/pcsd.crt in following tests:

> WITH DEFAULT SETTINGS

> cluster setup
[kid76 ~] $ ls -l /var/lib/pcsd/pcsd.crt
-rw-------. 1 root root 1179 Aug  5 08:45 /var/lib/pcsd/pcsd.crt
[kid76 ~] $ pcs cluster setup --name=zoo76 kid76 lion76
Destroying cluster on nodes: kid76, lion76...
kid76: Stopping Cluster (pacemaker)...
lion76: Stopping Cluster (pacemaker)...
lion76: Successfully destroyed cluster
kid76: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 'kid76', 'lion76'
kid76: successful distribution of the file 'pacemaker_remote authkey'
lion76: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
kid76: Succeeded
lion76: Succeeded

Synchronizing pcsd certificates on nodes kid76, lion76...
kid76: Success
lion76: Success
Restarting pcsd on the nodes in order to reload the certificates...
kid76: Success
lion76: Success
[kid76 ~] $ ls -l /var/lib/pcsd/pcsd.crt
-rw-------. 1 root root 1179 Aug  5 08:47 /var/lib/pcsd/pcsd.crt

> node add
[kid76 ~] $ ssh mule76 "ls -l /var/lib/pcsd/pcsd.crt"
-rw-------. 1 root root 1179 Aug  5 08:52 /var/lib/pcsd/pcsd.crt
[kid76 ~] $ pcs cluster node add mule76
Disabling SBD service...
mule76: sbd disabled
Sending remote node configuration files to 'mule76'
mule76: successful distribution of the file 'pacemaker_remote authkey'
kid76: Corosync updated
lion76: Corosync updated
Setting up corosync...
mule76: Succeeded
Synchronizing pcsd certificates on nodes mule76...
mule76: Success
Restarting pcsd on the nodes in order to reload the certificates...
mule76: Success
[kid76 ~] $ ssh mule76 "ls -l /var/lib/pcsd/pcsd.crt"
-rw-------. 1 root root 1179 Aug  5 08:54 /var/lib/pcsd/pcsd.crt

> WITH PCSD_SSL_CERT_SYNC_ENABLED=false IN /etc/sysconfig/pcsd

> cluster setup
[kid76 ~] $ ls -l /var/lib/pcsd/pcsd.crt
-rw-------. 1 root root 1179 Aug  5 08:47 /var/lib/pcsd/pcsd.crt
[kid76 ~] $ pcs cluster setup --name=zoo76 kid76 lion76
Destroying cluster on nodes: kid76, lion76...
kid76: Stopping Cluster (pacemaker)...
lion76: Stopping Cluster (pacemaker)...
lion76: Successfully destroyed cluster
kid76: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 'kid76', 'lion76'
kid76: successful distribution of the file 'pacemaker_remote authkey'
lion76: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
kid76: Succeeded
lion76: Succeeded
[kid76 ~] $ ls -l /var/lib/pcsd/pcsd.crt
-rw-------. 1 root root 1179 Aug  5 08:47 /var/lib/pcsd/pcsd.crt

> node add
[kid76 ~] $ ssh mule76 "ls -l /var/lib/pcsd/pcsd.crt"
-rw-------. 1 root root 1179 Aug  5 08:54 /var/lib/pcsd/pcsd.crt
[kid76 ~] $ pcs cluster node add mule76
Disabling SBD service...
mule76: sbd disabled
Sending remote node configuration files to 'mule76'
mule76: successful distribution of the file 'pacemaker_remote authkey'
kid76: Corosync updated
lion76: Corosync updated
Setting up corosync...
mule76: Succeeded
[kid76 ~] $ ssh mule76 "ls -l /var/lib/pcsd/pcsd.crt"
-rw-------. 1 root root 1179 Aug  5 08:54 /var/lib/pcsd/pcsd.crt

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0996