💾 Archived View for bbs.geminispace.org › u › skyjake › 1128 captured on 2023-09-08 at 18:57:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
Re: "Expiration of self-signed certificates Does it make sense..."
I think 99991231235959Z would make sense as a default for client certificates, and why not for server certificates as well.
IMO, having the ability to set an expiration date is still useful for special use cases, like when you want to have a throwaway identity that expires in a month, or there is some sort of service that is only supposed to be available for a fixed period of time.
2023-05-27 · 3 months ago
@skyjake Cool, then consider this a feature request for Lagrange, to have that as the default for new client certs!
I guess you're right that in the rare circumstance that you really know the identity should expire after some fixed time, it could make sense to set Not After, because it saves you from having to securely delete the certificate and lets the server know that it can safely forget about you. I'm not sure that having this option is worth all the headaches it can cause, though.
self-signed certs are often created for 10 years, some are created for 1 year, I am not sure which date format is actually supported, this may have an issue similar to the 2037 problem
@mbays
— /s/Lagrange-Issues/issues/22
Expiration of self-signed certificates Does it make sense to use Not After on self-signed gemini server and client certificates, so that they expire after some time? I long ago came to the conclusion that it doesn't make sense, but it still seems to be standard practice, so I'm worried that I may have missed something. Have I? Certainly you shouldn't expect a self-signed certificate to be usable forever -- the private key might be compromised one day, and anyway the underlying encryption will