Skip the PKI renewal process during engine-setup makes RHV host non-responsive

Solution Verified - Updated

Environment

Red Hat Virtualization (RHV) 4.3

Issue

  • During upgrade of RHVM, running engine-setup, I get this message:

    One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts.
              See https://access.redhat.com/solutions/1572983 for more details.
              Renew certificates? (Yes, No) [No]:
              Are you really sure that you want to skip the PKI renewal process?
              Please notice that recent openssl and gnutls upgrades can lead hosts refusing this CA cert making them unusable.
              If you choose "Yes", setup will continue and you will be asked again the next time you run this Setup. Otherwise, this process will abort and you will be expected to plan a proper upgrade according to https://access.redhat.com/solutions/1572983.
              Skip PKI renewal process? (Yes, No) [No]:
    
  • What should I select to avoid hosts becoming non-responsive?

Resolution

If the attached hosts are RHEL 7.6 and up, answer yes to to renew certificate during engine-setup.

If there are hosts in the system that are based RHEL 7.5 or earlier, hosts re-registration is required in order to refresh their CA after engine-setup, according to RHV: After upgrade to RHVH-4.2.7 (RHEL 7.6), libvirt fails to start.

Root Cause

In the time frame of RHV 4.2 and RHEL 7.6 a change in GNU utils and openssl was introduced to make RHV CA's NotBefore date encoding not compatible and required an update of all the hosts. For details, check this KCS and matching This content is not included.bugzilla#1648190.

Diagnostic Steps

If unsure and hosts are older version, it is possible to check hosts certificates using gnu-utils and decide, if host re-registration (note: only remove and add back, not reinstall) is needed or not. Use the certtool from gnu-utils to verify the CA on the manager and the hosts. Here is an example of such an output testing /etc/pki/vdsm/cacert.pem from one of the hosts in question:

$ certtool -e --infile cacert.pem.ok 
Loaded 1 certificates, 1 CAs and 0 CRLs

	Subject: C=US,O=rhvlab,CN=rhvm.rhvlab.83548
	Issuer: C=US,O=rhvlab,CN=rhvm.rhvlab.83548
	Checked against: C=US,O=rhvlab,CN=rhvm.rhvlab.83548
	Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

$ certtool -e --infile cacert.pem.broken 
error parsing CRTs: ASN1 parser: Error in DER parsing.

If there is an older certificate on one of the hosts, the hosts may go non-responsive after upgrade and would need to be re-registered after engine upgrade.

Category

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.