Wildcard-certifikat: Farliga eller enklare att använda?

Nästan hälften av företagen rapporterade certifikatrelaterade driftstopp under det senaste året, och ett wildcard-certifikat som ligger bakom dussintals underdomäner är precis den typen av fel som förvandlar en utgången eller komprometterad nyckel till ett avbrott i en hel miljö. Wildcard-certifikat är fortfarande ett av de mest missförstådda verktygen inom PKI för företag: genuint användbara för att minska certifikatspridning, genuint riskabla när styrning saknas.

Publicerad: december 2021 · Senast uppdaterad: 2026-08-13 · Senast verifierad: 2026-08-13 · Författare: Parnashree Saha, innehållsförfattare · Granskad av Aditi Goel, PKI-säkerhetskonsult

Vad är ett wildcard-certifikat, i ett svar: Ett wildcard-certifikat är ett enda SSL/TLS-certifikat (t.ex. *.example.com) som säkrar en domän och alla dess underdomäner på första nivån under ett certifikat och en privat nyckel. Det minskar förnyelsekostnaderna jämfört med att utfärda separata certifikat, men koncentrerar risken: en komprometterad privat nyckel exponerar alla täckta underdomäner samtidigt.

Sammanfattning

Ett wildcard-certifikat byter certifikatspridning mot koncentrerad risk. Det är rätt val för en definierad uppsättning användningsfall, främst underdomäner med hög volym och låg risk, och fel standard för allt som rör betalningsdata, reglerade system eller en liten stabil lista över produktionsvärdar. Beslutet bör gå igenom en godkännandeprocess, inte en bekväm genväg, och varje wildcard-certifikat i produktion behöver HSM-backad nyckellagring, en aktuell lagerpost och automatisk förnyelse för att överleva CA/Browser Forums övergång till 200 dagars, sedan 100 dagars, sedan 47 dagars maximal giltighet. Team som hoppar över styrning visas i statistiken över certifikatavbrott nedan; team som parar ihop wildcard-användning med kontroller får den operativa fördelen utan exponeringen för en enda felpunkt.

Key Takeaways

• Ett jokerteckencertifikat (t.ex. *.example.com) säkrar en domän och alla dess underdomäner på första nivån med ett enda certifikat och en privat nyckel, vilket minskar den administrativa belastningen på individuell certifikathantering.

• Certifikatavbrott är vanliga och kostsamma: DigiCerts Trust Pulse-undersökning från juli 2025 visade att 45 % av företagen upplevde certifikatrelaterade driftstopp under det senaste året, 37.5 % spårade ett avbrott direkt till ett utgånget certifikat och 31 % av organisationerna rapporterade ekonomiska förluster på 50 000 till 250 000 dollar från certifikatrelaterade incidenter.

• CA/Browser Forums omröstning SC-081v3 (antagen 14 april 2025, godkänd av Sectigo) minskar den maximala giltighetstiden för offentliga TLS-certifikat från 398 dagar till 200 dagar den 15 mars 2026, sedan 100 dagar den 15 mars 2027 och sedan 47 dagar den 15 mars 2029 — jokerteckencertifikat följer samma schema.

• Kärnrisken med alla jokercertifikat är koncentration: en enda komprometterad privat nyckel kan användas för att imitera varje underdomän som certifikatet täcker, så beslutet att använda en är ett risktagandebeslut, inte bara ett bekvämlighetsbeslut.

• Styrning (godkännandeflöden, nyckelskydd, lager, automatisk förnyelse) är det som gör ett wildcard-certifikat säkert att köra i produktion, och samma identifieringsarbete matas direkt in i planeringen av postkvantkryptografi (PQC)-migrering.

Vad är ett wildcard-certifikat?

Ett wildcard-certifikat är en typ av digitalt certifikat som säkrar en domän och ett obegränsat antal av dess underdomäner på första nivån under ett certifikat. Det utfärdas vanligtvis som ett SSL/TLS-certifikat av en offentlig eller privat certifikatutfärdare (CA).

Ett standard SSL/TLS-certifikat är giltigt för exakt ett fullständigt kvalificerat domännamn, till exempel www.example.com. Ett jokerteckencertifikat för *.example.com täcker istället alla underdomäner på första nivån av example.com samtidigt: cloud.example.com, shop.example.com, mobile.example.com och alla andra underdomäner som en organisation lägger till senare, utan att det krävs ett nytt certifikat för varje.

Asterisken i certifikatets vanliga namn är jokertecknet och matchar exakt en underdomännivå. Ett certifikat för *.example.com säkrar finance.example.com och marketing.example.com, men det säkrar inte en underdomän på andra nivån som east.finance.example.com; det skulle kräva antingen ett separat jokertecken för den kapslade nivån eller ett namngivet certifikat.

Varför team använder jokerteckenscertifikat

Wildcard-certifikat finns för att lösa ett specifikt operativt problem: att hantera SSL/TLS-täckning över ett växande antal underdomäner utan en linjär ökning av certifikathanteringskostnaderna.

• Täckning för obegränsat antal underdomäner

  Ett certifikat och en privat nyckel säkrar varje nuvarande och framtida underdomän på första nivån, så att starta en ny underdomän kräver inte en ny certifikatbegäran, väntan på utfärdande eller distributionssteg.

• Enklare certifikatadministration

  Färre certifikat i lagret innebär färre förnyelsedatum att spåra, färre CSR:er att generera och färre kontaktpunkter med distributionen, vilket spelar direkt roll eftersom maximala giltighetsperioder krymper enligt CA/Browser Forums schema.

• Lägre relativ kostnad i stor skala

  Ett enskilt wildcard-certifikat kostar vanligtvis mer än ett standardcertifikat, men det är oftast billigare än att köpa och förnya individuella certifikat för varje underdomän det annars skulle ersätta.

• Snabbare tid att lansera nya underdomäner

  En ny underdomän under ett befintligt jokertecken är aktiv så snart den har driftsatts, utan att något certifikatutfärdande steg blockerar lanseringen.

Wildcard vs. SAN vs. certifikat för en enda domän: Beslutstabell

Innan du distribuerar ett jokerteckencertifikat, jämför det med de två alternativ som de flesta team faktiskt väljer mellan. Den här tabellen mappar varje alternativ till den operativa ägaren som ska godkänna och det resultat som kan förväntas.

Användningsfall	Rekommendation	Operativ ägare	Förväntat resultat
Många lågriskiga, ofta föränderliga underdomäner (utveckling/testning, marknadsföringsmikrosajter)	Wildcard-certifikat	Plattform-/DevOps-teamet	Låg omkostnad för förnyelse; acceptera koncentrerad sprängradie som avvägning
En definierad, stabil uppsättning produktionsvärdnamn (5–20 namngivna domäner)	SAN-certifikat (multidomäncertifikat)	PKI / Säkerhetsteam	Avgränsad sprängradie begränsad till den namngivna listan; måttligt underhåll när listan ändras
Högsäkerhets- eller efterlevnadssystem (betalningshantering, PHI, myndighetssystem)	Certifikat för en enda domän	Säkerhets-/efterlevnadsteamet	Kompromettering isolerad till en värd; högsta administrativa omkostnader, motiverad av isoleringskrav
Något av ovanstående, på företagsnivå, som närmar sig giltighetsfristen på 47 dagar	Automatiserad utfärdande och förnyelse oavsett certifikattyp	PKI/Säkerhetsteam med plattformsstöd	Förnyelsetakten överlever övergången till maximal giltighet på 100 dagar och 47 dagar utan manuell åtgärd

För en mer djupgående jämförelse av valideringskrav, prissättning och CA-stöd, se Välja rätt SSL-certifikat: Wildcard vs. SAN (multidomän).

Säkerhetsrisker med jokerteckenscertifikat

Bekvämligheten med ett wildcard-certifikat är oskiljaktig från dess centrala risk: varje underdomän det täcker delar samma privata nyckel, så säkerheten för hela uppsättningen beror på säkerheten för den enda nyckeln.

En enda kompromisspunkt

Om den privata nyckeln bakom ett jokerteckencertifikat exponeras kan en angripare imitera vilken underdomän som helst som certifikatet täcker, dekryptera trafik till den och skapa en övertygande nätfiskeinfrastruktur under en betrodd domän. Eftersom samma nyckel vanligtvis distribueras över flera servrar och tjänster kan ett intrång i något av dessa system exponera nyckeln för dem alla.

Falsk känsla av säkerhet

Wildcard-certifikat kan maskera felaktig server- och DNS-konfiguration. Ett giltigt wildcard-certifikat på en gammal, bortglömd eller oavsiktlig underdomän visas fortfarande som betrodd av en webbläsare, vilket innebär att användare kan hamna på inaktuell eller övergiven infrastruktur utan någon certifikatvarning som flaggar problemet.

Certifikatavbrott och operativ risk

Certifikatrelaterade avbrott är redan vanliga i hela branschen. DigiCerts Trust Pulse-undersökning från juli 2025 visade att 45 % av företagen upplevde certifikatrelaterade driftstopp under det senaste året, varav 37.5 % av dessa avbrott var specifikt kopplade till utgångna certifikat. Samma undersökning visade att 31 % av de drabbade organisationerna förlorade mellan 50 000 och 250 000 dollar på grund av certifikatrelaterade incidenter, och 18.5 % förlorade mer än 250 000 dollar. Ett wildcard-certifikat koncentrerar den risken ytterligare: eftersom ett certifikat vanligtvis ligger bakom många tjänster, tar ett utgånget eller felkonfigurerat wildcard inte ner en enda webbplats, det kan ta ner alla underdomäner som är beroende av det samtidigt.

Återkallelsekomplexitet

Att återkalla ett jokerteckencertifikat påverkar alla underdomäner det täcker samtidigt. Det finns inget sätt att återkalla täckningen för en enskild komprometterad eller avaktiverad underdomän utan att utfärda och distribuera certifikat på nytt över hela den återstående uppsättningen.

Ägare/Handlingsmatris: Vem gör vad

Styrning av jokerteckenscertifikat omfattar mer än ett team. Denna matris mappar de nödvändiga åtgärderna till det team som ska äga varje enskild åtgärd.

Team	Åtgärd som krävs	Varför det gäller
PKI / Säkerhetsteam	Ansvarar för godkännandeundantagsprocessen för nya jokerteckenförfrågningar; tillämpa skydd av privata nycklar (HSM-baserad, ej exporterbar)	Utfärdande av jokerkort bör vara ett undantag, inte en standard, med tanke på den koncentrerade explosionsradien.
Plattform-/infrastrukturteamet	Upprätthåll en korrekt och aktuell inventering av alla system där ett jokerteckencertifikat används	Du kan inte rotera, återkalla eller förnya en nyckel mellan system som du inte har inventerat.
Compliance-teamet	Mappa användning av jokerteckenscertifikat till PCI DSS, HIPAA, DORA eller andra tillämpliga krav för certifikatinventering	Regelverk kräver i allt högre grad dokumenterade, kontinuerligt underhållna certifikatinventarier, inte punktvisa revisioner
Säkerhetsoperationer	Övervaka loggar för certifikattransparens för obehörig utfärdande av jokertecken mot ägda domäner	Ett jokerteckencertifikat som utfärdats utan auktorisering är en direkt signal om komprometterat certifikat eller att CA-processen har misslyckats

Snabb checklista innan du distribuerar ett jokerteckencertifikat

Använd den här checklistan innan du godkänner eller förnyar ett jokerteckencertifikat i en produktionsmiljö.

• Bekräfta att en dokumenterad affärsmotivering finns och har gått igenom undantagsgodkännandeprocessen, inte standardutfärdandevägen.

• Bekräfta att den privata nyckeln genereras och lagras i en certifierad HSM, markerad som ej exporterbar.

• Bekräfta att varje underdomän som certifikatet täcker är identifierad och dokumenterad före utfärdande, och inte upptäckt i efterhand.

• Bekräfta att automatisk förnyelse är konfigurerad så att certifikatet inte är beroende av en manuell process för att överleva övergången till kortare giltighetsperioder.

• Bekräfta att certifikatet är registrerat i ett aktuellt kryptografiskt inventarium med en tilldelad ägare, utgivningsdatum och utgångsdatum.

• Bekräfta att det finns en återkallnings-runbook som tar hänsyn till varje underdomän som jokertecknet täcker, inte bara den primära domänen.

Hur automatisering minskar risken för certifikatavbrott

Manuell certifikathantering skalas inte mot CA/Browser Forums giltighetsschema, och jokercertifikat gör det gapet mer synligt, inte mindre, eftersom en enda missad förnyelse har en större explosionsradie.

Automatiserad hantering av certifikatlivscykeln eliminerar de två vanligaste orsakerna till certifikatrelaterade avbrott: ett förnyelsedatum som missas eftersom det är beroende av att en person kommer ihåg det, och ett certifikat som distribueras till en server men aldrig uppdateras på en dubblett eller klustrad instans. Genom att automatisera utfärdande, förnyelse och distribution genom domänkontrollvalidering (DCV) och ACME-baserad registrering förvandlas en 47-dagars giltighetsperiod från en driftskris till en schemalagd, obevakad händelse.

Det är också här som jokercertifikat specifikt gynnas mer av automatisering än namngivna certifikat: eftersom ett jokercertifikat i genomsnitt ligger bakom fler system, skalas koordineringskostnaden för en manuell förnyelse (att hitta varje distributionsplats, uppdatera var och en, verifiera att det inte finns några tjänsteavbrott) med antalet underdomäner den täcker. Automatisering tar bort den koordineringskostnaden helt. Vår CertSecure Manager- plattform automatiserar denna process från identifiering till förnyelse för både jokercertifikat och namngivna certifikat.

Mätvärden att spåra efter implementering

När styrning och automatisering av jokercertifikat är på plats, spåra dessa mätvärden för att bekräfta att programmet fungerar och för att upptäcka avvikelser tidigt:

• Andel certifikat under automatisk förnyelse — andelen jokercertifikat och namngivna certifikat som förnyas utan manuell åtgärd; denna trend bör ligga mot 100 % när 100-dagars- och 47-dagarsfristerna närmar sig.

• Medeltid för återkallelse — hur lång tid det tar att återkalla ett komprometterat jokerteckencertifikat och omdistribuera ersättningar över alla drabbade underdomäner.

• Antal skuggcertifikat — certifikat som upptäcks via loggövervakning av certifikattransparens som inte visas i det hanterade inventariet; ett antal som inte är noll och växer signalerar ett upptäcktsluckor.

• Förhållande mellan jokertecken och namngivna certifikat – att spåra detta förhållande över tid visar om organisationen minskar användningen av jokertecken per policy eller tillåter att den expanderar som standard.

• Antal och kostnad relaterade till certifikat – avbrott, nära-missar och obehöriga utfärdandehändelser kopplade till certifikat, mätta kvartalsvis mot DigiCerts branschreferensvärde på 45 % av de företag som drabbas årligen och de 31 % av organisationerna som rapporterar certifikatrelaterade förluster på 50 000–250 000 USD.

Wildcard-certifikat i multimoln- och hybrid-PKI-miljöer

Multimoln- och hybridmiljöer lägger till ett koordineringsproblem utöver den vanliga riskprofilen för wildcard-certifikat: samma wildcard-certifikat distribueras ofta samtidigt i AWS-, Azure-, GCP- och lokal infrastruktur, vart och ett med sin egen certifikatarkiv, distributionsverktyg och förnyelseautomation (eller brist på den).

Två metoder är specifikt viktiga i den här miljön. För det första, upprätthåll en enda sanningskälla för var ett givet jokercertifikat distribueras i varje moln- och lokalt mål genom konsekvent certifikatidentifiering ; en certifikathanterare som bara ser ett molns certifikatarkiv kommer att missa de andra helt. För det andra, standardisera på en leverantörsneutral plattform för hantering av certifikatlivscykeln snarare än att förlita sig på varje molnleverantörs inbyggda, isolerade certifikathanterare, eftersom inbyggda verktyg i allmänhet inte koordinerar förnyelse eller återkallelse mellan leverantörer. En enhetlig plattform som CertSecure Manager ger PKI- och plattformsteam en vy och en automatiserad certifikatautomatiseringsväg i varje miljö som ett jokercertifikat berör.

Styrningsrekommendationer för Wildcard-certifikatpolicyer

Wildcard-certifikat är ett legitimt verktyg för hantering av underdomäner på företagsnivå, men bara inom en styrningsstruktur som tar undantaget på allvar. Följande policyer åtgärdar de vanligaste luckorna.

Godkännande och policy

• Undantagsbaserat godkännande

  Utfärdande av jokertecken bör kräva godkännande genom en dokumenterad undantagsprocess, och inte utfärdas som standard tillsammans med standardcertifikatförfrågningar.

• Certifikatpolicy och certifikatpraxisutlåtande

  Dokumentera jokerkortsspecifika regler för utfärdande, förnyelse och återkallelse explicit i organisationens CP och CPS, inklusive namngivet ansvar för löpande hantering.

• Regulatorisk anpassning

  Bekräfta att jokercertifikatpraxis uppfyller de specifika kraven för certifikatinventering och dokumentation i ramverk som PCI DSS och HIPAA.

Tekniska kontroller

• HSM-baserad nyckellagring

  Generera och lagra den privata nyckeln i en certifierad hårdvarusäkerhetsmodul , markerad som icke-exporterbar, snarare än på allmänna servrar.

• Åtkomstkontroll

  Begränsa åtkomsten till certifikatet och dess privata nyckel till en namngiven, minimal uppsättning behörig personal, med stark autentisering som verkställighet.

• Automatiserad förnyelse

  Automatisera utfärdande och förnyelse från början till slut så att certifikatets överlevnad inte är beroende av att en person kommer ihåg ett datum, särskilt när giltighetstiderna krymper mot 47 dagar.

Hur detta kopplas till 47-dagars TLS-certifikatberedskap

CA/Browser Forums omröstning SC-081v3, godkänd av Sectigo och antagen den 14 april 2025, fastställer ett fast schema som gäller för jokerteckencertifikat precis som det gäller för alla publika TLS-certifikat: maximal giltighetstid sjunker från 398 dagar till 200 dagar den 15 mars 2026, sedan till 100 dagar den 15 mars 2027, och sedan till 47 dagar den 15 mars 2029.

Denna tidslinje ändrar kostnads-nyttokalkylen specifikt för wildcard-certifikat. Ett wildcard-certifikat som en gång behövde förnyas manuellt en gång om året kommer att behöva det ungefär var 47:e dag år 2029, och eftersom ett wildcard vanligtvis finns bakom fler system än ett namngivet certifikat är koordineringsbördan av en missad manuell förnyelse proportionellt större. Organisationer som fortfarande hanterar wildcard-certifikat manuellt bör behandla automatiserad hantering av certifikatlivscykeln som en förutsättning för fortsatt användning av wildcard, inte en valfri förbättring. Se vår guide för att automatisera DNS-validering för mekanismerna för att ta bort manuella steg från förnyelsevägen som en del av en bredare 47-dagars TLS-certifikatberedskapsplan.

Wildcard-certifikat och kryptoagilitet: Kopplingen mellan PQC och CBOM

Nyckeln bakom ett wildcard-certifikat förblir inte relevant i all oändlighet. Varje RSA- eller ECDSA-nyckel som skyddar ett wildcard-certifikat idag är en kandidat för migrering när postkvantkryptografialgoritmer (PQC) blir baslinjen, och en organisation som inte vet var dess wildcard-certifikat finns eller vilka algoritmer de använder är inte positionerad för att planera den PQC-beredskapsmigreringen.

Det är därför styrning av wildcard-certifikat bäst behandlas som en delmängd av en större disciplin: kryptografisk inventering. En kryptografisk materiallista (CBOM) ger samma insyn som en PQC-färdplan behöver: vilka nycklar, certifikat och algoritmer som finns, var de distribueras och vilka som är kvantumsårbara, med början i de wildcard-certifikat som redan har den största explosionsradien om något går fel. Detta är grunden för kryptoagilitet : möjligheten att byta algoritmer eller utfärda certifikat på nytt i en miljö utan en nödinsats. Vår guide, Från upptäckt till handling: Hur en kryptografisk materiallista förvandlar inventering till intelligens , beskriver hur man omvandlar den inventeringen till en prioriterad åtgärdsplan snarare än ett statiskt kalkylblad, och CBOM Secure automatiserar det upptäcktslager som detta är beroende av.

När det lagret finns är nästa steg att sekvensera själva migreringen; ett wildcard-certifikat som skyddar ett dussin produktionsunderdomäner är en stark kandidat för tidig prioritet med tanke på dess explosionsradie. Encryption Consultings PQC Center of Excellence och PQC-beredskapstjänster utgår båda från samma inventering-först-strategi för kryptoagilitet.

Vad göra här näst

Nästa steg beror på vilket lag du sitter i:

• PKI-team: Granskar alla jokerteckencertifikat som för närvarande är i produktion, bekräftar HSM-baserad nyckellagring och dirigerar framtida jokerteckenförfrågningar genom en dokumenterad undantagsprocess.

• Säkerhetsteam: Konfigurera loggövervakning för certifikattransparens mot ägda domäner för att upptäcka obehörig utfärdande av jokertecken och skapa en återkallnings-runbook som tar hänsyn till varje underdomän som ett jokertecken täcker.

• Plattformsteam: Flytta förnyelsen av wildcard till en automatiserad process nu, inför övergången till 200 dagars giltighet i mars 2026, istället för att vänta tills 47-dagarsfristen tvingar fram problemet.

• Efterlevnadsteam: Bekräfta att jokerteckencertifikat finns representerade i det aktuella kryptografiska inventariet med den ägarskaps- och dokumentationsinformation som ert regelverk kräver.

Om du granskar ett befintligt wildcard-certifikat just nu, visar vår kostnadsfria OpenSSL CSR & Certificate Decoder exakt vilka underdomäner, giltighetsdatum och algoritmer det täcker innan du bestämmer dig för om det fortfarande hör hemma i din miljö.

Slutsats

Ett wildcard-certifikat är varken i sig farligt eller i sig säkert; det är en riskkoncentration som måste matchas med en lika stor koncentration av kontroll. Organisationer som kombinerar wildcard-certifikat med HSM-baserad nyckellagring, undantagsbaserat godkännande, korrekt inventering och fullständig automatisering av förnyelser får den operativa fördelen utan risken att misslyckas med en enda felpunkt. Organisationer som behandlar utfärdande av wildcard som en standardfunktion, utan någon av dessa kontroller, är de som syns i avbrottsstatistiken.

Vanliga frågor om partihandel med mat och dryck

Det här är de frågor som PKI-, säkerhets-, plattforms- och efterlevnadsteam ställer sig oftast när de utvärderar wildcard-certifikat.

Vad är den viktigaste slutsatsen från Wildcard-certifikat – farliga eller enklare att använda?

Ett wildcard-certifikat byter operativ enkelhet mot koncentrerad risk: ett certifikat och en privat nyckel täcker obegränsat antal underdomäner på första nivån, vilket minskar administrationskostnaderna men innebär att en enda nyckelkompromiss exponerar varje underdomän samtidigt. Beslutet att använda ett certifikat bör gå igenom en dokumenterad godkännandeprocess, inte en standardutgivningsväg.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel?

Certifikatrelaterade avbrott drabbar redan 45 % av företagen årligen, och wildcard-certifikat ökar risken för varje enskilt livscykelfel eftersom en missad förnyelse eller en komprometterad nyckel kan ta bort alla underdomäner som certifikatet täcker samtidigt, inte bara en enda värd.

Vilka team ansvarar för att agera utifrån denna vägledning?

PKI- och säkerhetsteamen ansvarar för godkännande och nyckelskydd; plattforms- och infrastrukturteamen ansvarar för inventering och distributionsspårning; efterlevnadsteamen ansvarar för mappning av jokerteckensanvändning mot regulatoriska krav på certifikatinventering; och säkerhetsverksamheten ansvarar för övervakning av obehörig utfärdande av jokertecken via loggar för certifikattransparens.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell hantering av wildcard-certifikat ökar risken för missad förnyelse som orsakar avbrott på flera underdomäner, för ofullständig inventering som lämnar skuggcertifikat oupptäckta tills en incident inträffar, och för långsammare återkallningsrespons när en nyckel komprometteras, eftersom varje distributionsplats måste hittas och uppdateras manuellt.

Hur minskar automatisering risken för certifikatavbrott?

Automatiserad hantering av certifikatlivscykeln eliminerar de två vanligaste orsakerna till certifikatavbrott: ett förnyelsedatum som beror på att en person kommer ihåg det, och ett certifikat som uppdaterats på en server men missat på en dubblett eller klustrad instans. Specifikt för jokerteckencertifikat eliminerar automatiseringen också koordineringskostnaden för att uppdatera varje underdomänsdistribution under en manuell förnyelse.

Vilka mätvärden bör teamen följa efter implementeringen?

Spåra andelen certifikat som förnyas automatiskt, genomsnittlig tid för att återkalla ett komprometterat certifikat, antal skuggcertifikat från övervakning av certifikattransparens, förhållandet mellan jokertecken och namngivna certifikat över tid och antal och kostnad för certifikatrelaterade incidenter mätt kvartalsvis mot branschriktmärket på 45 % av de företag som drabbas årligen.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

CA/Browser Forums schema minskar maximal giltighetstid för offentliga TLS till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029, och wildcard-certifikat följer samma schema. Eftersom ett wildcard vanligtvis ligger bakom fler system än ett namngivet certifikat, växer samordningskostnaden för manuell förnyelse snabbare i takt med att giltighetsperioderna krymper, vilket gör automatisering till en förutsättning snarare än en valfri uppgradering.

Hur ska detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Multimoln- och hybridmiljöer behöver en enda sanningskälla för varje plats där ett jokerteckencertifikat distribueras hos molnleverantörer och lokal infrastruktur, plus en leverantörsneutral plattform för hantering av certifikatlivscykeln, eftersom inbyggda certifikathanterare per moln i allmänhet inte koordinerar förnyelse eller återkallelse mellan leverantörer.