It's interesting that Ubuntu and RHEL went with very different choices here. Ubuntu decided to patch OpenSSL, so this means if you're relying on the old behaviour (weird, but certainly possible) that's an unexpected change. RHEL decided to explicitly remove trust in DST Root CA X3 even though it isn't actually expired quite yet, which seems less likely to have surprising consequences but does involve taking a patch to the upstream although likely that patch gets removed in a month or two when upstream removes this expired root CA.<p>On the surface the Ubuntu plan is riskier, but, it also carries a richer reward. The old OpenSSL behaviour is silly, even if you wanted that, wanting it is silly, and most likely you had no idea it does this so changing it just makes the library do what you assumed it already did. Ubuntu may eat a handful of "Why did you break our weird software?" tickets now, but avoid several more of these incidents for long-term support over coming months and years, depending on how willing they are to support these older systems for $$$.<p>For admins who have frequent patching either mean it's less likely they run into trouble later this week, and even if they don't patch production (a reasonable caution) knowing that this fix worked in non-production and is available means it's a shorter route from "it broke" to "we applied the patch and fixed it" when it does blow up.
I wonder what effect this will have on non-updated RHEL/CentOS 7 installs (for instance, new installs and/or new docker/podman containers). Do the servers used for the package updates use a certificate chain with this issue, or would a simple "yum update" be enough?