Certificate Renewal in OLVM (Oracle Linux Virtualization Manager)

Tested version: OLVM 4.4.10.7-1.0.18.el8
Recommended frequency: annual (certificates expire in ~395 days)
Critical prerequisite: full backup before any changes

Overview

OLVM uses its own internal PKI to authenticate communication between the Engine, hosts (VDSM/libvirt), the noVNC/SPICE console, OVN, and other components. All these certificates have limited validity and, when they expire, they cause silent connection failures — hosts appear as "Non-responsive", VM consoles seem down, and logs show TLS handshake errors.

This guide documents the complete renewal process, covering four fronts that do not happen automatically together:

Fronts 3 and 4 cover the same type of certificate (host/VDSM), but through different paths: front 3 is the manual host-to-host process; front 4 is the official Oracle script that automates this for one host, a cluster, or the entire environment at once. Use front 4 when you have multiple hosts or prefer the officially supported method.

Important: this procedure is for environments where certificates have already expired. If it is a preventive renewal, the flow is the same, but the risk of downtime during execution is much lower.

Before you begin

• Confirm whether the Engine is standalone or self-hosted.

  -

  • If self-hosted, enable maintenance mode first, according to Doc ID 3006292.1 (Oracle Support).

• Ensure root access via SSH or console.

• Have a maintenance window, as some services restart during the process.

• Have enough disk space for the backup (the engine-setup will also make an internal database backup).

Step 1 — Environment Backup

Always run the manual backup before starting, regardless of the backup that engine-setup offers to make:

engine-backup --scope=all --mode=backup \
  --file=/root/bkpcertificado.bck \
  --log=/root/bkpcertificado.log

This ensures a complete rollback point (configuration + database) in case something goes wrong.

Step 2 — Renewal via engine-setup

Start the process:

engine-setup --offline

The wizard will ask a series of questions. See how to answer each one:

At the end, engine-setup automatically restarts the Engine services (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) and displays a summary with access URLs and updated SSH fingerprint.

Note: this step renews most certificates, but not all. Some (OVN, vmconsole-proxy) are left out and need Step 4.

Step 3 — Checking what was renewed

List the validity of all Engine certificates:

cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
  echo "Certificate: $cert"
  openssl x509 -in "$cert" -noout -dates
  echo
done

Compare the notAfter dates — any certificate still with an old date (near or already expired) needs manual correction in the next step. Typically this affects:

• ovirt-provider-ovn.cer

• ovn-ndb.cer

• ovn-sdb.cer

• vmconsole-proxy-helper.cer

• vmconsole-proxy-user.cer

• vmconsole-proxy-host.cer

Step 4 — Fixing certificates not renewed

4.1 Find the correct subject

Use an existing valid certificate as a reference to keep the same subject pattern:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject

Example output:

subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local

4.2 Reissue the pending certificates

With the subject in hand, run the pki-enroll-pkcs12.sh script for each pending service:

cd /etc/pki/ovirt-engine/certs

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovirt-provider-ovn" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovn-ndb" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovn-sdb" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-helper" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-user" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-host" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

⚠️ Adjust --subject and --password for your environment. The subject must exactly reflect your OLVM domain/FQDN.

4.3 Restart affected services

systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service

Confirm that all started with systemctl status before proceeding.

Step 5 — VDSM certificate renewal

The VDSM certificate controls Engine ↔ Host communication and is also reused by SPICE/libvirt. Use the same subject identified in Step 4.1.

# 1. Generate the CSR from the existing key
mkdir /root/vdsm
cd /etc/pki/vdsm/keys/

openssl req -new -key vdsmkey.pem -out /root/vdsm/vdsm.csr \
  -passin "pass:mypass" -passout "pass:mypass" -batch -subj "/"

# 2. Sign the CSR with the oVirt internal CA, valid for 10 years
cd /etc/pki/ovirt-engine/

openssl ca -batch -policy policy_match -config openssl.conf \
  -cert ca.pem -keyfile private/ca.pem -days +3650 \
  -in /root/vdsm/vdsm.csr -out /root/vdsm/vdsm.cer \
  -startdate "$(date --utc --date "now -1 days" +"%y%m%d%H%M%SZ")" \
  -subj "/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" -utf8

# 3. Replace the VDSM certificate (keeping backup of the old one)
cd /etc/pki/vdsm/certs/
cp -a vdsmcert.pem vdsmcert.pem.old
cat /root/vdsm/vdsm.cer > vdsmcert.pem

# 4. Propagate the new certificate to SPICE and libvirt
cd /etc/pki/vdsm/libvirt-spice/
cp -a server-cert.pem server-cert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > server-cert.pem

cp -a /etc/pki/libvirt/clientcert.pem /etc/pki/libvirt/clientcert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > /etc/pki/libvirt/clientcert.pem

# 5. Restart host services
systemctl restart libvirtd vdsmd
systemctl status libvirtd vdsmd

Confirm the new validity:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates

The certificate should now expire 10 years in the future (-days +3650), instead of the standard 1-year period used by engine-setup.

Step 6 — Renewing Hypervisor certificates with the OlvmKvmCerts script

Oracle provides an official script, OlvmKvmCerts, which automates the checking and renewal of certificates on one or more Hypervisors (KVM hosts) directly from the Engine — without needing to manually repeat the steps of Step 5 on each host. It is documented in Oracle Support Doc ID 3008653.1.

When to use: environments with multiple hosts, or when the manual method (Step 5) has already been done on one host and you want to apply the same result to the others quickly and auditably.

When NOT to use as first option: the method recommended by Oracle itself remains to put the host in maintenance and use the "Enroll" option in the Admin Portal. The script is officially described as an "emergency measure" for when the certificate has already expired and preventive enrollment was not done in time.

Compatibility: tested by Oracle on OLVM 4.3, 4.4 and 4.5, on Oracle Linux 7.9 or higher.

⚠️ If the Engine also has expired certificates, renew them first (Steps 1–5 / Doc ID 3006292.1) before running this script.

6.1 Download and preparation

Download the latest version of the script (attached to Doc ID 3008653.1) and copy it to the Engine — the script only runs there, never directly on a Hypervisor.

chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts

6.2 Disable Cluster Fencing before running

In the OLVM Admin Portal, disable cluster fencing before running the script. The script itself disables/re-enables host power management during the process, but some hosts take time to report the correct status — active fencing during this interval can cause unwanted host restart.

6.3 Available commands

./OlvmKvmCerts

Usage: OlvmKvmCert [OPTION] 

status                    Displays the status of all certificates in the Engine
list-hosts                Lists all Hypervisors
renew-host          Renews certificates of a single Hypervisor
renew-cluster    Renews certificates of all Hypervisors in a Cluster
renew-all                 Renews certificates of all Hypervisors
check-host          Checks all certificates of a single Hypervisor
check-cluster    Checks all certificates of all Hypervisors in a Cluster
check-all                 Checks all certificates of all Hypervisors

6.4 Usage examples

Check the validity of all Engine certificates:

./OlvmKvmCerts status

engine.cer                      Dec 15 10:23:05 2028 GMT
jboss.cer                       Dec 15 10:23:06 2028 GMT
websocket-proxy.cer             Jan 16 10:23:06 2025 GMT
apache.cer                      Jan 16 10:23:06 2025 GMT
reports.cer                     Dec 15 10:23:06 2028 GMT
ovn-ndb.cer                     Dec 15 10:23:06 2028 GMT
ovn-sdb.cer                     Dec 15 10:23:07 2028 GMT
ovirt-provider-ovn.cer          Dec 15 10:23:07 2028 GMT
vmconsole-proxy-helper.cer      Dec 15 10:23:09 2028 GMT
vmconsole-proxy-user.cer        Dec 15 10:23:09 2028 GMT
vmconsole-proxy-host.cer        Dec 15 10:23:09 2028 GMT
hypervisor1.exemplo.local.cer       Mar  6 16:53:36 2029 GMT
hypervisor2.exemplo.local.cer       Mar  6 16:56:38 2029 GMT

List all managed hosts:

./OlvmKvmCerts list-hosts

name        | host                   | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default

Check (without changing) the certificates of a specific host:

./OlvmKvmCerts check-host hypervisor1.exemplo.local

The script validates, host by host: connectivity, VDSM certificate and private key, libvirt-migrate, libvirt-spice, libvirt-vnc and OVN — confirming each item with [PASS] or pointing out failure.

Renew certificates for a host:

./OlvmKvmCerts renew-host hypervisor2.exemplo.local

The script executes, in this order, for the specified host:

2. Local backup of current certificates

4. Generation of new key/CSR and signing by the Engine CA (VDSM, libvirt, libvirt-spice, libvirt-vnc)

6. Copy the new certificates to the host

8. Same process for the OVN certificate

10. Generation of the libvirt-migrate certificate (when applicable to the OLVM version)

12. Disables host power management, restarts affected services, waits for the host to return to "Available" and re-enables power management

6.5 Post-execution

• In the Admin Portal, re-enable Cluster Fencing if you disabled it in step 6.2.

• The script stores a temporary backup of previous certificates in /var/tmp on each host — useful for manual rollback if something goes wrong (just extract, copy the files back to the original paths and restart services).

• Even after successful script renewal, it is recommended to later schedule maintenance and do the "Enroll" of the host via the Admin Portal — the script is an emergency fix, it does not replace the official long-term flow.

Script correction history (for reference)

If, after renewal, the noVNC console shows "Something went wrong, connection is closed" and /var/log/messages shows an encryption error, adjust the Apache key permissions and force websocket-proxy to use the correct certificate:

chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass

cp -a /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf \
      /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf

vim /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf

Add (or confirm) the lines in the 99-setup.conf file:

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

Restart the service:

systemctl restart ovirt-websocket-proxy.service

If it still doesn't work: import the CA as intermediate in the browser

2. Access, replacing with your OLVM FQDN:

    https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

4. Rename the downloaded file to .pem extension.

6. In the browser (e.g., Chrome), import this .pem in:
   Settings → Privacy and security → Manage certificates → Intermediate Certification Authorities → Import

This resolves cases where the browser still distrusts the new certificate chain even with correctly configured services.

Final checklist

• Backup engine-backup performed and stored off the server

• engine-setup --offline completed without errors

• All .cer in /etc/pki/ovirt-engine/certs/ with updated notAfter

• OVN and vmconsole-proxy certificates reissued manually (if necessary)

• VDSM certificate renewed and propagated to SPICE/libvirt

• (Alternative) Cluster Fencing disabled before running OlvmKvmCerts

• (Alternative) OlvmKvmCerts check-all or status confirming updated validity on all hosts

• (Alternative) Cluster Fencing re-enabled after the script

• (Alternative) Hosts re-enrolled via Admin Portal after using the script (good post-emergency practice)

• Services ovirt-provider-ovn, ovn-northd, ovirt-vmconsole-proxy-sshd, libvirtd, vdsmd active

• noVNC console tested and functional

• Host validated as "Up" in the OLVM panel

References

• Eclipsys — OLVM Renew Engine and KVM Certificate

• Oracle Support — Doc ID 3006292.1 (maintenance mode in self-hosted environment)

• Oracle Support — Doc ID 2960024.1 (update of certificates not renewed by engine-setup)

• Oracle Support — Doc ID 2922244.1 (import of intermediate CA in the browser)

• Oracle Support — Doc ID 3008653.1 (script OlvmKvmCerts — checking and renewal of Hypervisor certificates)

Internal procedure document from Nyverra Tecnologia, based on Infrastructure Support process, restructured into technical article format.

Overview

OLVM uses its own internal PKI to authenticate communication between the Engine, hosts (VDSM/libvirt), the noVNC/SPICE console, OVN, and other components. All these certificates have limited validity and, when they expire, they cause silent connection failures — hosts appear as "Non-responsive", VM consoles seem down, and logs show TLS handshake errors.

This guide documents the complete renewal process, covering four fronts that do not happen automatically together:

Fronts 3 and 4 cover the same type of certificate (host/VDSM), but through different paths: front 3 is the manual host-to-host process; front 4 is the official Oracle script that automates this for one host, a cluster, or the entire environment at once. Use front 4 when you have multiple hosts or prefer the officially supported method.

Important: this procedure is for environments where certificates have already expired. If it is a preventive renewal, the flow is the same, but the risk of downtime during execution is much lower.

Before you begin

• Confirm whether the Engine is standalone or self-hosted.

  • If self-hosted, enable maintenance mode first, according to Doc ID 3006292.1 (Oracle Support).

• Ensure root access via SSH or console.

• Have a maintenance window, as some services restart during the process.

• Have enough disk space for the backup (the engine-setup will also make an internal database backup).

Step 1 — Environment Backup

Always run the manual backup before starting, regardless of the backup that engine-setup offers to make:

engine-backup --scope=all --mode=backup \
  --file=/root/bkpcertificado.bck \
  --log=/root/bkpcertificado.log

This ensures a complete rollback point (configuration + database) in case something goes wrong.

Step 2 — Renewal via engine-setup

Start the process:

engine-setup --offline

The wizard will ask a series of questions. See how to answer each one:

At the end, engine-setup automatically restarts the Engine services (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) and displays a summary with access URLs and updated SSH fingerprint.

Note: this step renews most certificates, but not all. Some (OVN, vmconsole-proxy) are left out and need Step 4.

Step 3 — Checking what was renewed

List the validity of all Engine certificates:

cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
  echo "Certificate: $cert"
  openssl x509 -in "$cert" -noout -dates
  echo
done

Compare the notAfter dates — any certificate still with an old date (near or already expired) needs manual correction in the next step. Typically this affects:

• ovirt-provider-ovn.cer

• ovn-ndb.cer

• ovn-sdb.cer

• vmconsole-proxy-helper.cer

• vmconsole-proxy-user.cer

• vmconsole-proxy-host.cer

Step 4 — Fixing certificates not renewed

4.1 Find the correct subject

Use an existing valid certificate as a reference to keep the same subject pattern:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject

Example output:

subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local

4.2 Reissue the pending certificates

With the subject in hand, run the pki-enroll-pkcs12.sh script for each pending service:

cd /etc/pki/ovirt-engine/certs

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovirt-provider-ovn" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovn-ndb" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="ovn-sdb" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-helper" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-user" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
  --name="vmconsole-proxy-host" --password=mypass \
  --subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key

⚠️ Adjust --subject and --password for your environment. The subject must exactly reflect your OLVM domain/FQDN.

4.3 Restart affected services

systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service

Confirm that all started with systemctl status before proceeding.

Step 5 — VDSM certificate renewal

The VDSM certificate controls Engine ↔ Host communication and is also reused by SPICE/libvirt. Use the same subject identified in Step 4.1.

# 1. Generate the CSR from the existing key
mkdir /root/vdsm
cd /etc/pki/vdsm/keys/

openssl req -new -key vdsmkey.pem -out /root/vdsm/vdsm.csr \
  -passin "pass:mypass" -passout "pass:mypass" -batch -subj "/"

# 2. Sign the CSR with the oVirt internal CA, valid for 10 years
cd /etc/pki/ovirt-engine/

openssl ca -batch -policy policy_match -config openssl.conf \
  -cert ca.pem -keyfile private/ca.pem -days +3650 \
  -in /root/vdsm/vdsm.csr -out /root/vdsm/vdsm.cer \
  -startdate "$(date --utc --date "now -1 days" +"%y%m%d%H%M%SZ")" \
  -subj "/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" -utf8

# 3. Replace the VDSM certificate (keeping backup of the old one)
cd /etc/pki/vdsm/certs/
cp -a vdsmcert.pem vdsmcert.pem.old
cat /root/vdsm/vdsm.cer > vdsmcert.pem

# 4. Propagate the new certificate to SPICE and libvirt
cd /etc/pki/vdsm/libvirt-spice/
cp -a server-cert.pem server-cert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > server-cert.pem

cp -a /etc/pki/libvirt/clientcert.pem /etc/pki/libvirt/clientcert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > /etc/pki/libvirt/clientcert.pem

# 5. Restart host services
systemctl restart libvirtd vdsmd
systemctl status libvirtd vdsmd

Confirm the new validity:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates

The certificate should now expire 10 years in the future (-days +3650), instead of the standard 1-year period used by engine-setup.

Step 6 — Renewing Hypervisor certificates with the OlvmKvmCerts script

Oracle provides an official script, OlvmKvmCerts, which automates the checking and renewal of certificates on one or more Hypervisors (KVM hosts) directly from the Engine — without needing to manually repeat the steps of Step 5 on each host. It is documented in Oracle Support Doc ID 3008653.1.

When to use: environments with multiple hosts, or when the manual method (Step 5) has already been done on one host and you want to apply the same result to the others quickly and auditably.

When NOT to use as first option: the method recommended by Oracle itself remains to put the host in maintenance and use the "Enroll" option in the Admin Portal. The script is officially described as an "emergency measure" for when the certificate has already expired and preventive enrollment was not done in time.

Compatibility: tested by Oracle on OLVM 4.3, 4.4 and 4.5, on Oracle Linux 7.9 or higher.

⚠️ If the Engine also has expired certificates, renew them first (Steps 1–5 / Doc ID 3006292.1) before running this script.

6.1 Download and preparation

Download the latest version of the script (attached to Doc ID 3008653.1) and copy it to the Engine — the script only runs there, never directly on a Hypervisor.

chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts

6.2 Disable Cluster Fencing before running

In the OLVM Admin Portal, disable cluster fencing before running the script. The script itself disables/re-enables host power management during the process, but some hosts take time to report the correct status — active fencing during this interval can cause unwanted host restart.

6.3 Available commands

./OlvmKvmCerts

Usage: OlvmKvmCert [OPTION] 

status                    Displays the status of all certificates in the Engine
list-hosts                Lists all Hypervisors
renew-host          Renews certificates of a single Hypervisor
renew-cluster    Renews certificates of all Hypervisors in a Cluster
renew-all                 Renews certificates of all Hypervisors
check-host          Checks all certificates of a single Hypervisor
check-cluster    Checks all certificates of all Hypervisors in a Cluster
check-all                 Checks all certificates of all Hypervisors

6.4 Usage examples

Check the validity of all Engine certificates:

./OlvmKvmCerts status

engine.cer                      Dec 15 10:23:05 2028 GMT
jboss.cer                       Dec 15 10:23:06 2028 GMT
websocket-proxy.cer             Jan 16 10:23:06 2025 GMT
apache.cer                      Jan 16 10:23:06 2025 GMT
reports.cer                     Dec 15 10:23:06 2028 GMT
ovn-ndb.cer                     Dec 15 10:23:06 2028 GMT
ovn-sdb.cer                     Dec 15 10:23:07 2028 GMT
ovirt-provider-ovn.cer          Dec 15 10:23:07 2028 GMT
vmconsole-proxy-helper.cer      Dec 15 10:23:09 2028 GMT
vmconsole-proxy-user.cer        Dec 15 10:23:09 2028 GMT
vmconsole-proxy-host.cer        Dec 15 10:23:09 2028 GMT
hypervisor1.exemplo.local.cer       Mar  6 16:53:36 2029 GMT
hypervisor2.exemplo.local.cer       Mar  6 16:56:38 2029 GMT

List all managed hosts:

./OlvmKvmCerts list-hosts

name        | host                   | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default

Check (without changing) the certificates of a specific host:

./OlvmKvmCerts check-host hypervisor1.exemplo.local

The script validates, host by host: connectivity, VDSM certificate and private key, libvirt-migrate, libvirt-spice, libvirt-vnc and OVN — confirming each item with [PASS] or pointing out failure.

Renew certificates for a host:

./OlvmKvmCerts renew-host hypervisor2.exemplo.local

The script executes, in this order, for the specified host:

1. Local backup of current certificates

2. Generation of new key/CSR and signing by the Engine CA (VDSM, libvirt, libvirt-spice, libvirt-vnc)

3. Copy the new certificates to the host

4. Same process for the OVN certificate

5. Generation of the libvirt-migrate certificate (when applicable to the OLVM version)

6. Disables host power management, restarts affected services, waits for the host to return to "Available" and re-enables power management

6.5 Post-execution

• In the Admin Portal, re-enable Cluster Fencing if you disabled it in step 6.2.

• The script stores a temporary backup of previous certificates in /var/tmp on each host — useful for manual rollback if something goes wrong (just extract, copy the files back to the original paths and restart services).

• Even after successful script renewal, it is recommended to later schedule maintenance and do the "Enroll" of the host via the Admin Portal — the script is an emergency fix, it does not replace the official long-term flow.

Script correction history (for reference)

If, after renewal, the noVNC console shows "Something went wrong, connection is closed" and /var/log/messages shows an encryption error, adjust the Apache key permissions and force websocket-proxy to use the correct certificate:

chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass

cp -a /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf \
      /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf

vim /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf

Add (or confirm) the lines in the 99-setup.conf file:

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

Restart the service:

systemctl restart ovirt-websocket-proxy.service

If it still doesn't work: import the CA as intermediate in the browser

1. Access, replacing with your OLVM FQDN:

    https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

2. Rename the downloaded file to .pem extension.

3. In the browser (e.g., Chrome), import this .pem in:
   Settings → Privacy and security → Manage certificates → Intermediate Certification Authorities → Import

This resolves cases where the browser still distrusts the new certificate chain even with correctly configured services.

Final checklist

• Backup engine-backup performed and stored off the server

• engine-setup --offline completed without errors

• All .cer in /etc/pki/ovirt-engine/certs/ with updated notAfter

• OVN and vmconsole-proxy certificates reissued manually (if necessary)

• VDSM certificate renewed and propagated to SPICE/libvirt

• (Alternative) Cluster Fencing disabled before running OlvmKvmCerts

• (Alternative) OlvmKvmCerts check-all or status confirming updated validity on all hosts

• (Alternative) Cluster Fencing re-enabled after the script

• (Alternative) Hosts re-enrolled via Admin Portal after using the script (good post-emergency practice)

• Services ovirt-provider-ovn, ovn-northd, ovirt-vmconsole-proxy-sshd, libvirtd, vdsmd active

• noVNC console tested and functional

• Host validated as "Up" in the OLVM panel

References

• Eclipsys — OLVM Renew Engine and KVM Certificate

• Oracle Support — Doc ID 3006292.1 (maintenance mode in self-hosted environment)

• Oracle Support — Doc ID 2960024.1 (update of certificates not renewed by engine-setup)

• Oracle Support — Doc ID 2922244.1 (import of intermediate CA in the browser)

• Oracle Support — Doc ID 3008653.1 (script OlvmKvmCerts — checking and renewal of Hypervisor certificates)

Internal procedure document from Nyverra Tecnologia, based on Infrastructure Support process, restructured into technical article format.