Den 13 maj 2026 genomförde Let's Encrypt tre förändringar i sin produktionsmiljö samtidigt. Var och en är hanterbar var och en. Tillsammans, och särskilt i samband med utfärdandeincidenten som föregick dem fem dagar tidigare, levererar de ett tydligt budskap till alla som ansvarar för certifikat: eran där certifikathantering behandlades som tillfälligt pappersarbete är över. Certifikatdrift håller på att bli infrastruktur, och de organisationer som inte har gjort den förändringen är de som kommer att känna varje framtida förändring som en kamp.
Den här bloggen går igenom vad som förändrats, varför ett kort avbrott några dagar tidigare är viktigare än dess korta varaktighet antyder, och vad dessa händelser säger oss om vart certifikathanteringen är på väg i hela branschen.
En snabb sammanfattning: Incidenten den 8 maj
Fem dagar före de planerade ändringarna stoppade Let's Encrypt all certifikatutgivning. Pausen varade i ungefär två och en halv timme innan utfärdandet återupptogs. Grundorsaken visade sig vara ett konfigurationsproblem i nyligen utfärdade korssignerade mellanliggande certifikat: de saknade obligatoriska fält för utökad nyckelanvändning. Åtgärden var att återkalla och utfärda de berörda mellanliggande certifikaten på nytt med rätt fält på plats. Viktigt är att inga slut-entitetscertifikat, certifikaten som distribuerats på servrar, återkallades eftersom de förblev kompatibla på egen hand.
För att hantera den resulterande vågen av förnyelser smidigt förlitade sig Let's Encrypt på ACME Renewal Information (ARI), ett protokolltillägg som låter en certifikatutfärdare berätta för ACME- klienter när de ska förnya. Istället för att alla drabbade klienter skulle förnya samtidigt och överbelasta systemet, spred ARI förnyelserna över ett kontrollerat fönster. För klienter som stöder ARI hämtades den korrigerade kedjan automatiskt vid nästa schemalagda körning, utan att någon manuell åtgärd krävdes.
Incidenten löstes utan problem, men det lämnade en lärdom efter sig som är värd att hålla fast vid. Kedjeverifiering är inte längre en engångsuppgift för installation. Rötterna ändras, korstecken repareras och förtroendebutiker uppdateras enligt sina egna scheman. Att verifiera att din certifikatkedja är korrekt måste vara en kontinuerlig, loggförd del av din förnyelseprocess, inte en kontroll begravd i en distributions-runbook skriven för flera år sedan.
De tre förändringarna den 13 maj
1. Tlsserver-profilen sänktes till 45-dagars certifikat
Opt-in tlsserver-profilen började utfärda certifikat som endast var giltiga i 45 dagar. Denna profil riktar sig till tidiga användare som vill stresstesta sin automatisering mot en kort förnyelsekadens innan den blir oundviklig. Det är framkanten av ett mycket större branschförändring, vilket gör den till en användbar provningsplats. Om din automatisering kan hantera ett 45-dagars certifikat idag, kommer den att överleva det som komma skall för alla.
Den operativa haken är subtil men allvarlig. Många ACME-klienter är konfigurerade att förnya ett fast antal dagar före utgången, ofta 30 dagar. För ett 90-dagars certifikat går det bra att förnya 30 dagar innan certifikatet löper ut, eftersom det utlöses ungefär två tredjedelar av certifikatets livslängd. För ett 45-dagars certifikat skulle samma inställning försöka förnya efter bara 15 dagar i tjänst, vilket automatisering kan behandla som ett fel och hoppa över, ibland tyst. Certifikatet löper sedan ut utan förnyelse. Det korrekta tillvägagångssättet är förnyelselogik baserad på en bråkdel av certifikatets livslängd, eller ännu bättre, driven av ARI så att CA själv signalerar rätt förnyelsefönster.
2. Tlsclient-profilen började stängas av
tlsclient-profilen, som används för att utfärda certifikat för TLS-klientautentisering, frystes den 13 maj. Befintliga konton som redan hade använt den kunde fortsätta tillfälligt, men inga nya konton beviljades åtkomst, och en hård avstängning sattes till den 8 juli 2026, varefter profilen försvinner helt.
Denna förändring är inte en Let's Encrypt-säregenhet. Den härrör från ett bredare krav på rotprogram, drivet av stora webbläsar- och operativsystemleverantörer, som kräver att TLS- klientautentisering och TLS-serverautentisering separeras i separata infrastrukturer med publika nyckelringar. Den praktiska konsekvensen är betydande: alla system som förlitade sig på ett Let's Encrypt-certifikat för att autentisera en klient till en server, såsom intern ömsesidig TLS, vissa XMPP-tjänster eller applikationer som hanteras av klientautentisering, kommer att sluta fungera när profilen är borta.
Det svåra är sällan själva migreringen. Det handlar om att veta var dessa certifikat finns. Klientautentiseringscertifikat distribueras ofta av enskilda applikationsteam för specifika integrationer och dyker aldrig upp i centrala PKI- inventeringar. Att hitta dem kräver identifiering som kan filtrera efter utökad nyckelanvändning, vilket visar certifikat efter deras faktiska konfiguration snarare än efter värdnamn, över moln-, lokala och containermiljöer. När de väl hittats migrerar interna användningsfall vanligtvis till en privat PKI, medan externa fall som verkligen behöver klientautentisering flyttas till en kommersiell CA.
3. Den klassiska profilen flyttad till generation Y:s mellannivåer
Den klassiska standardprofilen för ACME, som används av majoriteten av Let's Encrypt-prenumeranter utan någon explicit konfiguration, började kedjas igenom de nya mellanliggande certifikaten från generation Y. För de flesta automatiserade konfigurationer är denna övergång transparent, men den förstärker lärdomen från händelsen den 8 maj: förtroendekedjor förändras under dig, och det enda säkra antagandet är att de kommer att fortsätta att göra det. Organisationer som har fäst specifika rötter eller mellanliggande certifikat i sin egen infrastruktur måste verifiera att deras korssignerade mellanliggande certifikat är aktuella, annars riskerar de valideringsfel i kedjorna som är smärtsamma att diagnostisera.
Den större bilden: Ett branschomfattande skifte, inte en leverantörshändelse
Det vore ett misstag att tolka dessa förändringar som en specifik översyn av Let's Encrypt. De är en förhandsvisning av vart hela ekosystemet för offentliga certifikat är på väg. CA/Browser Forum har satt giltighetstiden för offentliga TLS-certifikat mot 47 dagar år 2029, med mellanliggande minskningar längs vägen. Webbläsarens rotprogram skärper kraven på hur certifikat kan användas. Återkallelse går bort från äldre mekanismer till kortare livslängder som gör återkallelse nästan onödigt, eftersom ett certifikat som bara varar i dagar eller veckor i praktiken löper ut självt.
Varje certifikatutfärdare kommer att gå igenom sin egen version av root-migreringar, profiländringar och livslängdsförkortningar. Nästa är alltid redan igång någonstans. Det är i detta sammanhang som ändringarna från den 13 maj är viktiga långt bortom den totala populationen av Let's Encrypt-användare.
Den djupare frågan som dessa händelser väcker handlar om hur en organisation är byggd för att absorbera dem. Team som behandlar certifikatdrift som infrastruktur hanterar varje ändring som en konfigurationsuppdatering, eftersom deras förnyelser är automatiserade från början till slut, deras inventering sker i realtid och fungerar över alla certifikatutfärdare de använder, och deras kryptoagilitet är en inbyggd egenskap hos deras plattform snarare än ett sidoprojekt. Team som behandlar certifikat som pappersarbete lever i kalkylblad, ärendeköer och åldrande runbooks, och för dem blir varje ändring av certifikatutfärdare ett flerveckors kaos som ingen mängd övertid kan komprimera.
Det är just det krympande giltighetsfönstret som gör att denna klyfta förvärras. En förnyelseprocess utformad kring 90-dagars certifikat överlever inte en 45-dagars kadens, och tiden som finns tillgänglig för att omforma den är kortare än själva tidsfristen. De organisationer som investerar i automatisering nu löser inte bara dagens problem. De bygger den kapacitet som kommer att bära dem genom kortare livslängder imorgon och post -kvantummigreringen efter det.
Hur krypteringskonsulting kan hjälpa
Lärdomen från den 13 maj är att certifikatoperationer måste fungera som en robust infrastruktur. Encryption Consulting tillhandahåller produkterna och expertisen för att bygga just detta.
CertSecure Manager är vår lösning för hantering av certifikatlivscykeln, utformad just för den värld som dessa förändringar beskriver. Den levererar kontinuerlig, CA-agnostisk identifiering i moln-, lokala och Kubernetes-miljöer, så att du kan hitta alla certifikat du äger, inklusive klientautentiseringscertifikat som applikationsteam har distribuerat utanför central PKI och som inte innehåller några kalkylbladsposter.
Dess heltäckande automatisering av utfärdande, förnyelse och återkallelse är byggd för att hantera kortlivade certifikat och höga förnyelsefrekvenser utan de fallgropar med fasta intervall som orsakar tysta fel, och dess centraliserade policytillämpning och realtidsinventering innebär att en rotmigrering eller profiländring blir en konfigurationsuppdatering snarare än en brandövning. Genom att göra kedjeverifiering och utgångsövervakning kontinuerlig snarare än engångshändelse, förvandlar CertSecure Manager den typ av händelse som utspelade sig den 8 maj och 13 maj till en icke-händelse.
För att utöka insynen i hela din kryptografiska miljö upptäcker och inventerar CBOM Secure algoritmer, nycklar och protokoll i din miljö, vilket ger dig en kryptografisk materiallista som stöder både efterlevnad och beredskap för den post-kvantumövergång som följer övergången till kortare livslängder.
På rådgivningssidan hjälper vårt PKI- tjänsteteam till att designa och modernisera företags- och Microsoft PKI-miljöer som i allt högre grad behöver ta över användningsfall som offentliga certifikatutfärdare överger, till exempel de klientautentiseringscertifikat som påverkas av dessa förändringar. Våra krypteringsrådgivningstjänster hjälper dig att bygga en motståndskraftig, automatiseringsfokuserad certifikatstrategi, och våra efterlevnadsrådgivningstjänster håller den strategin i linje med utvecklande regelverk och webbläsarprogramkrav.
Oavsett om ni kämpar med att inventera klientautentiseringscertifikat före juli månads slutdatum eller bygger den långsiktiga automatisering som gör nästa omgång av ändringar till rutin, kan Encryption Consulting hjälpa till. Kontakta oss för att utvärdera era certifikatoperationer och bygga för vad som kommer härnäst.
Slutsats
Förändringarna från Let's Encrypt den 13 maj, och det korta avbrottet som föregick dem, är var för sig små. Deras verkliga betydelse är som en signal. Certifikatens livslängd krymper inom branschen, förtroendekedjor ändras oftare och reglerna för hur certifikat kan användas skärps. Inget av detta saktar ner.
De organisationer som smidigt tar sig igenom dessa förändringar är inte de som arbetar hårdast varje gång en CA tillkännager en förändring. Det är de som slutat behandla certifikat som pappersarbete och byggt upp sina certifikatverksamheter som en automatiserad, observerbar, CA-agnostisk infrastruktur. Den grunden absorberar en 45-dagars kadens, en profilnedgång och en rotmigrering som rutinhändelser, och det är samma grund som kommer att bära en organisation genom den post-kvantumövergång som fortfarande ligger vid horisonten.
Nästa förändring är redan på väg, från Let's Encrypt eller från någon annan del av ekosystemet. Den enda verkliga frågan är om era certifikatoperationer är redo att behandla den som en konfigurationsuppdatering eller om de är dömda att behandla den som ytterligare en nödsituation.
