Automated service ca rotation was initially released without a guarantee of a unique ca serial number due to the library code used to generate CAs using a fixed value. The lack of a unique serial number resulted in a broken chain of trust for non-golang clients such as curl [1]. If a cluster has been upgraded to a release supporting automated CA rotation but without the fix to ensure unique CA serials, the resulting CA configuration will break non-golang clients (e.g. curl) due to the chain of trust containing more than one certificate for the same issuer and serial. Fixing this CA configuration automatically will not be possible due to the requirement to restart affected services, so manual cert rotation [1] is likely the best option. 1: https://bugzilla.redhat.com/show_bug.cgi?id=1810036
Corrected, manual cert rotation link: https://docs.openshift.com/container-platform/4.3/authentication/certificates/service-serving-certificate.html#manually-rotate-service-ca_service-serving-certificate
Note that there is no work to be done on this BZ. It is intended to be the canonical BZ for reports of TLS validation errors caused by upgrading to 4.3.5 and 4.2.22. The fix is manual rotation.
Updating to indicate the affected release is 4.3.0, since this issue should only exhibit on 4.3.5. Again, no target release since we're not targeting a fix.
Closing since the issue is not actionable.