tl;dr: machine is unable synchronize its clock because it won't trust the NTP server's DNSSEC certificate because its clock isn't synchronized. Oof.
You'll have to ignore DNSSEC time based validation while you start up, of course... Start with the last time you were properly synced: it's most likely less than a month behind then.
Then take a sampling of certificates offered from well known sites. If the certificates validate, other than time, no reasonable CA that you trust issues not-before dates in the future, so it's not before the most recent not-before date in a certificate. It's probably not much after the not-after dates either, well know sites tend to replace their certificates (but maybe you're getting MITMed with a compromised, old certificate).
Maybe ask for OSCP stapling, which should get you a more narrow range of times. I think OSCP responses are valid for a week? But if you get several from different https servers, chances are good you'll narrow the range.
In the case as suggested that the time was only off by about a day, IMHO, something is seriously wrong if it can't get to sync from there, but I guess I'm not really surprised either.
Years ago I've tried privilege escalation exploit to play with a phone and it involved rolling back date to unexpire signature, so I know there is exploit potential, but it... it just feels like RTC bootstrap problem should be something solvable.
Security protocols (at least the ones in common use) require certificates or keys that eventually expire, because of the risk of a permanent key being compromised. If they expire, the protocol needs time. QED.
While systemd-timesyncd contains a workaround for this, chrony does not seem to.