Webbcertifikatens livslängd ska förkortas kraftigt

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.

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.

Det är också lätt att glömma att "Applikationsserver" är lite halvlöst definierat och otroligt många av dem serverar publika sidor till webbläsare. Hur många gamla Tomcats tror du inte ligger och bara tuggar på mellan omstarterna för att minnet tagit slut?