If an oVirt environment suddenly stops allowing access to the Administration Portal and displays an error similar to:

PKIX path validation failed:
java.security.cert.CertPathValidatorException:
validity check failed

one of the first things to investigate is the oVirt PKI certificate infrastructure.

This problem can appear unexpectedly even when the virtualization host, Hosted Engine virtual machine, storage, and other services seem to be running normally.

A particularly common cause is an expired Apache HTTPS certificate on the oVirt Engine.

This guide explains how to diagnose the problem, determine exactly which certificate has expired, safely renew certificates in a Self-Hosted/Hosted Engine environment, and troubleshoot a second problem that can appear when engine-setup attempts to access obsolete or unreachable software repositories.

What Does “PKIX Path Validation Failed” Mean?

PKIX stands for Public Key Infrastructure X.509.

Java applications use certificate path validation to determine whether an SSL/TLS certificate can be trusted. During validation, Java checks several properties, including:

• whether the certificate is signed by a trusted certificate authority;
• whether the certificate chain is valid;
• whether the certificate is currently valid;
• whether it has expired;
• whether it is not yet valid.

Therefore, an error containing:

CertPathValidatorException: validity check failed

does not automatically mean that the entire oVirt CA infrastructure is broken.

It may simply mean that one certificate in the chain has expired.

Understanding Certificates in oVirt

oVirt maintains its PKI infrastructure under:

/etc/pki/ovirt-engine/

Important certificates include the Engine CA, Engine certificate, and Apache certificate. The Apache certificate is the certificate exposed by the Engine’s HTTPS service.

For example:

/etc/pki/ovirt-engine/ca.pem
/etc/pki/ovirt-engine/certs/apache.cer
/etc/pki/ovirt-engine/certs/engine.cer

These certificates do not necessarily expire at the same time.

That distinction is extremely important when troubleshooting.

Step 1: Check the System Clock First

Before replacing anything, verify the date and time on the Engine VM:

timedatectl

Check that:

• the date is correct;
• the time is correct;
• the timezone is reasonable;
• NTP synchronization is functioning.

A certificate can appear invalid if the machine’s clock is significantly incorrect.

If the clock is correct, continue with certificate inspection.

Step 2: Check the Apache Certificate

Run this command on the Hosted Engine VM, not on the physical virtualization host:

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/apache.cer \
  -noout -dates

Typical output:

notBefore=Aug 12 10:47:08 2024 GMT
notAfter=Sep 15 10:47:08 2025 GMT

The important field is:

notAfter

If the current date is later than this date, the certificate has expired.

You can also display additional information:

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/apache.cer \
  -noout -subject -issuer -dates

Step 3: Check the Engine Certificate

Next inspect the Engine certificate:

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/engine.cer \
  -noout -dates

Depending on the oVirt installation, certificate filenames can differ. If necessary, inspect the available certificates:

ls -lah /etc/pki/ovirt-engine/certs/

An Engine certificate might, for example, report:

notBefore=Jul 5 04:51:44 2023 GMT
notAfter=Jul 6 04:51:44 2028 GMT

In this example, the Engine certificate itself is still valid.

Step 4: Check the oVirt CA

Now check the internal CA:

openssl x509 \
  -in /etc/pki/ovirt-engine/ca.pem \
  -noout -dates

For example:

notBefore=Jul 5 04:51:44 2023 GMT
notAfter=Jul 1 04:51:44 2043 GMT

The CA is therefore still valid.

This produces an important diagnosis:

In this situation, do not regenerate the CA simply because the web certificate expired.

Changing the CA unnecessarily can create considerably more work because hosts and other components trust the existing CA.

Why Can the Apache Certificate Expire Much Earlier?

This is normal in newer oVirt releases.

oVirt documentation notes that certificates exposed to browsers have shorter lifetimes. In oVirt versions before 4.5, certificates generally followed a 398-day lifetime; newer versions extend some internal certificates while browser-facing certificates continue to require more frequent renewal.

This explains a situation where:

CA expires:      2043
Engine expires:  2028
Apache expires:  2025

The different dates do not necessarily indicate corruption.

Step 5: Back Up the Engine Before Changing PKI

Before making certificate changes, create an Engine backup.

The correct utility on many oVirt installations is:

engine-backup

not:

ovirt-engine-backup

A full backup can be created with:

engine-backup \
  --mode=backup \
  --file=/root/engine-backup-$(date +%F).tgz \
  --log=/root/engine-backup-$(date +%F).log

oVirt documents engine-backup as the standard utility for backing up Engine databases and configuration files.

Verify the resulting files:

ls -lh /root/engine-backup*

For an important production installation, copy the backup to another machine before continuing.

Special Consideration for a Self-Hosted Engine

In a Hosted Engine deployment, the oVirt Engine itself runs as a virtual machine managed by the environment.

Certificate maintenance should therefore be treated carefully.

The documented renewal procedure recommends putting the Self-Hosted Engine environment into global maintenance mode before renewing Engine certificates.

Run this on the physical oVirt host:

hosted-engine --set-maintenance --mode=global

Check its state:

hosted-engine --vm-status

Global maintenance prevents the Hosted Engine HA mechanism from interfering while maintenance is being performed on the Engine VM.

Step 6: Renew Certificates Using engine-setup

Older and newer oVirt releases do not necessarily support the same command-line switches.

For example, this command may fail:

engine-setup --reconfigure-ssl

with:

FATAL: Invalid option '--reconfigure-ssl'

That does not mean engine-setup is broken.

Instead, use the renewal method supported by the installed version.

Current oVirt documentation recommends:

engine-setup --offline

for Engine certificate renewal, followed by accepting the certificate renewal prompt.

The setup process should eventually ask something similar to:

Renew certificates? (Yes, No) [Yes]:

Answer:

Yes

oVirt’s PKI renewal mechanism specifically checks certificates approaching or past expiration and can prompt to renew them.

What If Plain engine-setup Fails Before Asking About Certificates?

A common complication is that running:

engine-setup

may trigger a DNF repository metadata refresh.

You may then receive an apparently unrelated error such as:

Failed to download metadata for repo 'centos-ceph-pacific'

or:

Curl error (6): Couldn't resolve host name

For example:

Could not resolve host: mirrorlist.centos.org

The setup process then exits during:

Stage: Environment setup

This means certificate renewal has not actually started yet.

The immediate problem is repository or DNS access.

Why Does Certificate Renewal Care About DNF?

engine-setup does considerably more than generate certificates.

During its environment initialization it may interact with the system package infrastructure. Consequently, a broken repository can prevent setup from progressing far enough to reach the PKI renewal stage.

This can be confusing because the administrator starts with:

PKIX path validation failed

but then encounters:

Failed to download metadata

These are two separate problems:

Expired HTTPS certificate
        ↓
Need engine-setup
        ↓
engine-setup checks environment
        ↓
DNF accesses repositories
        ↓
Repository/DNS failure
        ↓
engine-setup terminates

The original certificate problem still exists.

Step 7: Try Offline Certificate Renewal

For supported versions, use:

engine-setup --offline

This is particularly appropriate when the goal is certificate renewal rather than package updates.

The official oVirt administration documentation specifically uses engine-setup --offline in its Engine certificate renewal procedure.

If the installed version does not recognize --offline, check available options:

engine-setup --help

Do not blindly use command-line switches copied from a different oVirt release.

Step 8: Investigate Repository Failures

If setup still requires repository access, first inspect the enabled repositories:

dnf repolist --enabled

Then test DNS:

getent hosts mirrorlist.centos.org

You can also test general name resolution:

getent hosts example.com

Check the resolver configuration:

cat /etc/resolv.conf

And test basic connectivity:

ping -c 3 1.1.1.1

If IP connectivity works but DNS lookups fail, investigate DNS configuration rather than changing oVirt.

Temporarily Disabling a Broken Repository

If one obsolete or inaccessible repository is blocking setup and that repository is not required for the certificate operation, it can be temporarily disabled.

First identify it:

dnf repolist --enabled

If dnf config-manager is available:

dnf config-manager --set-disabled <repository-id>

For example:

dnf config-manager --set-disabled centos-ceph-pacific

Then retry:

engine-setup

After maintenance, restore the repository configuration if appropriate:

dnf config-manager --set-enabled <repository-id>

Be careful here: disabling repositories should not become a substitute for maintaining a supported operating system and valid repository configuration.

Step 9: Verify the New Certificate

After successful renewal, inspect the Apache certificate again:

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/apache.cer \
  -noout -subject -issuer -dates

The notAfter value should now be in the future.

Also check the services:

systemctl status ovirt-engine

and:

systemctl status httpd

If necessary:

systemctl restart ovirt-engine
systemctl restart httpd

Then test HTTPS:

curl -vk https://localhost/ovirt-engine/

Finally, open the Administration Portal using the Engine’s normal FQDN.

Step 10: Disable Global Maintenance

If you enabled global maintenance before performing the renewal, return to the physical host and disable it:

hosted-engine --set-maintenance --mode=none

Verify:

hosted-engine --vm-status

This is an important final step in a Self-Hosted Engine deployment. The official certificate renewal procedure similarly enables global maintenance before Engine renewal and disables it afterward.

Do You Need to Reinstall the oVirt Host?

Usually no, if only the browser-facing Apache certificate was renewed and the existing internal CA remains unchanged.

That is why checking:

/etc/pki/ovirt-engine/ca.pem

before making changes is so important.

Replacing or regenerating the CA is a much larger operation than renewing an expired leaf certificate.

Avoid replacing a valid CA unless you have determined that the CA itself must be replaced.

Useful Diagnostic Commands

A compact troubleshooting sequence is:

timedatectl

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/apache.cer \
  -noout -subject -issuer -dates

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/engine.cer \
  -noout -subject -issuer -dates

openssl x509 \
  -in /etc/pki/ovirt-engine/ca.pem \
  -noout -subject -issuer -dates

Check Engine:

systemctl status ovirt-engine
systemctl status httpd

Check repositories:

dnf repolist --enabled

Check DNS:

getent hosts mirrorlist.centos.org

Check setup capabilities:

engine-setup --help

And, when supported, renew certificates with:

engine-setup --offline

Common Mistakes to Avoid

1. Regenerating the CA immediately

An expired Apache certificate does not imply an expired CA.

Check each certificate separately before making changes.

2. Running Hosted Engine commands on the Engine VM

Commands such as:

hosted-engine --set-maintenance --mode=global

belong on the virtualization host, while:

engine-setup

belongs on the Engine VM.

3. Assuming every oVirt version supports the same flags

A command such as:

engine-setup --reconfigure-ssl

may simply not exist on your installed release.

Use:

engine-setup --help

and consult documentation appropriate to your version.

4. Ignoring repository errors

If engine-setup terminates during environment initialization, certificate renewal has not occurred.

Resolve or bypass the repository problem appropriately before expecting the certificate to change.

5. Performing PKI changes without a backup

Certificate infrastructure is tightly integrated with Engine configuration and host trust.

Create an Engine backup before modifying it.

Preventing the Problem in the Future

The best solution is not to allow certificates to expire.

oVirt explicitly recommends renewing certificates before expiration because expired certificates can cause communication between the Engine and hosts to stop and make recovery considerably more difficult.

Periodically check:

openssl x509 \
  -in /etc/pki/ovirt-engine/certs/apache.cer \
  -noout -enddate

For monitoring systems, OpenSSL can also determine whether a certificate will expire within a given number of seconds.

For example, check whether it expires within 30 days:

openssl x509 \
  -checkend $((30*24*60*60)) \
  -noout \
  -in /etc/pki/ovirt-engine/certs/apache.cer

A monitoring alert 30–60 days before expiration provides plenty of time to schedule maintenance.

Conclusion

The error:

PKIX path validation failed:
java.security.cert.CertPathValidatorException:
validity check failed

can look like a serious oVirt infrastructure failure, but the root cause may be much simpler: an expired Apache SSL certificate on the Hosted Engine VM.

The safest troubleshooting strategy is:

1. Verify the Engine VM’s system time.
2. Check apache.cer.
3. Check engine.cer.
4. Check ca.pem.
5. Determine exactly which certificate expired.
6. Back up the Engine.
7. Put a Self-Hosted Engine environment into global maintenance.
8. Use the certificate-renewal procedure supported by your oVirt version, commonly engine-setup --offline.
9. Resolve repository or DNS problems if they prevent engine-setup from starting.
10. Verify the renewed certificate and Engine services.
11. Disable global maintenance.
12. Add certificate-expiration monitoring.

Most importantly, do not replace a healthy oVirt CA just because the Apache certificate has expired. Diagnosing the individual certificates first can turn what appears to be a major PKI recovery into a relatively straightforward maintenance operation.

SEO Elements

SEO title:
oVirt PKIX Path Validation Failed: How to Fix an Expired SSL Certificate

Meta description:
Learn how to diagnose and fix the oVirt “PKIX path validation failed” error caused by an expired Apache SSL certificate in a Self-Hosted Engine environment, including engine-setup and DNF troubleshooting.

Suggested URL slug:
ovirt-pkix-path-validation-failed-expired-ssl-certificate

Focus keyphrase:
oVirt PKIX path validation failed

Secondary keywords:
oVirt expired certificate, oVirt SSL certificate renewal, oVirt Hosted Engine certificate, CertPathValidatorException validity check failed, engine-setup certificate renewal, oVirt apache.cer expired, engine-setup offline

Suggested excerpt:
An expired oVirt Apache certificate can cause a PKIX path validation failure and prevent access to the Administration Portal. This guide explains how to identify the expired certificate, safely renew it in a Hosted Engine environment, and troubleshoot repository errors that can block engine-setup.