This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
I spent quite some time in recent days trying to fully understand both the current status re the various openssl conf files and their templates, as well as _why_ it's like that. Documenting it here for reference. We have: [1] cacert.template.in [2] cacert.template [3] cacert.conf [4] cert.template.in [5] cert.template [6] cert.conf [1],[2],[3] are only used for creating the CA itself (its keys). [4],[5],[6] are used when signing other keys/requests by the CA. [1],[4] are packaged in the RPM. [2] is generated from [1], and [5] from [4], by engine-setup code, replacing '@AIA@' with the URI for authorityInfoAccess. However, only [4] includes it - [1] and [2] are identical. This is true since 3.3 [7]. Before that, the implementation was different, and both [3] and [6] included authorityInfoAccess. Now (after [7]), [2] is copied to [3], and [5] to [6], by pki-create-ca.sh. Before [7], the scripts used till then also changed the copies, but now they remain untouched - and there is no practical reason to have the copies. Also: We have, in pki-enroll-request.sh, code that checks if ca.pem has the extension "Subject Key Identifier", and if so it uses [6] (and a few other things). This was originally added to fix bug 588721, at the time a RHEV 2.2/2.3 bug, before oVirt was published. I can't tell if it still affects current setups, if they were upgraded from such old versions. I think I'll do just the minimal changes needed to fix current bug: 1. Make engine-setup create two copies of above [2] - one remains as-is (before current bug), other with qemu somewhere in its name and current content 2. Make pki-* scripts copy/use the relevant file, based on the existing param "--ca-file". That's ugly, but we already have code doing this, so I am not breaking anything... [7] https://gerrit.ovirt.org/15499 pki: scripts rework, hash 400c9cf5d8195353e52726e3a09accd6084d09ae
Update to comment 3: [2],[3] are re-generated from [1], and [5],[6] from [4], by engine-setup during upgrades, using the AIA in [5]. If we want to fix current bug also on upgrades, we need to also consider this. In particular, probably something like this: 1. Try to regenerate [5],[6] from [4] and compare with [5],[6] itself. If equal, it means user didn't change them, so probably we should. 2. Use the correct AIA in each case, and (re-)generate current and new qemu-ones.
About AIA - Authority Information Access Answering Sandro's comment/question [1] saying he is not sure how AIA works. I am not an expert in the field either. Most of my knowledge specifically about how it is/was used in oVirt is based on reading the code and bugzilla discussions, not reference material. I wrote much of what I know about this in above comment 3 (and comment 4). I don't mind writing also current comment, but do not want to sound authoritative. Specifically, one of the changes that Alon introduced was to not include AIA in new _CA_ certs (and the conf files used in generating these), presumably because this is fundamentally wrong. I can't say I ever fully understood what's so wrong with this - other than perhaps breaking the possibility to easily do a rename. Best I can find right now, copying a paragraph from [2], is: The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to the CA that issued the certificate containing this extension. The referenced CA issuers description is intended to aid certificate users in the selection of a certification path that terminates at a point trusted by the certificate user. Anyway, he decided this is bad and changed this. However, there was a problem: It seems that in the past, it was possible for a user to manually change cacert.template, and perhaps this was even documented (failed to find anything), in order to affect CA creation. So he made the code respect AIA in cacert.template and carry it on even when we decide to re-generate cacert.template (which we did in the past, e.g. to include new extensions, fix stuff, etc.). See also [3]. Now, we have an additional bug (current): the templates were written, until current patch, twice: Once with correct AIA, then again with broken AIA (which links at qemu-ca cert). With above in mind: I have two functions for "getting" AIA: One from an existing template, other by "calculating" it (code in them already existed here, but not explicitly in functions nor parametric). Then: 1. I get aia from each template. If qemu template is missing (it will always be, when upgrading from a setup before current bug to a later one), I set it to calculated one. 2. If engine template seems broken (aia links at qemu-ca), I use calculated one also for engine, and emit suitable messages depending on whether file was changed or not. 3. Then I re-generate templates from .in files (as before), with the correct aia. I hope this is clear enough. [1] https://github.com/didib/ovirt-engine/commits/qemu-ca-fixes [2] https://tools.ietf.org/html/rfc3280#section-4.2.2.1 [3] https://gerrit.ovirt.org/#/q/Ia975aad12e97ce0287cd6414e7ab91ea2ca6c0f9,n,z
QE: Reproduction/Verification: Flows ===== 1. Install and setup engine, add hosts 2. Upgrade engine, add hosts, re-enroll certificates Tests ===== 1. cd /etc/pki/ovirt-engine grep -i authorityInfoAccess *{conf,template} 2. cd certs for f in *.cer; do echo === $f; openssl x509 -in $f -text | grep -A1 'Authority Information Access:'; done Expected results ================ With a broken build, the commands in "Tests" emit (also) "qemu-ca", also for files which are not part of the qemu CA. With a fixed build, "qemu-ca" should appear (currently) only in conf files that include 'qemu' in their name, and (currently) not in any cert. When upgrading to a fixed build, "qemu-ca" should appear (currently) only in conf files that include 'qemu' in their name, and (currently) not in any new cert. Existing certs are not changed.
Clean install verified with ovirt-engine-4.4.4.1-0.1.el8ev.noarch - everything has ca-cert and no qemu-ca in relevant places (not counting qemu certs) Upgraded env verified with ovirt-engine-4.4.4.1-0.1.el8ev.noarch - existing certs are kept with qemu-ca, reenrolled certs have ca-cert - templates have ca-cert instead of qemu-ca they used to have - there is also a mention of this bug during engine upgrade
This bugzilla is included in oVirt 4.4.4 release, published on December 21st 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.