Certificates shouldn’t expire on a specific date. As they age, they should trigger increasingly painful delays in TLS negotiation until someone looks into the problem and replaces them.
-
-
Also a good idea!
-
As a one-time RFC author (ask me for the errata), please standardize both thank you.
- Show replies
New conversation -
-
-
Whynot both?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Like random decay? The mean time will be normally distributed around some time in the future? Could expire in three hours, or twenty years. Make Certbot work for it.
-
Per-request decay! At half-life, half of requests fail. That way retrying keeps functionality up. But you are heavily incentivized to fix things!
- Show replies
New conversation -
-
-
Including being toxic if you touch them
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Perhaps the universe implemented your idea already

Just use neutrons as certificates (for existence of energy sufficient for producing the corresponding particle). 
-
TLS authentication by HL-PUF - proving possession of a Physical Unclonable Function with a half-life.
End of conversation
New conversation -
-
-
OTOH if client certificate validation required OCSP stapling then does it even need an expiration date?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
You mean one starts with a RSA-4096 key and after a year it deteriorates to a 2048 bit key?
-
So basically all the old implementations with sidechannel attacks
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.