This should be in 4.6.0-0.nightly-2020-10-08-111332 if you have the ability to test a nightly with a registry that lacks a DNS SAN entry we'd appreciate feedback on whether or not this resolves the problem. If you cannot test nightlies this will be in the next RC as well.
Kyle, Could you please test the nightly referenced above with a cert that does not have the SAN entries? Thanks
This was cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1882191 if additional context is necessary. Whenever we clone a bug it marks the entire history as private if there's any private comments made. Thanks for looking.
Hi, Unfortunately, there is no 4.6.0-0.nightly-2020-10-08-111332 build from CI. We downloaded OCP build 4.6.0-0.nightly-s390x-2020-10-08-182421 and tested this instead. We are also using RHCOS 46.82.202010071939-0 to test this nightly. I tested the disconnected install on zKVM first using the CN property and the install succeeded. There is still the issue where you need to set the variable GODEBUG=x509ignoreCN=0 prior to running the command to mirror the images to our local private registry, otherwise you would see this error: # oc adm -a ${LOCAL_SECRET_JSON} release mirror --from=registry.svc.ci.openshift.org/ocp-s390x/release-s390x@sha256:9be577ca37cf8aa5c9b97b33a6cc1551bdbad4dc6fdfd628b0a364bce35eb7d1 --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE} warning: An image was retrieved that failed verification: unable to locate a valid signature for one or more sources info: Mirroring 122 images to bastion:5000/ocp4/openshift4 ... error: unable to connect to bastion:5000/ocp4/openshift4: Get "https://bastion:5000/v2/": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 I then re-tested using a SAN property, and this also successfully installed. We are in the process of verifying this on zVM. Based on the above results, this nightly build works for both CN and SAN entries. If we proceed with this release candidate, I think at a minimum we'll need a documentation update with regard to the GODEBUG variable. Thank you, -Phil
Thanks for confirming. I think for the mirror command that is fine that you set the env variable explicitly as the oc binaries have been compiled with Go1.15.
Deprecation notice will note client side unless they do something like build the client with 1.14. Bug for that at https://bugzilla.redhat.com/show_bug.cgi?id=1886892
Prashanth and Scott, Thank you for your assistance and the information on the OCP on Z 4.6 fix to support OCP 4.6 disconnected installs using certificates with and without SAN configuration. Using certificates configured with and without SANs, we have successfully tested OCP 4.6 disconnected installs on zVM hosted clusters. The following OCP on Z 4.6 RC builds and associated RHCOS builds, with or without SAN configured certificates, have been successfully tested for disconnected installs on zVM hosted clusters, using RHCOS 46.82.202010071939-0 to install the bootstrap node. OCP level RHCOS level With SAN cert Without SAN cert Comments ========== ==================== ============= ================ =================================================================================== 1. 4.6.0-rc.0 46.82.202010051339-0 successful unsuccessful As expected, as the fix for non-SAN configured certs not included in this build. 2. 4.6.0-rc.1 46.82.202010071939-0 successful successful As expected, as the fix for SAN and non-SAN configured certs included in this build. 3. 4.6.0-rc.2 46.82.202010082340-0 successful successful As expected, as the fix for SAN and non-SAN configured certs included in this build. Thank you, Kyle
Based on comment #8, marking VERIFIED
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 (OpenShift Container Platform 4.6 GA Images), 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:4196