I just find it incredible that in 30+ years the industry hasn't adapted one bit to the brittle failure modes of certificates. I did some subcontract work with Verisign to deploy their CA infrastructure back in the early oughties and it felt like a solution was overdue way back then. I was at Google in the teensies when gmail broke due to expired SMTP certs. WAAAY overdue by then. Here we are, a decade later and it's still the same lol.

▲

yjftsjthsd-h 11 hours ago | parent | next [-]

Other than automating renewal - which we have made huge strides on - what adaption would you want to see?

	▲	jcims 8 hours ago \| parent \| next [-]
		The number one thing for me would be to standardize methods to implement soft failures. Minimally in standard clients and libraries the ability to warn when certs are nearing expiration. Cert extensions to declare lifecycle expectations and possibly even warning endpoints for notification. Basically some way to empirically look at a valid cert and know something is wrong before it fails. There are all sorts of potential privacy/security issues with any feature built in this area so it would have to be done carefully, but I think useful improvements could easily be made.
	▲	AlotOfReading 10 hours ago \| parent \| prev [-]
		I'd like to see better support for networks that aren't connected to the broader internet, or moving away from X.509. Note that these are contradictory. X.509 was intentionally designed to support offline verification and has a lot of elaborate ceremony to support it (like all the rest of the OSI stack). The industry just doesn't, so we get the worst of both worlds.

▲

packetlost 11 hours ago | parent | prev [-]

I mean, what's the alternative? I struggle to come up with a solution that doesn't boil down to the same primitive operations and trust model.