Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

For information on the advisory (Critical: OpenShift Container Platform 4.15.0 bug fix and security update), 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/RHSA-2023:7198

vrutkovs@redhat.com thanks for helping me answer that, i am not quite sure about the bug you are asking me to open so could you please help open it ? Based on your confirmation above about the `kube-api-server` owning it moving the bug to verified state.

When kube-apiserver starts it prepares cert key pairs for its components - including kube-controller-manager and kube-scheduler - and components are using it connect to kube-apiserver. So although they are in kube-controller/kube-scheduler namespaces the component responsible for certificate contents and its lifecycle is kube-apiserver, thus the annotation

vrutkovs@redhat.com okay, thank you !! But would like to understand what all should be a owning component of kube-apiserer vs kube-scheduler ? can you help me explain ? thanks !! Below is the output i see for kube-scheduler and kcm

kube-scheduler:
=============
[knarra@knarra ~]$ oc get secret -A -o json | jq -r ' .items[] | select( .metadata.annotations."auth.openshift.io/certificate-not-after" | .!=null and fromdateiso8601<='$( date --date='+10year' +%s )') | "expiration: ( .metadata.annotations."auth.openshift.io/certificate-not-after" ) cert-owning: ( .metadata.annotations."openshift.io/owning-component" ) ( .type ) -n ( .metadata.namespace ) ( .metadata.name )" ' | sort | column -t | grep "kube-scheduler"
expiration: 2023-12-12T20:42:23Z cert-owning: kube-apiserver kubernetes.io/tls -n openshift-config-managed kube-scheduler-client-cert-key
expiration: 2023-12-12T20:42:23Z cert-owning: kube-apiserver kubernetes.io/tls -n openshift-kube-scheduler kube-scheduler-client-cert-key

KCM:
===================
[knarra@knarra ~]$ oc get secret -A -o json | jq -r ' .items[] | select( .metadata.annotations."auth.openshift.io/certificate-not-after" | .!=null and fromdateiso8601<='$( date --date='+10year' +%s )') | "expiration: ( .metadata.annotations."auth.openshift.io/certificate-not-after" ) cert-owning: ( .metadata.annotations."openshift.io/owning-component" ) ( .type ) -n ( .metadata.namespace ) ( .metadata.name )" ' | sort | column -t | grep "kube-controller-manager"
expiration: 2023-12-12T20:42:16Z cert-owning: kube-apiserver kubernetes.io/tls -n openshift-config-managed kube-controller-manager-client-cert-key
expiration: 2023-12-12T20:42:16Z cert-owning: kube-apiserver kubernetes.io/tls -n openshift-kube-controller-manager kube-controller-manager-client-cert-key
expiration: 2023-12-13T08:28:07Z cert-owning: kube-controller-manager kubernetes.io/tls -n openshift-kube-controller-manager csr-signer
expiration: 2023-12-13T08:28:07Z cert-owning: kube-controller-manager kubernetes.io/tls -n openshift-kube-controller-manager-operator csr-signer
expiration: 2023-12-13T08:28:07Z cert-owning: kube-controller-manager kubernetes.io/tls -n openshift-kube-controller-manager-operator csr-signer-signer

First link won't open for me, but lets open a new issue - similar to OCPBUGS-23366

I see that kube-scheduler cert owning is shown as `kube-apiserver`, needed to confirm with apiserver dev if this is expected. checked with workloads dev and kube-apiserver team and they were kind of not very sure.

Thread here: https://redhat-internal.slack.com/archives/GK58XC2G2/p1702374943145799 -> workloads dev

control-plane-qe thread: https://redhat-internal.slack.com/archives/CS05TR7BK/p1702378805503759

Hi jchaloup@redhat.com,

Bugs should not be moved to Verified without first providing a Release Note Type("Bug Fix" or "No Doc Update") and for type "Bug Fix" the Release Note Text must also be provided. Please populate the necessary fields before moving the Bug to Verified.