Thank you for all of your responses! Your comments helped through the investigation.
The :443 in the domain was being used to evaluate the domain in our backend system which caused the main issue. The CAA issue was on my end from some initial troubleshooting but has been corrected.
The only remaining question is: where is the :443 originating from in the Acme Challenge url?
If no port is included, the default port for the service requested is implied (e.g., 443 for an HTTPS URL, and 80 for an HTTP URL).
Note that that only goes one direction. AFAICT it's allowed for clients to send Host: example.com or Host: example.com:443, at their discretion. And depending on implementation details it's quite possible servers would respond differently based on that.
Some real-life Let's Encrypt users on lighttpd ran into issues with extraneous port numbers being sent, back in 2015:
Based on the above, I believe it's the case that Go's net/http library won't strip :443 (or :80) from hosts in URLs. I quickly peeked at the source for net/http and that seems to be the case, though I haven't confirmed with a test.
That means if you redirect to https://example.com:443/, your server will see Host: example.com:443. If you redirect to https://example.com/, your server will see Host: example.com. I believe this is a valid implementation choice for Go, even though curl and possibly other implementations seem to differ.
As @MikeMcQ says, the kinda-superfluous port in the redirect URL is probably an issue with your code that redirects to HTTPS. Perhaps that's a RewriteRule in your Apache config?
It's worth noting, there are two possible fixes: your system that looks up challenges could detect and handle port numbers; or you could change your redirect logic not to add the :443.
I'm still not sure what could have changed to trigger this issue. AFAIK the way net/http handles port numbers hasn't changed recently. We did upgrade from Go 1.17 to Go 1.18 recently, but looking at the release notes there are no relevant changes.