OCPBUGS-26498: Upgrade Validation plugin for SHA1 certs #555

gcs278 · 2024-01-11T00:01:06Z

This PR adds support for setting a new status condition type, UnservableInFutureVersions, when a SHA1 cert is detected on a route. It accomplishes this by adding a new plugin, the upgrade validation plugin. This plugin is simple: when a route configuration that is unsupported in the future is detected, it adds a UnservableInFutureVersions status condition to the route. When the problematic configuration is no longer detected, it clears/removes the UnservableInFutureVersions condition.

In order to support updating a new route status condition, the routeRejectionRecorder and associated methods were refactored to be more generic. The writerlease logic used to update route status had to be refactored because the old code made assumptions that only one type of status condition would ever be updated.

It also updates certificates for existing unit tests, as some certificates were SHA1 and incorrectly labeled as expired.

This PR is intended to be introduced in 4.16, but to be backported to 4.15 as UnservableInFutureVersions only makes sense in 4.15 because 4.16 will reject SHA1 routes. In PR #552, there will be a partial revert, as it will no longer add UnservableInFutureVersions to SHA1 routes due to them now being rejection.

Dependent on openshift/api#1722
Related Ingress Operator PR openshift/cluster-ingress-operator#1014

openshift-ci-robot · 2024-01-11T00:01:13Z

@gcs278: This pull request references Jira Issue OCPBUGS-26498, which is invalid:

expected the bug to target the "4.16.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

If a route has a SHA1 certificate, set a new route ingress condition status type of Upgradeable to false.

Dependent on openshift/api#1722

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-01-30T17:09:05Z

@gcs278: This pull request references Jira Issue OCPBUGS-26498, which is valid.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.16.0) matches configured target version for branch (4.16.0)
bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @ShudiLi

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

This PR adds support for setting a new status condition type, Deprecated, when a SHA1 cert is detected on a route. It accomplishes this by adding a new plugin, the deprecation validation plugin. This plugin is simple: when a specific deprecated configuration on a route is detected, it adds a Deprecated status condition to the route. When the deprecated configuration is no longer detected, it clears/removes the Deprecated condition.

In order to support updating a new route status condition, the routeRejectionRecorder and associated methods were refactored to be more generic. The writerlease logic used to update route status had to be refactored because the old code made assumptions that only one type of status condition would ever be updated.

It also updates certificates for existing unit tests, as some certificates were SHA1 and incorrectly labeled as expired.

Dependent on openshift/api#1722
Related Ingress Operator PR openshift/cluster-ingress-operator#1014

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

gcs278 · 2024-01-30T17:12:31Z

/test verify

gcs278 · 2024-04-17T16:04:15Z

/test e2e-upgrade

Miciah

Excellent work! I made some comments, but the one thing I want to clarify is whether UpgradeRouteValidation should be checking tlsConfig.CACertificate or tlsConfig.DestinationCACertificate in addition to tlsConfig.Certificate (see #555 (comment)).

Miciah · 2024-04-17T00:27:12Z

.gitleaks.toml

Are the changes in this PR causing scanners to report issues with these files, or is this change logically separate from the SHA1 validation change?

Yes, the PR commit Regenerate certs for unit tests is causes the scanner to report repo leaks due to certs changing in the test files.

Regenerate certs for unit tests is required because we need to differentiate between SHA1 and SHA256 certs in our testing for the Upgrade Validation plugin.

pkg/router/routeapihelpers/validation_test.go

Miciah · 2024-04-18T21:24:50Z

pkg/router/routeapihelpers/validation_test.go

+			name: "Edge termination cert key mismatch",
 			route: &routev1.Route{
 				Spec: routev1.RouteSpec{
 					Host: "www.example.com",
 					TLS: &routev1.TLSConfig{
 						Termination:   routev1.TLSTerminationEdge,
-						Certificate:   testExpiredCAUnknownCertificate,
+						Certificate:   testCAUnknownCertificate,
 						Key:           testPrivateKey,
 						CACertificate: testCACertificate,


This test case seems to have both a mismatch between server certificate and key and a mismatch between server certificate and CA certificate. The test case fails with the expected error (namely the mismatch between server certificate and key), so it passes as is. However, there are a few oddities here:

The test-case name only mentions the one mismatch.

The test case expects only one error—perhaps for the same reason that "Edge termination with expired cert, ignoring CA mismatch" passes, in which case it might be helpful to add a comment saying as much.

I suspect the test case would pass when it shouldn't if the validation erroneously checked for a match between the server certificate and CA certificate and not between the server certificate and key.

There is already a test, "Edge termination mismatched key and cert", which seems to cover the case of a mismatch between server certificate and key:

router/pkg/router/routeapihelpers/validation_test.go

Lines 1170 to 1183 in 20865c3

{

name: "Edge termination cert with unknown CA",

route: &routev1.Route{

Spec: routev1.RouteSpec{

Host: "www.example.com",

TLS: &routev1.TLSConfig{

Termination: routev1.TLSTerminationEdge,

Certificate: testCAUnknownCertificate,

Key: testCAUnknownCertificateKey,

},

},

},

expectedErrors: 0,

},

Is this a duplicate test case, or should it be named something like "Edge termination mismatched key and cert with unrelated CA"?

The test-case name only mentions the one mismatch.

Updated the name to "Edge termination mismatched key and cert with unrelated CA".

The test case expects only one error—perhaps for the same reason that "Edge termination with expired cert, ignoring CA mismatch" passes, in which case it might be helpful to add a comment saying as much.

Sorry, this is where I get confused. I thought you were taking about previously named "Edge termination cert key mismatch", which returns 2 expectedErrors.

Is this a duplicate test case, or should it be named something like "Edge termination mismatched key and cert with unrelated CA"?

I don't think it's a duplicate. It returns a different number of errors, so I've taken your suggested name change.

The test case expects only one error—perhaps for the same reason that "Edge termination with expired cert, ignoring CA mismatch" passes, in which case it might be helpful to add a comment saying as much.

Sorry, this is where I get confused. I thought you were taking about previously named "Edge termination cert key mismatch", which returns 2 expectedErrors.

Sorry, I must have been mixing up test cases or misreading the diff.

pkg/router/routeapihelpers/validation_test.go

pkg/router/controller/status.go

pkg/router/template/plugin_test.go

pkg/router/controller/status_test.go

pkg/router/controller/host_admitter_test.go

SHA1 certs will be unsupported in the future. Clean up unit tests to organize clearly between SHA1 and SHA256 certs. The unit tests had SHA1 certs that weren't tested separately. Also, the unit tests claimed to be using an expired certificate, but it was NOT expired. Document all certs by adding openssl comands for the regenerated certs to help future developers recreate certs if needed.

Bumping openshift/api requires bumping golang to 1.21 otherwise the ci/prow/verify job will fail on go tidy.

Bump openshift/api to get new route UnservableInFutureVersions status condition type and update K8S packages to 0.29.1.

When an route ingress already exists, but an expected condition isn't found, recordIngressCondition would previously not change/update anything. This wasn't an issue for when only had Admitted because the route ingress was updated synchronously with the Admitted condition. However, adding another route status condition exposes the scenario in which a route ingress will exist, but the desired condition won't. This also adds a unit test for recordIngressCondition which explicitly tests this case along with other edge cases.

Previously, recordIngressCondition sometimes clears the original return value conditions depending on whether the condition was found and changed. This doesn't seem consistent and makes it hard to unit test. The original return value only affects logging. Logging the original conditions is advantageous because modifying conditions can also lead to contention, and having visibility into the modified conditions is beneficial. Therefore, it seems reasonable to remove condition clearing as it benefits logging and it's inconsistent. Update unit testing to now verify original return value from recordIngressCondition.

Add the Upgrade Validation plugin which provides a framework for adding a status to a route to indicate future upgrade issues. For this initial implementation, if a route has a SHA1 certificate, the upgrade validation plugin will mark the route with a UnservableInFutureVersions status. If the route no longer has a SHA1 certificate, remove the status instead of setting UnservableInFutureVersions=false. This is specific to OpenShift 4.15 and is expected to be removed from 4.16 once backported to avoid confusion. It's specific to 4.15 because 4.15 accepts SHA1 certs, but 4.16 does not. Therefore, validating the upgrade should be only done in 4.15. Update the RejectionRecorder interface to be the RouteStatusRecorder to support more generic status-related use cases as we have more than just Admitted status now. Add UPGRADE_VALIDATION env variable, but default to true, so that we can disable in the future. Follow existing pattern similar to existing EXTENDED_VALIDATION env variable. Key the writerlease logic off of route UID AND condition type. This is now essential because if only route UID, then the lease logic will only update one condition as it doesn't differentiate from the work items for the different conditions. Adjust findMostRecentIngress to use the latest condition instead of just Admitted as we can no longer assume that Admitted is the only condition. Add a type for writelease WorkKey to ensure strings aren't used anymore as the previous logic was only using route.UID. Add a type for ContentionTracker key to ensure it is different than writelease WorkKey. Update ingressEqual function to detect contention if any condition is not equal. Previously, it hardcoded the "Admitted" status. Add a unit test, TestRouterContentionUpdateCondition to test these changes.

gcs278

@Miciah Thanks for the detailed review. Changes are here: https://github.com/openshift/router/compare/d5ea141e7ff30459aeff301e46f09bd7715c839c..c22b003ff4b0140aaa0fecefdd699a1b74717415

gcs278 · 2024-04-19T14:00:07Z

.gitleaks.toml

Yes, the PR commit Regenerate certs for unit tests is causes the scanner to report repo leaks due to certs changing in the test files.

Regenerate certs for unit tests is required because we need to differentiate between SHA1 and SHA256 certs in our testing for the Upgrade Validation plugin.

gcs278 · 2024-04-19T15:08:44Z

pkg/router/controller/status_test.go

+			if diff := cmp.Diff(baselineIngressState, original, cmpOpts...); len(diff) > 0 {
+				t.Errorf("expected original to match baseline ingress from route.Status (-want +got):\n%s", diff)
+			}


Because I believe removing the original.Conditions = nil in recordIngressCondition is a net positive .

First, it had no impact other than logging. original was only used for logging

Besides being confusing to modify a variable called original, removing the conditions removes half the benefit of logging here.

I found myself trying to debug a contention issue, and the fact it doesn't log the conditions makes that much harder.

Adding the new UnservableInFutureVersions condition and condition removal as contention points makes this even more desirable (more potential contention will be between conditions)

It only clears conditions on the original return value when the ingress has changed...that feels confusing and inconsistent.

gcs278 · 2024-04-19T16:37:08Z

pkg/router/controller/status.go

+		// preserve a deep copy of the original ingress
+		original := existing.DeepCopy()


This seems like a pessimization. Doing a deep copy has significant time and memory impact.

Yes, it's slower, I agree.

Is the intention only to make writing the unit test easier, or is it the intention also to improve logging or something else?

Well neither, I wrote it as a "future proofing" or "avoiding fragility" fix.

Reviewing how shallow copies work in Go again, I see now that we technically don't need the deepcopy, as the RouteIngress object is made up of values, not pointers, except for []conditions, which I now understand each item in a slice is a pointer, but the slice header is a value (which includes slice length).

Since the logic below only ever appends to the shallow copy slice of existing.Conditions (different slice header), that means that original will be unaffected by the current logic below.

I'll switch back to a shallow copy for now since it's provides the same result.

pkg/router/controller/host_admitter_test.go

gcs278 · 2024-04-19T17:25:44Z

pkg/router/controller/status.go

+
+		return handleRouteStatusUpdate(context.TODO(), action, oc, route, latest, tracker)
 	})
 }


Yes I like that. I had the idea to do a callback, but got stuck following through with it, but this was I wanted.

Maybe better left as a follow-up as it would be nontrivial to check for correctness.

Could you elaborate? It appear "correct" for our two use-cases (performIngressConditionUpdate, performIngressConditionRemoval), but are you saying we would need to explore "correctness" for other (future) use cases?

I ask because I prefer this logic, and don't exactly see how any more "non-trivial" it is than what I currently have.

pkg/router/routeapihelpers/validation_test.go

gcs278 · 2024-04-19T18:52:37Z

pkg/router/routeapihelpers/validation_test.go

+			name: "Edge termination cert key mismatch",
 			route: &routev1.Route{
 				Spec: routev1.RouteSpec{
 					Host: "www.example.com",
 					TLS: &routev1.TLSConfig{
 						Termination:   routev1.TLSTerminationEdge,
-						Certificate:   testExpiredCAUnknownCertificate,
+						Certificate:   testCAUnknownCertificate,
 						Key:           testPrivateKey,
 						CACertificate: testCACertificate,


The test-case name only mentions the one mismatch.

Updated the name to "Edge termination mismatched key and cert with unrelated CA".

The test case expects only one error—perhaps for the same reason that "Edge termination with expired cert, ignoring CA mismatch" passes, in which case it might be helpful to add a comment saying as much.

Sorry, this is where I get confused. I thought you were taking about previously named "Edge termination cert key mismatch", which returns 2 expectedErrors.

Is this a duplicate test case, or should it be named something like "Edge termination mismatched key and cert with unrelated CA"?

I don't think it's a duplicate. It returns a different number of errors, so I've taken your suggested name change.

gcs278 · 2024-04-19T19:14:12Z

pkg/router/routeapihelpers/validation_test.go

-			name: "Edge termination expired cert unknown CA",
+			name: "Edge termination cert with unknown CA",


Yes, sorry this is painful to review. Thanks for writing this out.

"Edge termination expired cert unknown CA" is deleted and replaced by these two tests:

"Edge termination expired cert with unknown CA", which uses an actually expired certificate so it does what the name says.

"Edge termination cert with unknown CA", which does what "Edge termination expired cert unknown CA" actually did (despite the latter's misleading name).

Yes, that seems right.

"Edge termination expired cert key mismatch" is renamed to "Edge termination cert key mismatch" to reflect what it actually tests. We already have "Expired cert mismatched key", which actually covers what the name implies (though unlike "Edge termination expired cert key mismatch", "Expired cert mismatched key" doesn't specify CACertificate).

Yes, this one just had an incorrect name.

"Edge termination expired cert mismatched CA" is deleted and replaced by these two tests:

"Edge termination with expired cert, ignoring CA mismatch", which uses an actually expired certificate so it does what the name says. (Using an actually expired certificate also means that expectedErrors changes from 0 to 1.)

"Edge termination cert mismatched CA", which does what "Edge termination expired cert mismatched CA" actually did (despite the misleading name).

Correct, the testExpiredCAUnknownCertificate it was using was NOT expired. Super confusing.

"Expired cert" is renamed to "expired cert edge" and fixed to use an actually expired certificate; what it actually tested is already tested by "Edge termination OK with certs".

Correct.

The rest of the changes are changes to individual tests, the test runner logic, or net-new tests.

I think so.

pkg/router/controller/status.go

pkg/router/controller/status_test.go

Miciah · 2024-04-20T03:40:55Z

Thanks!
/approve
/lgtm
Do you want to implement #555 (comment), or should we go with what you have?
/hold
for the above question, and in case Andy wants to have another look.

openshift-ci · 2024-04-20T03:41:26Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Miciah

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [Miciah]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

gcs278 · 2024-04-20T21:16:28Z

Thanks @Miciah! For the sake of time, I'm going to save #555 (comment) as a follow up. I do plan a follow up change in a hopeful fix for https://issues.redhat.com/browse/OCPBUGS-1689 as this PR has laid the groundwork from removing conditions.

I'll wait for to hear from @frobware to remove the hold.

gcs278 · 2024-04-20T21:17:04Z

Unrelated pod IP failure:
/test e2e-upgrade

openshift-ci · 2024-04-20T23:29:34Z

@gcs278: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

frobware · 2024-04-22T10:19:57Z

/hold cancel

openshift-ci-robot · 2024-04-22T10:22:23Z

@gcs278: Jira Issue OCPBUGS-26498: Some pull requests linked via external trackers have merged:

The following pull requests linked via external trackers have not merged:

openshift/cluster-ingress-operator#1014 is open

These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with /jira refresh.

Jira Issue OCPBUGS-26498 has not been moved to the MODIFIED state.

Details

In response to this:

This PR adds support for setting a new status condition type, UnservableInFutureVersions, when a SHA1 cert is detected on a route. It accomplishes this by adding a new plugin, the upgrade validation plugin. This plugin is simple: when a route configuration that is unsupported in the future is detected, it adds a UnservableInFutureVersions status condition to the route. When the problematic configuration is no longer detected, it clears/removes the UnservableInFutureVersions condition.

In order to support updating a new route status condition, the routeRejectionRecorder and associated methods were refactored to be more generic. The writerlease logic used to update route status had to be refactored because the old code made assumptions that only one type of status condition would ever be updated.

It also updates certificates for existing unit tests, as some certificates were SHA1 and incorrectly labeled as expired.

Dependent on openshift/api#1722
Related Ingress Operator PR openshift/cluster-ingress-operator#1014

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-bot · 2024-04-22T13:16:55Z

[ART PR BUILD NOTIFIER]

This PR has been included in build ose-haproxy-router-base-container-v4.16.0-202404220845.p0.g7ad7ec1.assembly.stream.el9 for distgit ose-haproxy-router-base.
All builds following this will include this PR.

openshift-ci-robot · 2024-04-22T14:49:30Z

@gcs278: Jira Issue OCPBUGS-26498: Some pull requests linked via external trackers have merged:

The following pull requests linked via external trackers have not merged:

openshift/cluster-ingress-operator#1014 is open

These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with /jira refresh.

Jira Issue OCPBUGS-26498 has not been moved to the MODIFIED state.

Details

In response to this:

This PR adds support for setting a new status condition type, UnservableInFutureVersions, when a SHA1 cert is detected on a route. It accomplishes this by adding a new plugin, the upgrade validation plugin. This plugin is simple: when a route configuration that is unsupported in the future is detected, it adds a UnservableInFutureVersions status condition to the route. When the problematic configuration is no longer detected, it clears/removes the UnservableInFutureVersions condition.

In order to support updating a new route status condition, the routeRejectionRecorder and associated methods were refactored to be more generic. The writerlease logic used to update route status had to be refactored because the old code made assumptions that only one type of status condition would ever be updated.

It also updates certificates for existing unit tests, as some certificates were SHA1 and incorrectly labeled as expired.

This PR is intended to be introduced in 4.16, but to be backported to 4.15 as UnservableInFutureVersions only makes sense in 4.15 because 4.16 will reject SHA1 routes. In PR #552, there will be a partial revert, as it will no longer add UnservableInFutureVersions to SHA1 routes due to them now being rejection.

Dependent on openshift/api#1722
Related Ingress Operator PR openshift/cluster-ingress-operator#1014

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

gcs278 · 2024-04-22T22:50:03Z

/cherry-pick 4.15

openshift-cherrypick-robot · 2024-04-22T22:50:44Z

@gcs278: cannot checkout 4.15: error checking out "4.15": exit status 1 error: pathspec '4.15' did not match any file(s) known to git

Details

In response to this:

/cherry-pick 4.15

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

gcs278 · 2024-04-22T22:56:07Z

/cherry-pick release-4.15

openshift-ci-robot added the jira/severity-moderate Referenced Jira bug's severity is moderate for the branch this PR is targeting. label Jan 11, 2024

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 11, 2024

openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jan 11, 2024

openshift-ci bot requested review from Miciah and rfredette January 11, 2024 00:01

gcs278 force-pushed the OCPBUGS-26498-upgradeable-status branch 3 times, most recently from c6a9ad2 to 5eb0acb Compare January 18, 2024 20:27

gcs278 force-pushed the OCPBUGS-26498-upgradeable-status branch 12 times, most recently from b88197d to a378d74 Compare January 30, 2024 16:53

gcs278 changed the title ~~[WIP] OCPBUGS-26498: Route Upgradeable status for SHA1~~ [WIP] OCPBUGS-26498: Route Deprecated plugin for SHA1 certs Jan 30, 2024

openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jan 30, 2024

openshift-ci bot requested a review from ShudiLi January 30, 2024 17:09

gcs278 changed the title ~~[WIP] OCPBUGS-26498: Route Deprecated plugin for SHA1 certs~~ [WIP] OCPBUGS-26498: Deprecation Validation plugin for SHA1 certs Jan 30, 2024

gcs278 mentioned this pull request Jan 30, 2024

[release-4.15] OCPBUGS-28928: Prevent upgrades for SHA1 default cert and SHA1 route certs openshift/cluster-ingress-operator#1014

Merged

Miciah reviewed Apr 19, 2024

View reviewed changes

gcs278 added 6 commits April 19, 2024 15:16

Bump golang 1.21

6bec801

Bumping openshift/api requires bumping golang to 1.21 otherwise the ci/prow/verify job will fail on go tidy.

Bump openshift/api

79d80c4

Bump openshift/api to get new route UnservableInFutureVersions status condition type and update K8S packages to 0.29.1.

gcs278 force-pushed the OCPBUGS-26498-upgradeable-status branch from d5ea141 to c22b003 Compare April 19, 2024 19:40

gcs278 commented Apr 19, 2024

View reviewed changes

openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Apr 20, 2024

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 20, 2024

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 22, 2024

openshift-merge-bot bot merged commit 7ad7ec1 into openshift:master Apr 22, 2024

This was referenced Apr 23, 2024

[release-4.15] OCPBUGS-28928: Upgrade Validation plugin for SHA1 certs #585

Merged

WIP: Extended TestRouteAdmissionPolicy test timeouts openshift/cluster-ingress-operator#1051

Closed

gcs278 mentioned this pull request Apr 30, 2024

OCPBUGS-26498: Make ingressConditionsEqual more efficient #588

Merged

	{
	name: "Edge termination cert with unknown CA",
	route: &routev1.Route{
	Spec: routev1.RouteSpec{
	Host: "www.example.com",
	TLS: &routev1.TLSConfig{
	Termination: routev1.TLSTerminationEdge,
	Certificate: testCAUnknownCertificate,
	Key: testCAUnknownCertificateKey,
	},
	},
	},
	expectedErrors: 0,
	},

		// preserve a deep copy of the original ingress
		original := existing.DeepCopy()

		name: "Edge termination expired cert unknown CA",
		name: "Edge termination cert with unknown CA",

OCPBUGS-26498: Upgrade Validation plugin for SHA1 certs #555

OCPBUGS-26498: Upgrade Validation plugin for SHA1 certs #555

Uh oh!

Conversation

gcs278 commented Jan 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 11, 2024

Uh oh!

openshift-ci-robot commented Jan 30, 2024

Uh oh!

gcs278 commented Jan 30, 2024

Uh oh!

gcs278 commented Apr 17, 2024

Uh oh!

Miciah left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Miciah Apr 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gcs278 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Miciah commented Apr 20, 2024

Uh oh!

openshift-ci bot commented Apr 20, 2024

Uh oh!

gcs278 commented Apr 20, 2024

Uh oh!

gcs278 commented Apr 20, 2024

Uh oh!

openshift-ci bot commented Apr 20, 2024

Uh oh!

frobware commented Apr 22, 2024

Uh oh!

openshift-ci-robot commented Apr 22, 2024

Uh oh!

openshift-bot commented Apr 22, 2024

Uh oh!

openshift-ci-robot commented Apr 22, 2024

Uh oh!

gcs278 commented Apr 22, 2024

Uh oh!

openshift-cherrypick-robot commented Apr 22, 2024

Uh oh!

gcs278 commented Jan 11, 2024 •

edited

Loading

Miciah left a comment •

edited

Loading

Miciah Apr 20, 2024 •

edited

Loading