Code change:
// it does not have to be reimplemented. type counterRaiser struct { counter *metrics.Counter <del> reason  string </del> <ins> // programmatic id used in log and audit annotations prefixes id string // human readable explanation reason string </ins> } func (c *counterRaiser) IncreaseMetricsCounter(req *http.Request) { if req != nil && req.URL != nil { if hostname := req.URL.Hostname(); len(hostname) > 0 { <del> klog.Infof("invalid certificate detected while connecting to %q: %s", req.URL.Hostname(), c.reason) </del> <ins> prefix := fmt.Sprintf("%s.invalid-cert.kubernetes.io", c.id) klog.Infof("%s: invalid certificate detected connecting to %q: %s", prefix, hostname, c.reason) audit.AddAuditAnnotation(req.Context(), prefix+"/"+hostname, c.reason) </ins> } } c.counter.Inc()

Related discussion:
text: go1.18 dropped support for certificates signed with the SHA-1 hash function - While this does improve security, and publicly trusted Certificate Authorities no longer issue such certificates, it is possible that user-provided certificates issued by private Certificate Authorities and used in webhooks or aggregated API servers do still use this. Similar to removal of support for certificates without subjectAltNames in go1.17, we need to: [x] add metrics when webhook/conversion/aggregated certificates with this hash are encountered - [x] document use of and the metric from 1 as a mitigation for clusters which still need to identify and replace use of such certificates - to release note and known issues [x] add audit annotation when SHA-1 cert is encountered - [x] update docs at and - /sig api-machinery instrumentation docs /priority important-soon /milestone v1.24 /kind bug documentation Upgraded 1.23 clusters to continue working as-is Configure an admission webhook, conversion webhook, or aggregated server with a serving certificate signed with the SHA-1 hash function. Upgrade to HEAD of 1.24. The certificate will no longer work by default No response 24 HEAD (go1.18-based) n/a n/a No response No response No response
it looks like NewMissingSANRoundTripperWrapperConstructor already has all the plumbing, and instead of missing SANs we could check the SignatureAlgorithm and output a distinct metric
had a not-yet-tested WIP branch at with a sketch of what it might look like
/assign who offered to pick this up
GitHub didn't allow me to assign the following users: stlaz. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign who offered to pick this up Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Indeed, please, you should trust Jordan :slightlysmilingface:
/assign
/triage accepted
These restrictions are on the GitHub side, this message is posted when it receives a specific error from the GitHub API while attempting to assign It is an annoying GitHub limitation, and one that seemingly does not exist in the web client vs the API.