The cross-functional communication required to deal with short certificate lifecycles

My working title for this piece was 'short certs and a long jacket' because within a couple of years you're going to be rolling public certs monthly and it's going to take a long list of people and teams working together to make that happen seamlessly without outages, burnout or a few blamefests.

Certificate revocation is, as everyone politely phrases it, fraught (the less polite version is broken) so cert lifecycle is getting short enough that it doesn't matter; this touches so many teams inside organizations that CIOs need to make the conversations happen now to be ready in time for 2029.

My thanks for @daveon.bsky.social for details about how organizations are starting to care about TLS expiration dates, @cpswan.net Swan for the view from an organization that already renews certs at enormous scale

and to Chris Hickman for pointing out so clearly that this is as much about internal processes as technology for automation, and Jeff Hagen for some great details about the nitty gritty of how to proceed with getting ready for monthly TLS cert renewals

you can't manage it, cap, that's my secret: you have to automate it! go ACME, have the system autorenew when it hits the renewal window, don't use public certs when you don't have to AKA *know your use cases* and *know you certs*

can't remember if I had space for the quote which was basically 'if you lot were any good at managing your certs in the first place, we wouldn't have to force you into getting good at managing certs by making them last for shorter and shorter periods'

I also couldn't fit in the point that 47 days isn't the end of this; once people can cope with that it could easily go down to 10, so weekly expiry (look at DNS TTLs)

Most of my sources think 10-day certs are the likely end state and point at DNS TTL

If you need a public cert that you spend money on - or even a free cert from Let’s Encrypt then you can automate it with ACME. There is a ton of cert management software. There are tools for this. Orgs just need to stop misusing expensive public certs, centralise them on load balancers and automate

“Just” handwaves all the internal conversations like “who owns this application and what is its GUI for updating the cert is uses” and “are all the devices we provision certs on managed and yes that has to include the CEO’s devices”

I could have written a piece three times as long and included all of this! internal certs are trending to one year expiry currently (ahead of schedule but might stick there); no point in expiring public certs faster that current guidance because you'd be paying twice for the same cert

but if you move the public certs to your load balancers then use private certs to connect to those, you can expire as fast as you feel comfortable

Hey @robin.berjon.com @bkardell.com you have probably both spotted this long before I did but the browser (cough Chrome cough) capture of CABF (including things previously IETF like mTLS) is another thread in that future funding and governance of browsers discussion

I was surprised that one of my sources actually mentioned it spontaneously; like hey, has anyone else noticed this shift of power and I was 'dang, I have such a tight commission on this piece it's ok of scope but YES'

At root (hah), the question is how big would you have to be to say “Google’s not the boss of me” and *could you get big enough to say it* while taking a route Google has decided is out of bounds

you know, just last summer I was saying that cert lifecycles were only getting shorter so orgs needed to have the conversations and build the muscle to be able to deal with cert changes at short notice in case something bad happened...