I think there should be an option in TLS clients to ignore expiration times, explicitly for cases like this. All other validations are performed, just the not-before and not-after times are waived.
Of all the validations, this one seems like the one that causes problems in edge cases most frequently. I'm definitely not saying that expiry times should be ignored by default; just that client should have the option to do it.
This is obviously a problem for embedded devices, but it even goes to the browser level: when a certificate expired yesterday but is otherwise valid, I as a user want to be able to ignore that and only that error, particularly for a pinned certificate, since it's more likely to be incompetent sysadmin than malicious attacker.
Comments
I think there should be an option in TLS clients to ignore expiration times, explicitly for cases like this. All other validations are performed, just the not-before and not-after times are waived.
Of all the validations, this one seems like the one that causes problems in edge cases most frequently. I'm definitely not saying that expiry times should be ignored by default; just that client should have the option to do it.
This is obviously a problem for embedded devices, but it even goes to the browser level: when a certificate expired yesterday but is otherwise valid, I as a user want to be able to ignore that and only that error, particularly for a pinned certificate, since it's more likely to be incompetent sysadmin than malicious attacker.
This would be the solution I’d go with. For the first DoH call made by NTP after startup, just ignore expiry timestamps.