Webbcertifikatens livslängd ska förkortas kraftigt

Men.. Det står ju att den skall sänkas till 200 dagar 2026??

"Tanken är att giltighetstiden för TLS-certifikat först sänks till 200 dagar i mars 2026, sedan till 100 dagar i mars 2027 och till slut till 47 dagar i mars 2029."

Det är vad som maximalt ska accepteras, kortare har alltid varit ok https://letsencrypt.org/2015/11/09/why-90-days/

@jreklund : För någon som inte har full koll på webbcert kan du förklara vad som blir skillnaden med att byta sin privata nyckel eller andra publica nycklar i detta sammanhang.

Jag förstår inte heller varför man ska byta cert, ska inte det vara bundet till en webbadress, då kan väl ingen annan använda den? Kunskapen är låg känner jag på detta med cert.

Det finns så otroligt många konstiga processer för att få in ett certifikat i något avartsformat i applikationsservrar från förr!
Applikationsservrar som aldrig dör!

Jag undrar om jag kan vrida min konsultprofil till att jag är expert på att lösa det här problemet (Caddy i container som reverse proxy) och sen ha underhållsavtal på lösningen (bumpa Caddy-versionen en gång i kvartalet).

Hahaha, ja det ska bli skoj att se hur alla olika tillverkare löser så att deras produkter kan uppdatera certifikat automatiskt...

En helt annan punkt... Johan kan inte vara nöjd över den bilden alltså

När någon snor ditt certifikat är det inte säkert att du roterar dina privata nycklar. När du återkallar ditt stulna certifikat och du återanvänder nyckeln kan förövaren fortsatt använda din privata nyckel till att dekryptera informationen på de nya certifikaten.

Om du vid varje förnyelse blir tvingad att byta privat nyckel måste förövaren alltid ha åtkomst till servern. Du täppte förhoppningsvis förra hålet.

Den här artikeln förklarar det bättre: https://trufflesecurity.com/blog/10-of-tls-certificates-reuse...

Edit: Angående att byta certifikat kan du på domännivå gjort misstaget att använda CNAME/A-rekord till en adress du inte längre äger och förövarna tar över den istället och installerar det stulna certifikatet på.

Tack. Då blev jag lite smartare idag. Länken var bra också.

Detta gäller väl ändå publika webbcertifikat. Interna system kan väl fortsätta använda egenutfärdade certifikat, eller vad menar du?
Enda skillnaden är intervallen (och att det troligen kommer kosta lite mer), den IT-avdelning som inte har koll på när certifikat löper ut och agerar först när användare ringer in och gnäller är inte värt namnet.

Min fråga var.
Vad är Maximalt nu?

Ja.

Det är ju ännu värre om någon har din privata nyckel, för då kan de använda det nya certet precis som de kunde med det gamla

Det är lätt att glömma att 47 dagar gäller cert för webbläsare, både på desktop och mobiler.

För applikationsservrar spelar det ingen roll. För öst/väst mellan sådana system kan du köra cert hur du vill. Det är först när du vill att webbläsare ska blandas in du behöver hantera kortare certifikatlivstider. Då är ett tips att du kastar in en reverseproxy som hanterar användar-vända cert (typ caddy, traefik et c).

Jag kan varmt rekommendera smallstep-ca (step-ca) med aktiverad ACME-endpoint. Då kan du skapa ett intermediate-certifikat för din interna CA och låta interna system få interna certifikat den vägen.

Är det något som hindrar att du har en lokal certifikatstjänst med godtyckliga regler för livslängd? Det löser väl detta problem?

Ett år plus några dagar.

Certifikatet består av en publik nyckel som signerats av någon som båda parter litar på. I teorin finns inget som hindrar att du genererar en certifikatsbegäran baserad på en privat nyckel du återanvänt. Det vore dumt, men det finns inget tekniskt hinder för det så länge den är stark nog för att uppfylla dagens krav.

Med moderna automationsverktyg sköts detta åt dig så det är lättare att göra rätt än fel.

Certifikatet består av bland annat utfärdandedatum, giltighetstid, domän som certifikatet är giltigt för, innehavarens publika nyckel, utfärdarens (CA'ns) certifikats identifier, samt en signatur skapad av utfärdaren genom att skapa en hash av certifikatet och "dekryptera" den genom att applicera utfärdarens privata nyckel. På så vis kan man verifiera att certifikatet verkligen är utfärdat (och omodifierat) av den angivna utfärdaren genom att applicera utfärdarens publika nyckel (som man får från utfärdarens certifikat) på signaturen och sedan jämföra med certifikatets hash. Utfärdarens certifikat finns antingen i operativsystemets CA trust store, eller skickas tillsammans med servercertifikatet som en del av en certifikat-chain. I det senare fallet är utfärdarens certifikat då i sin tur signerat av en CA vars certifikat ska finnas i operativsystemets CA trust store. En klient avgör att ett certifikat "går att lita på" om dess utfärdare/signatur kan verifieras hela vägen till operativsystemets CA trust store.

Det finns dock många interna system som användarna kommer åt via webbläsaren, så om webbläsaren i sig slutar lita på cert med längre giltighetstid (även om de litar på den interna CA:n) kommer det ställa till problem. Det går såklart att lösa (reverse proxy t.ex.) men det är inget som många IT-avdelningar kommer ta tag i förrän det blir kris och panik.

Håller med. 200,100,50,20… spelar ingen roll. Redan ett år är nästan för dåligt, jag har helt ärligt tappat räkningen på hur många driftstörningar jag varit med om där ett utgånget cert varit problemet. Vi snackar hundratals.

Så helt enkelt, ska man börja pusha giltighetstid nedåt så måste man automatisera, det går inte (ja eller allt går ju beroende på vad man tycker är kul att göra om dagarna) att sitta och manuellt uppdatera cert med 100 dagars giltighetstid.

På min förra arbetsplats hade bara mitt team runt 200 cert ”i drift”. Skulle vi haft manuella rutiner hade någon alltså behövt sitta och förnya och byta cert i stort sett varje arbetsdag.

Men det är ju varför vi får flera års varning: människor kommer att agera som människor, men klokt nog blir det jobbigare och jobbigare att skjuta detta framför sig tills det blir ohållbart. Status quo är uppenbart inte bra nog, så det är bra att folk med makt och kompetens att göra så vågar bryta situationen.

Har jobbat med support för certifikatlösningar och det var inte bara utgångna cert som orsakade problemen. Ett tråkigt område att ha hand om och ingen rolig period i arbetslivet då felorsakerna var så skiftande. Förhoppningsvis är dagens applikationer bättre/stabilare och att det finns automatiska hjälpmedel låter ju positivt.

I vårt team har vi ett hundratal certifikat och jag har alltid varit ensam i teamet, så automatisering har varit självklart från start

Jag har visserligen automatiserat certifikathanteringen, men det betyder egentligen bara att jag har skapat ett cronjob som kör ett program, som i sin tur uppdaterar nödvändiga certifikat. Vad detta program (acme.sh i mitt fall) gör har jag inte den blekaste aning om, så när det slutar fungera, så har jag ingen aning om hur jag ska få tag på nya certifikat och måste ChatGPT:a fram en ny lösning baserad på tredjepartskod.

Jag hatar allt som har med certifikat att göra, men det beror endast på att jag har så fruktansvärt dålig koll på det tekniska. Jag jobbar primärt som utvecklare, så serveradministrationen är bara något jag pysslar med när det behövs. Vilket säkert låter skrämmande för er på stora företag med flera team, men så ser verkligheten ut på ett litet företag

Detta är otroligt vanligt, skulle jag påstå. Samtidigt måste det ju ligga i en utvecklares egenintresse att förstå protokollen deras program använder? Exemplet jag gav i ett tidigare inlägg, med Javaprogram där certifikat måste skötas helt manuellt, kan jag inte tolka på något annat sätt än att någon överarbetad stackare fått order om att företagsdata ska vara ”encrypted in transit” för att man själva eller någon partner kräver detta av produkten, och så de läst exakt vad man behöver göra för att komma dit utan att läsa stycket om vad en publik certifikatsauktoritet gör.