CertSecure Manager 3.3 är här, och den kommer precis när du behöver den som mest 

Om du har varit i närheten av diskussionen om certifikathantering under det senaste året vet du redan att läget förändras. Livslängden för offentliga TLS-certifikat, hörnstenen i hur webben har fungerat i över ett decennium, förkortas kraftigt. Eran då man "förnya det en gång om året och glöm bort det" är officiellt över. 

CertSecure Manager v3.3 är vår release för denna nya verklighet. Det är en medveten uppsättning förändringar utformade för att hjälpa ditt team att överleva, och helst blomstra, i en värld där certifikat löper ut med några veckors mellanrum istället för var 13:e månad. Låt oss gå igenom vad som har förändrats, vad det betyder för din verksamhet och varför vi byggde varje del som vi gjorde. 

CertSecure Manager v3.3 är byggd för en enda branschrealism: TLS-certifikat Livslängderna minskar från 398 dagar till 47 dagar under de kommande tre åren, och manuell certifikathantering klarar inte av den takten. Versionen innehåller 18 nya funktioner och förbättringar som syftar till den högre förnyelsetakten. 

Rubriktilläggen är en Certifikatrisk Profil som poängsätter varje certifikat i ditt inventarium, fullständig visualisering av förtroendekedjor, massåterkallelse och massöverföring av ägarskap, zero-touch-förnyelse över alla webbserveragenter, inbyggda integrationer med Google Public CA och ServiceNow, utökat stöd för Azure Key Vault inklusive myndigheter, identifiering av AWS och IIS CCS samt en Ansible ACME-automatiseringsväg. Om du använder TLS-certifikat i någon större skala är den här versionen byggd för den värld du är på väg in i. 

47-dagarsskiftet

Den 11 april 2025 antog CA/Browser Forum, branschorganisationen som sätter reglerna som alla större webbläsare och CA följer, omröstningen SC-081v3, ett förslag som ursprungligen lades fram av Apple och stöddes av Sectigo, Google Chrome och Mozilla. Omröstningen godkändes med 29 röster mot 0 och fem nedlagda röster. Alla fyra stora webbläsarleverantörer (Apple, Google, Microsoft och Mozilla) röstade för, tillsammans med 25 certifikatmyndigheter, inklusive DigiCert, Sectigo, GlobalSign, GoDaddy och Amazon. Fem behöriga myndigheter avstod och uttryckte oro över den operativa beredskapen.

Omröstningen stegvis minskar livslängden för TLS-certifikat från dagens maximala livslängd på 398 dagar till endast 47 dagar år 2029. Schemat ser ut så här: 

• Mars 15, 2026: Maximal livslängd för TLS-certifikat sjunker till 200 dagar, och återanvändning av domänkontrollvalidering sjunker även till 200 dagar. 
• Mars 15, 2027: Maximal livslängd sjunker till 100 dagar, och återanvändning av DCV sjunker till 100 dagar. 
• Mars 15, 2029: Maximal livslängd sjunker till 47 dagar, och återanvändningsperioden för DCV sjunker till bara 10 dagar.

Vi har redan passerat den första milstolpen. 200-dagarstaket gäller just nu. 

Varför specifikt 47? Det motsvarar en 31-dagarsmånad, plus en halv 30-dagarsmånad, plus en dags utrymme. Tillräckligt för att stödja en rimlig månatlig förnyelsetakt utan att vara så snäv att operatörerna inte har någon marginal.

Vad detta egentligen betyder för ditt team 

Det är matematiken som väcker folk på natten. En organisation som hanterar 1 000 certifikat kommer att se ungefär 7 766 förnyelser per år enligt 47-dagarsmodellen. Det är ungefär 21 varje dag, en åttafaldig ökning jämfört med dagens förnyelsefrekvens. 

Kalkylblad, kalenderpåminnelser, ”Bob hanterar det där.” Inget av det skalas upp. CA/Browser Forum har inte varit subtilt angående detta: besväret är avsiktligt, eftersom branschkonsensus är att automatisering inte längre är valfritt för internetsäkerheten. 47-dagarscertifikat är hur det meddelandet slutar vara valfritt. 

Det finns tre verkliga skäl bakom förkortningen. 

• Begränsande sprängradie: Om en privat nyckel är komprometterat, ger ett 398-dagarscertifikat angriparen över ett år av användbart missbruk. Ett 47-dagarscertifikat ger dem högst veckor. 
• Att kringgå trasig återkallelse: Röstningen innehåller ett långt argument om att systemet för återkallelse av certifikat använder CRL:er och OCSP är opålitlig, då webbläsare ofta ignorerar dessa funktioner. Korta livslängder är en mer ärlig mekanism än återkallelse som faktiskt inte återkallar. 
• Kryptoagilitet för kvanteran: Kortare livslängder gör det svårare för motståndare att använda taktiker som ”fånga nu, dekryptera senare”, och de påskyndar övergångar till nya kryptografiska algoritmer vid behov. NIST slutförde sina första postkvantstandarder (ML-KEM, ML-DSA, SLH-DSA) år 2024, och offentliggjorde CA testar redan utgivning. Migrering avstängd RSA och ECDSA är inte längre avlägsen. En flotta av certifikat som redan förnyas var sjätte vecka anpassar sig snabbare än en som förnyas var trettonde månad. 

CertSecure Manager 3.3 byggdes med alla dessa tre verkligheter framför oss. Så här visas det i utgåvan.

Se risken innan den ser dig

Om du ska förnya certifikat åtta gånger oftare behöver du en instrumentpanel som faktiskt visar vilka certifikat som är problem innan de blir till incidenter. Tre ändringar i 3.3 samverkar för att ge dig det. 

Certifikatets riskprofil 

 Varje certifikat i ditt lager poängsätts nu automatiskt mot en riskprofil, där poängen visas som en kolumn i dina lagerlistor och som ett filter i certifikatsökningen. Poängsättningen tittar på tre signaler som historiskt sett har varit källan till mest problem i certifikathanteringen:

• Nyckellängd: Flaggar svaga RSA-nycklar, föråldrade ECDSA-kurvor och allt som understiger nuvarande branschbaslinjer. 
• Signaturalgoritm: SHA1-uteslutningar, svaga hashkoder och allt som inte kommer att överleva nästa utfasningsvåg kommer fram. 
• Giltighetsperiod: Viktigare nu än någonsin, då branschen vandrar nerför stegen från 398 till 200 till 100 till 47 dagar. 

Certifieringar är indelade i fyra nivåer: Säker, Låg risk, Hög risk och Allvarlig. Filtrering, sortering och rapportering på dessa nivåer innebär att du kan ställa frågan "visa mig alla allvarliga certifikat i produktion" och få ett svar på några sekunder istället för efter ett upptäcktsskript och en Excel-pivot. Det ger dig också den ammunition du behöver när en revisor frågar hur du hanterar kryptografisk risk. 

Visualisering av certifikatförtroendekedja 

När en TLS-handskakning misslyckas är orsaken ofta något tråkigt som involverar kedjan. En saknad mellanliggande kedja, en kedja i fel ordning, en inaktuell rot. CertSecure visualiserar nu hela förtroendekedjan för varje hanterat certifikat, direkt från certifikatdetaljvyn.

Rot- och mellanliggande certifikat är tillgängliga inline, där varje kedjeelement är klickbart så att du kan gå in i metadata utan att lämna skärmen. För tredjepartscertifikat stöder systemet att bygga och ladda ner hela kedjan, så att du slipper jaga mellanliggande certifikat över CA-portaler när du behöver driftsätta någonstans nytt.

CA-pinging och systemstatistik

Två ofta förbisedda funktioner kompletterar synlighetshistorien. En ny CA-pingningsfunktion på sidan CA-hantering låter dig övervaka om varje ansluten CA faktiskt är nåbar och felfri. Detta är användbart både för att diagnostisera misslyckade registreringar och för att proaktivt upptäcka CA-avbrott innan användarna gör det.

Och den nya fliken Metrics i Inställningar ger dig övervakning av CPU, disk och RAM i realtid för varje CertSecure-komponent: Automation Agents, CA Connectors och Manager-noder. Du kan lägga till eller ta bort maskiner från vyn för att fokusera på det som är viktigt för din miljö. När automatisering är ryggraden i din förnyelsestrategi är det inte förhandlingsbart att veta att ryggraden är hälsosam. 

Överlev förnyelsetakten med massoperationer

Två länge efterfrågade funktioner landar i 3.3, och tillsammans kommer de förmodligen att vara den enskilt största produktivitetsvinsten från dag ett för de flesta team. 

Massåterkallelse 

Nu kan du återkalla många certifikat samtidigt i en enda operation. Användningsfallen är uppenbara om du någonsin har upplevt dem. 

• Viktiga kompromisshändelser: Om en HSM eller om nyckellagret har intrång måste du återkalla snabbt och fullständigt, inte ett certifikat i taget. 
• Händelser med misstro i Kalifornien: Om en certifikatutfärdare hämtas från en rotlagring (det händer, fråga vem som helst som har upplevt DigiNotar, Symantec eller något av flera nyare exempel), måste du omedelbart rensa de berörda certifikaten. 
• Rutinmässig städning: Föråldrade testcertifikat, pensionerade tjänster, gamla miljöer. Återkalla dem i bulk och gå vidare. 

Massöverföring av ägarskap 

Ägarskapsposter för certifikat ändras ständigt. Folk slutar, team omorganiserar och applikationer omtilldelas. I version 3.3 kan du överföra ägarskap i bulk över många certifikat samtidigt. Det här är den typen av funktion som låter liten tills du har ägnat två dagar åt att klicka igenom enskilda certifikatposter för att uppdatera ägarens e-postadress efter en omorganisation. 

Båda dessa funktioner var redan användbara i en 398-dagars värld. I en 47-dagars värld är de bordsinsatser. 

Automation som täcker plattformarna som de flesta verktyg glömmer 

Automatisering fungerar bara om den fungerar överallt, och historiskt sett har automatiseringsverktyg varit mycket starka för de enkla målen och mycket svaga för de obekväma. CertSecure 3.3 täcker några av de mest efterfrågade luckorna. 

Förnyelseautomation för Citrix NetScaler, JBoss EAP och Wildfly 

Helautomatiserad certifikatförnyelse omfattar nu även Citrix NetScaler, JBoss EAP och Wildfly. Avgörande är att automatiseringen hanterar hämtning av kedjecertifikat som en del av förnyelseflödet, så att agenten hämtar rätt mellanliggande certifikat och skickar dem till rätt nyckellager eller konfiguration utan att användare behöver ladda ner kedjepaket separat och sammanfoga dem manuellt. Den sista detaljen är viktigare än den låter: felkonfiguration av kedjor är en av de vanligaste orsakerna till misslyckade distributioner. 

Zero-touch förnyelse över alla webbserveragenter

Alla CertSecures webbserverförnyelseagenter stöder nu zero-touch-förnyelse. Det innebär att en certifikatförnyelse kan ske från CA-registrering till leverans, installation och omladdning av tjänsten utan någon människa inblandad. Det är den enda hållbara modellen när du förnyar var sjätte eller sjunde vecka.

Ansible Desired State Management med ACME-modulen

För miljöer som föredrar infrastruktur som kod introducerar 3.3 en ny automatiseringsväg med hjälp av Ansible. ACME modul. Du deklarerar önskat tillstånd för dina certifikat i din Ansible-konfiguration, och systemet hanterar att hämta och förnya TLS-certifikat från valfri ACME-kompatibel certifikatutfärdare, vilket håller det faktiska driftsatta tillståndet i linje med det deklarerade. Det är rätt mönster för team som redan kör Ansible i stor skala. 

Möt certifikat var de än bor 

CertSecure 3.3 utökar utbudet av CA:er, valv och system som du kan hantera internt.

Google Public CA-integration 

Google Public CA är nu en förstklassig integrerad CA. Fullständig livscykelhantering (utgivning, förnyelse, återkallelse, inventering) fungerar mot Google Public CA precis som mot dina andra CA:er. För organisationer som använder GCP tjänster eller vill ha ett ytterligare offentligt CA-alternativ, eliminerar detta ett betydande integrationsgap. 

ServiceNow-appen, nu i butiken 

CertSecure-appen för certifikathantering för ServiceNow finns nu tillgänglig i den officiella ServiceNow-butiken. Det här är en mycket större sak än det låter: de flesta arbetsflöden för företagscertifikat är redan grindade via ITSM-ärendeflöden. Integrationen låter användare begära, registrera, generera och ladda ner certifikat inifrån sitt befintliga ServiceNow-arbetsflöde istället för att behöva lära sig en ny portal. Mindre friktion, snabbare hantering, färre ärenden som väntar eftersom någon inte visste vilket verktyg de skulle öppna.

Azure Key Vault: Myndighetsklienter och uppladdning med ett klick 

Azure Key Vault stödet har utökats i två viktiga riktningar. 

• Statliga hyresgäster får nu stöd, med fullständig rollbaserad åtkomstkontroll (RBAC) för certifikatuppladdningar. Detta är avgörande för reglerade kunder och kunder inom den offentliga sektorn som arbetar i Azure Government. 
• Uppladdning med ett klick låter dig skicka certifikat till Azure Key Vault antingen vid registreringstillfället eller för alla redan registrerade certifikat. Det som tidigare var en manuell överlämning i flera steg är nu en knapp. 

DigiCert: anpassade giltighetsperioder

DigiCert-kunder kan nu ange en anpassad giltighetsperiod vid registrering. En liten ändring, ofta efterfrågad och särskilt relevant eftersom branschen går igenom livslängder i faser. "Anpassa min förnyelse till mitt driftsättningsfönster" blir ett mer nyanserat beslut.  

Upptäckt utan manuell jakt 

Du kan inte hantera det du inte hittar. CertSecure 3.3 har två anmärkningsvärda utökningar. 

• AWS Cloud Discovery är nu aktiverat. Certifikat som finns i AWS, inklusive ACM, IAM och lastbalanserare kan automatiskt hämtas till CertSecures inventering istället för att spåras separat. 
• IIS CCS-butiksidentifiering stöds nu. För miljöer med tunga Windows-funktioner som använder IIS Centralized Certificate Store kan certifikat i CCS-resurser nu inventeras direkt. 

När certifikat finns i lagret visas tredjepartscertifikat nu i sina egna synliga behållare under Lager → CertSecure, filtrerbara via filtret Certifikattyp. Du kan köra samma operationer på dem som du skulle göra på internt hanterade certifikat: ladda ner, visa kedja, leverera via e-post, byta behållare. Detta stänger en av de återkommande luckorna i certifikathanteringen. Mer specifikt problemet "vi har några certifikat från externa certifikatutfärdare, och vi spårar dem på sätt och vis i ett annat kalkylblad". 

Rapporteringen har också ett nytt mallfilter i lager- och utgångsrapporterna, så att du kan dela upp ditt lager efter certifikatmall. Detta är användbart för miljöer med många mallar som tjänar olika syften, där "alla mina webbservermallcertifikat löper ut om 30 dagar" är frågan du faktiskt vill ställa. 

Och om du någonsin har tillbringat tio minuter med att leta igenom dokumentationssidor för ett specifikt avsnitt, har UI-dokumentationen nu en inbyggd sökning. 

Smidigare registreringsmoment 

Ett par mindre men genuint användbara förändringar. 

PFX-nedladdning med uppladdning av privat nyckel för CSR-registrering. När du registrerar dig via CSR, du kan nu ladda upp din privata nyckel under registreringsprocessen och ha CertSecure generera en nedladdningsbar PFX-fil. För destinationer som behöver PFX (och det finns fortfarande många) sparar detta ett separat openssl-steg på din bärbara dator. 

Leverans av DigiCert-certifikat via e-post har åtgärdats för ett känt edge-fall, och ett antal ytterligare buggar i registreringsvägen har åtgärdats. Beteendet "ignorera mall" har också korrigerats. 

Vad händer härnäst 

En snabb kommentar om vart vi är på väg, för arbetet slutar inte med den här utgåvan.

Fortsatt automatiseringsdjup är det största temat. I takt med att 100-dagarscertifikat blir standard i mars 2027 kommer vi att lägga till fler distributionsmål och mer sofistikerade orkestreringsmönster. Om det finns en plattform i er stack som vi ännu inte automatiserar, berätta det för oss. Den feedbacken formar färdplanen. 

Post-kvantkryptografisk beredskap är den andra. Riskprofilen, noll-touch-förnyelse och orkestreringsgrunden i 3.3 är det som skapar en framtid PQC-migration hanterbar. När man kan förnya en hel flotta automatiskt blir algoritmbyte en konfigurationsändring snarare än ett projekt som sträcker sig över flera kvartal. Explicita PQC-funktioner är under utveckling, och vi kommer att dela mer i kommande utgåvor i takt med att det offentliga CA-ekosystemet standardiserar sina PQC-utgivningspraxis. 

Discovery-expansion är den tredje. AWS Cloud Discovery och IIS CCS ansluter sig till discovery-listan i 3.3, men det finns fler moln- och lokala certifikatarkiv att täcka. Vi arbetar oss igenom dem. 

Hur du uppgraderar 

CertSecure Manager v3.3 är tillgänglig nu. Om du redan använder en nyligen utgiven version är uppgraderingsvägen enkel. Ditt Encryption Consulting-kontoteam kan guida dig genom miljöspecifika överväganden och eventuell sekvensering för HA-distributioner. 

Om du inte är på än CertSecure-hanterare, tidpunkten är verkligen värd att fundera över. Övergången från 200-dagars till 100-dagars certifikat sker i mars 2027, mindre än ett år senare. Organisationer som väntar tills 47-dagars certifikat faktiskt är obligatoriska 2029 innan de börjar automatisera kommer att göra det under press. Organisationer som bygger en fungerande automatiseringsgrund nu, genom 200-dagars- och 100-dagarsfaserna, kommer att anlända till 2029 med en infrastruktur som redan fungerar. 

Om någon av funktionerna ovan låter som att de löser ett problem du har haft, kontakta Krypteringskonsulting team för en genomgång av er miljö. 

Och, som alltid, tack till alla kunder som skickade in ett ärende, ställde den svåra frågan eller insisterade på att den befintliga lösningen inte var acceptabel. Det mesta av det som står i 3.3 kan spåras tillbaka till dig.