Can we update this to a feature request then? There is already special logic in the MCO to identify when a cert path has updated, it shouldn't be too much lift to refresh the certs in those cases before trying to pull the OS image right? The MCO updates all of the repository configs (allowlisted urls, mirrors, contact source policies, etc) before trying to pull the image, and no where in the documentation does it say you need to update a CA before an OSImage or your MCP update will be blocked. There is also no other case that I know of where you need to worry about applying a config and wait for the MCP to update across all hosts, before updating another config. I'd expect, if all of the configs are applied correctly, the MCP would be able to successfully update a host. We are using the customOSImage override supported here: https://github.com/openshift/machine-config-operator/blob/01141a259d5a9adbb4c301941e016985124c17ef/docs/UsingLayering.md?plain=1#L94 So yes one is a config map and one is a machine config. Nothing is done by hand to make this happen it's all automated as a part of our installation. I'm not sure what you mean by this can't be done in a future release. There are cases where the update CA Trust is run rather than restarting the host: https://github.com/openshift/machine-config-operator/blob/01141a259d5a9adbb4c301941e016985124c17ef/pkg/daemon/update.go#L219 There are also constants already defined for the cert paths: https://github.com/openshift/machine-config-operator/blob/01141a259d5a9adbb4c301941e016985124c17ef/pkg/daemon/update.go#L1995-L1997 So why can't there be a check for if one of the cert paths change, update the trust store before pulling the new OSImage. Or, if the pull OS Image fails, try to update the trust store and pull again?