What you see
The first sign is usually a hard TLS failure, not a clean warning. A service that worked before the rotation starts throwing validation errors, and the client stops before it gets far enough to be useful.
Two common causes usually sit at the front of the queue. The device never received trust store updates, or the application has certificate pinning tied to the old hierarchy and will not accept anything else.
If the device is old enough, both can be true at once. That is when the failure looks random to anyone who only checked a current desktop browser.
Where it happens
The chain often fails at the intermediate layer before it reaches the root. A cross-certificate may bridge the old and new roots for one client, then disappear from the path a different client actually builds.
TLS certificate validation is strict about the path it accepts. If the client trust store only knows the older root, and the server presents a chain that no longer fits that path, validation stops there.
Hard-coded anchors cause the same sort of mess. Anything that points validation straight at the 2016 hierarchy will keep doing that until someone changes it.
Find the cause
Check the active root and intermediate chain on the server first. Do not assume the live chain matches what was planned, because deployed certificates and published diagrams often drift apart.
Then compare that chain with the client trust store on the oldest supported device. If the device trusts only the old root set, the new chain can be perfectly valid and still fail every time.
Pinning needs the same treatment. Look for application logic that hard-codes a root, intermediate, or subject name and never learnt to follow a rotated hierarchy.
Fix
Ship the updated trust bundle or the current system CA package to anything that can take it. On managed devices, that is the cleanest fix because it moves validation back into a known trust store.
For older clients that cannot be updated neatly, replace brittle pinning and hard-coded anchors. Pinning to a specific old root tends to break at exactly the point the certificate authority changes it, which is not very convenient but is at least consistent.
If backward compatibility is needed during the transition, use the cross-certificate path that bridges the old and new roots. Do not leave that as a permanent crutch, because it only hides the underlying drift.
Check it’s fixed
Test validation on the oldest supported client, not just on a modern browser that already trusts everything sensible. The old box is the one that will embarrass you later.
Confirm the new chain loads without fallback hacks. If the service only works after manual trust edits, custom exceptions, or a pile of local overrides, the rotation is not really fixed yet.
