Allt du behöver veta om wildcard-certifikat

Snabbt svar: En enda komprometterad privat nyckel kan i tysthet exponera varje underdomän som finns bakom den, och det är den avvägning som är inbyggd i varje wildcard-certifikat. Wildcard-certifikat gör det enkelt att säkra dussintals underdomäner, vilket är just därför de har blivit både vanliga och kontroversiella i moderna PKI-program.

Sammanfattning

Wildcard-certifikat byter administrativ enkelhet mot koncentrerad risk: ett certifikat och en privat nyckel kan säkra dussintals underdomäner, men en enda komprometterad eller misskött nyckel exponerar alla samtidigt. Den risken är redan vanlig: 45 % av företagen rapporterade certifikatrelaterad driftstopp under det senaste året, varav 37.5 % kan spåras till ett utgånget certifikat ( DigiCert Trust Pulse Survey, juli 2025 ), och ett wildcard koncentrerar samma exponering över varje underdomän det täcker istället för bara en. CA/Browser Forums etappvisa minskning av maximal giltighetstid för offentliga TLS-certifikat, till 200 dagar i mars 2026, 100 dagar 2027 och 47 dagars TLS-certifikat senast i mars 2029, gör manuell förnyelse av wildcard matematiskt ogenomförbar i den skalan. Denna guide täcker de styrnings- och automatiseringsmetoder som gör wildcards säkra att använda, och hur wildcard-inventering matas in i bredare post-kvantkryptografi (PQC) beredskap och CBOM-planering som en del av en hållbar kryptoagilitetsstrategi.

Snabb checklista: Är du utsatt för risker med wildcard-certifikat?

Innan du läser hela sammanfattningen nedan, använd den här checklistan för att bedöma hur exponerad din organisation redan är för risker med wildcard-certifikat.

• Bekräfta att du känner till alla underdomäner och system som för närvarande provisioneras från varje jokerteckencertifikat i din miljö, inte bara de du kommer ihåg.
• Bekräfta att varje begäran om jokerteckencertifikat har gått igenom en dokumenterad undantags-/godkännandeprocess snarare än att utfärdas som ett standardbekvämlighetsalternativ.
• Bekräfta att den privata nyckeln bakom varje jokerteckencertifikat lagras i en HSM eller motsvarande skyddad miljö och inte exporteras till enskilda servrar.
• Bekräfta att förnyelse av wildcard-certifikat sker automatiserat snarare än en manuell kalenderpåminnelse, särskilt eftersom giltighetsfönstren krymper mot 47 dagar.
• Bekräfta att du har en dokumenterad plan för att minska användningen av jokertecken till förmån för namngivna certifikat där isolering är viktigare än bekvämlighet.

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 certifikat och en privat nyckel, vilket minskar administrativa kostnader jämfört med att utfärda individuella certifikat.

• Wildcard-certifikat är fortfarande en betydande andel av TLS-utgivningen: de utgjorde 27.4 % av alla offentligt loggade TLS-certifikat under andra kvartalet 2026, en minskning något från 29.6 % föregående kvartal, enligt en analys av Cloudflare Radar Certificate Transparency-data.

• Kärnrisken är koncentration: en komprometterad privat nyckel med jokertecken exponerar varje underdomän under det certifikatet samtidigt, och över 70 % av organisationerna rapporterade minst ett certifikatrelaterat avbrott under det senaste året, enligt CyberArks rapport om säkerhetsstatus för maskinidentiteter från 2025.

• Ett SAN-certifikat (Subject Alternative Name, ofta kallat multidomain) eller ett certifikat för en enda domän begränsar explosionsradien men ökar administrationskostnaderna. Rätt val beror på hur många underdomäner du har och hur mycket riskkoncentration du kan tolerera.

• Stark styrning (godkännandearbetsflöden, nyckelhantering, inventering, automatisk förnyelse) är det som gör wildcard-certifikat säkra att använda överhuvudtaget, och samma inventeringsarbete är grunden för planering av migrering efter kvantkryptografi (PQC).

Vad är ett wildcard-certifikat?

Ett wildcard-certifikat , även känt som ett wildcard SSL-certifikat, är en typ av digitalt certifikat som används för att säkra flera underdomäner inom en enda domän.

Jokertecken används ofta i SSL-certifikat (Secure Socket Layers) för att utöka SSL-kryptering till underdomäner. Ett traditionellt SSL-certifikat är endast giltigt för en enda domän, till exempel www.abc.com. Ett *.abc.com -jokerteckencertifikat kan skydda alla underdomäner under en domän, t.ex. cloud.abc.com , shop.abc.com , mobile.abc.com med flera.

Asterisken (*) används som jokertecknet i certifikatet. Den kan representera vilken enskild underdomännivå som helst. Till exempel fungerar ett jokertecknecertifikat för *.abc.com för vilken underdomän som helst på första nivån, till exempel finance.abc.com eller marketing.abc.com.

Wildcard-certifikat är särskilt användbara för organisationer med många underdomäner som vill säkra dem alla under ett enda certifikat. De tillhandahåller kryptering och autentisering för data som överförs mellan användarens webbläsare och webbservern, vilket förbättrar säkerheten och integriteten för webbkommunikation. Det är dock viktigt att hantera wildcard-certifikat noggrant eftersom om den privata nyckeln komprometteras kan en angripare potentiellt använda den för att imitera vilken underdomän som helst under wildcard-domänen. Därför är korrekta säkerhetsrutiner, som att skydda den privata nyckeln och regelbundet förnya certifikat, avgörande när man använder wildcard-certifikat.

Wildcard-certifikat används fortfarande i stor utsträckning: enligt en analys av Cloudflare Radar Certificate Transparency -data stod wildcard-certifikat för 27.4 % av alla offentligt loggade TLS-certifikat under andra kvartalet 2026, en liten minskning från 29.6 % under första kvartalet. Även med den nedgången jämfört med föregående kvartal är wildcard-certifikat fortfarande ett vanligt sätt för team som kör många underdomäner per SaaS-plattform, CDN eller mikrotjänst att förhindra att TLS-täckning blir ett heltidsjobb.

Wildcard kontra SAN kontra certifikat för en enda domän: Hur man väljer

Innan man antar ett wildcard-certifikat är det bra att se det bredvid de två alternativ som de flesta team faktiskt väljer mellan: ett SAN-certifikat (multidomäncertifikat) och individuella certifikat för en enda domän. Båda alternativen handlar med täckning, kostnad och sprängradie på olika sätt.

Certifikattyp	Domäntäckning	Sprängningsradie om nyckeln är komprometterad	Administrativa kostnader	Bästa passform
Jokertecken (*.example.com)	Alla underdomäner på första nivån inom en domän	Hög: varje underdomän under jokertecknet	Låg: ett certifikat att förnya och spåra	Miljöer med många underdomäner som är villiga att centralisera risker för enkelhetens skull
SAN / Multidomän	En fast, namngiven lista över domäner och underdomäner som valts vid utfärdandet	Begränsat till de namngivna värdarna på certifikatet	Måttlig: ett certifikat, men listan måste uppdateras när värdar byts	Organisationer som behöver en handfull specifika domäner på ett certifikat utan exponering av jokerteckenstyp
Enkeldomän	Ett fullständigt kvalificerat värdnamn	Begränsad till den enda värden	Hög: ett separat certifikat och förnyelse per värd	Högsäkerhets- eller efterlevnadskänsliga system där isolering är viktigare än bekvämlighet

För en mer djupgående jämförelse av valideringskrav, priser och CA-stöd för varje alternativ, se vår fullständiga guide: Att välja rätt SSL-certifikat: Wildcard vs. SAN (multidomän).

Problem med jokerteckencertifikat

Det finns några stora säkerhetsproblem med den utbredda användningen av jokercertifikat.

Falsk känsla av säkerhet

I system med hög säkerhet, som https://cloud.abc.com eller https://personnel-records.abc.com, är det viktigt att ange värdnamn explicit snarare än att förlita sig på ett jokertecken för att täcka dem. Jokerteckencertifikat kan ge en falsk känsla av säkerhet, eftersom de inte garanterar att användare verkligen använder de avsedda systemen. Användare kan omedvetet ansluta till föråldrade eller inaktiva länkar eller servrar som inte längre tjänar något syfte. Att använda jokertecken döljer potentiella server- och DNS-fel.

Missbruk av certifikat och deras privata nycklar

Att använda jokercertifikat ökar risken avsevärt för att certifikatet hamnar i fel händer. Felaktigt konfigurerade jokercertifikat kan leda till säkerhetsbrister. Om de inte är korrekt konfigurerade eller om deras privata nycklar exponeras kan angripare utnyttja dem. Detta beror främst på att jokercertifikat som '*.abc.com' sannolikt kommer att distribueras i stor utsträckning över olika system, inklusive högsäkerhetssystem för redovisning, telefonkataloger, routrar och lastbalanserare.

Det är en fråga om grundläggande sannolikhet: ju fler individer som är involverade i installationen av samma jokercertifikat, desto större är sannolikheten att det komprometteras eller läcks. Däremot installeras och hanteras namngivna certifikat exklusivt under utsedda teams installation av specifika system. Denna metod erbjuder mycket starkare ansvarsskyldighet. Dessutom skyddar SAN-certifikat endast de specifika värdnamn som listas på dem, vilket begränsar oavsiktlig exponering för orelaterade system.

• Säkerhetshinder

  Om den privata nyckeln till ett jokerteckencertifikat komprometteras kan den potentiellt användas för att imitera vilken underdomän som helst under jokerteckendomänen. Detta gör det viktigt att skydda den privata nyckeln noggrant.

• Begränsad till en enda nivå

  Wildcard-certifikat täcker bara en nivå av underdomäner. Till exempel skulle ett certifikat för *.abc.com säkra underdomäner som blog.abc.com och mail.abc.com, men inte underdomäner som sub.blog.abc.com. För att säkra flera nivåer av underdomäner behöver du ett jokercard-certifikat med flera nivåer, vilket kan vara dyrare och mindre vanligt tillgängligt.

• Komplexitet för tredje part

  Vissa tjänster eller program från tredje part kanske inte stöder jokerteckencertifikat eller kan kräva ytterligare konfiguration. Kompatibilitetsproblem kan uppstå i vissa situationer.

• Risk för överanvändning

  Team frestas ofta att använda ett wildcard-certifikat för för många underdomäner, vilket ökar risken om den privata nyckeln komprometteras. Begränsa användningen av wildcard-certifikat till endast de underdomäner som verkligen behöver det.

Certifikatavbrott och operativ risk

Felaktigt använda nycklar är inte den enda operativa risken som wildcard-certifikat medför. Certifikatrelaterade avbrott är fortfarande ett av de vanligaste PKI-felen i hela branschen: en rapport från CyberArk State of Machine Identity Security från 2025 visade att över 70 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under det senaste året. Eftersom ett wildcard-certifikat ofta ligger bakom många tjänster samtidigt, tar ett utgånget eller felkonfigurerat wildcard inte ner en webbplats; det kan ta ner alla underdomäner som är beroende av det samtidigt.

Komplexitet vid återkallelse av certifikat

Att återkalla ett jokerteckencertifikat kan vara mer komplext än att återkalla enskilda certifikat. Återkallelsen gäller vanligtvis hela jokerteckendomänen och påverkar alla underdomäner.

Rekommendationer för policyer för jokerteckenscertifikat

Wildcard-certifikat kan vara en bekväm lösning för att säkra flera underdomäner inom en organisation på företagsnivå. De medför dock också vissa säkerhets- och hanteringsutmaningar. Styrning är viktig här eftersom de flesta organisationer fortfarande hanterar detta manuellt: en SwissSign-undersökning från februari 2026 visade att 90 % av organisationerna med fler än 500 anställda fortfarande hanterar certifikat åtminstone delvis manuellt, exakt under vilket en felkonfiguration av ett wildcard går obemärkt förbi. Här är några policyer som en organisation på företagsnivå bör överväga när de implementerar wildcard-certifikat i sin miljö:

Styrning och godkännande

• Godkännandeprocess

  Upprätta en process för att begära, validera och godkänna begäranden om wildcard-certifikat. Ett wildcard-certifikat bör aldrig vara standardsättet att erhålla ett certifikat; varje begäran bör gå igenom en dokumenterad undantagsprocess, såsom godkännande från en styrelseledamot eller vice VD.

• Policyer för certifikathantering

  Skapa en tydlig policy för utfärdande, förnyelse och återkallelse av wildcard-certifikat i er "Certifikatpolicy (CP)" och "Certificate Practice Statement (CPS)". Ange vem som ansvarar för att hantera certifikaten.

• Efterlevnad och branschstandard

  Säkerställ att hanteringspraxis för wildcard-certifikat överensstämmer med branschstandarder och föreskrifter som är relevanta för din organisation, till exempel PCI DSS eller HIPAA.

Identifiering, namngivning och dokumentation

• Identifiera underdomäner

  Identifiera alla underdomäner som jokerteckencertifikatet kommer att täcka. Bestäm vilka underdomäner som måste säkras och se till att de följer organisationens namngivningskonventioner.

• Namngivningskonventioner för underdomäner

  Upprätta tydliga namngivningskonventioner för underdomäner som jokerteckencertifikat säkrar. Detta bidrar till att säkerställa konsekvens och tydlighet i certifikathanteringen.

• Ge korrekt information

  Säkerställ att all information som tillhandahålls under certifikatutfärdandeprocessen är korrekt, aktuell och inkluderar alla slutpunkter som är avsedda för certifikatet. Detta inkluderar en korrekt namngivningskonvention för certifikatet (enligt organisationens preferenser och krav), kontaktinformation, organisationsuppgifter (om tillämpligt), information om domänägande och en motivering för att begära ett certifikat.

• Inventering och dokumentation

  Håll en uppdaterad inventering av alla jokercertifikat som används inom organisationen. Dokumentera certifikatinformation, inklusive utgångsdatum, tillhörande underdomäner och ansvariga parter.

Tekniska kontroller och åtkomstkontroller

• Nyckelhantering

  Implementera starka nyckelhanteringspraxis, inklusive säker generering och lagring av privata nycklar som är kopplade till jokerteckencertifikat. Rotera regelbundet nycklar och uppdatera certifikatkonfigurationer, inklusive certifikatmallar och protokollkompatibilitet, för att ligga steget före potentiella sårbarheter.

• Åtkomstkontroll

  Begränsa åtkomsten till jokerteckencertifikat och deras privata nycklar endast till behörig personal. Tillämpa strikta åtkomstkontroller och autentiseringsmekanismer för att förhindra obehörig åtkomst.

• Säker lagring

  Lagra jokerteckencertifikat och deras privata nycklar i en säker, offline- eller HSM-skyddad miljö. Kryptera och säkerhetskopiera certifikatdata för att förhindra dataförlust.

Livscykel, övervakning och riskreducering

• Policy för återkallelse av certifikat

  Definiera en tydlig process för att återkalla jokerteckenscertifikat om de komprometteras eller inte längre behövs. Säkerställ att återkallade certifikat omedelbart tas bort från alla relevanta system.

• Process för förnyelse av certifikat

  Upprätta en process för snabb certifikatförnyelse för att undvika avbrott i tjänsten på grund av utgångna certifikat. Automatisera certifikatförnyelse där det är möjligt för att minska manuella fel.

• Regelbunden säkerhetsbedömning

  Genomför regelbundna säkerhetsbedömningar och penetrationstester för att identifiera sårbarheter relaterade till jokercertifikat och deras användning.

• Säkerhetsmedvetenhet och utbildning

  Utbilda anställda om vikten av säkerhet för wildcard-certifikat och riskerna med att hantera dem felaktigt.

• Användning av jokerteckencertifikat

  Användning av wildcard-certifikat bör undvikas när det är möjligt. Skapa en omfattande plan för att gradvis minska användningen av wildcard-certifikat när de ska förnyas.

Rekommendation för framtida åtgärder

Rekommendationerna nedan beskriver praktiska nästa steg som organisationer kan ta med sina wildcard-certifikat, grupperade efter hur snart varje enskilt certifikat bör utfärdas.

Interimistisk åtgärd

Minimera antalet individer med åtkomst till jokercertifikat, helst begränsat till färre personer. Implementera strikta kontroller över hanteringen av den privata nyckeln och certifikatet och behandla dem med största möjliga säkerhet. Undvik elektronisk överföring och hårddisklagring; välj istället säkra fysiska lagringsmetoder som HSM som lagras på en säker plats. Se till att varje certifikatinstallation är inställd som "ej exporterbar" för att förhindra potentiella läckor.

Medellång sikt

Minska användningen av jokerteckencertifikat till så få system som möjligt. Använd namngivna certifikat överallt där det är möjligt. Detta innebär att veta var jokertecknen är installerade och planera för deras utbyte (om möjligt).

Långsiktig strategi

Implementera ett krav att alla wildcard-certifikat måste genereras eller förnyas uteslutande genom en automatiserad process, utan personalinteraktion. Denna övergång kommer att kräva betydande planering och förberedelser. Denna förändring är inte längre valfri med en tillräckligt lång tidsram: CA/Browser Forums maximala giltighetstid för offentliga TLS-certifikat sjönk till 200 dagar i mars 2026 och är planerad att minska till 100 dagar år 2027 och 47 dagar år 2029, vilket gör manuell förnyelse av wildcards ohållbar i stor skala oavsett policypreferens.

Wildcard-certifikat och kryptoagilitet: Varför detta kopplas till din PQC- och CBOM-strategi

Här är den del som de flesta riktlinjer för wildcard-certifikat utelämnar: nyckeln bakom certifikatet förblir inte relevant för alltid. 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 redan vet var dess wildcard-certifikat finns och vilka algoritmer de använder är inte redo att planera den migreringen.

Det är därför vi behandlar styrning av wildcard-certifikat som en delmängd av en större disciplin: kryptografisk inventering. En kryptografisk materiallista (CBOM) ger dig samma insyn som din PQC-färdplan behöver: vilka nycklar, certifikat och algoritmer som finns, var de används 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. CBOM Secure automatiserar det upptäckts- och inventeringsarbetet, och From Discovery to Action: How a Cryptographic Bill of Materials Turns Inventory into Intelligence täcker hur det inventariet blir till handlingsbar riskprioritering. Vi täcker också varför de flesta inventeringar missar detta i The Cryptographic Blind Spot Hiding in Your Own Infrastructure.

När den inventeringen finns behöver själva migreringen sekvenseras, inte en big bang-övergång. Vår guide, PQC-migrering år 2026: Att bygga en färdplan som överlever kontakt med produktion , går igenom hur man prioriterar vilka certifikat och nycklar som ska migreras först, och ett jokerteckencertifikat som skyddar ett dussin produktionsunderdomäner är en stark kandidat för den prioriteringslistan. PQC Center of Excellence är där detta arbete med upptäckt, styrning och migrering sammanförs i ett strukturerat program snarare än ett engångsprojekt.

Ägare och åtgärdsmatris per team

Beslutstabell för certifikatmetod

Använd den här tabellen för att mappa ett vanligt användningsfall till den rekommenderade certifikatmetoden, vem som bör äga det beslutet och vilket resultat man kan förvänta sig.

Vad göra här näst

PKI-team bör börja med ett identifieringspass som listar alla underdomäner och system som för närvarande provisioneras från varje jokerteckencertifikat, eftersom explosionsradien för ett jokertecken bara är så väl förstådd som inventariet bakom det.

Säkerhetsteam bör verifiera att varje privat nyckel med jokertecken finns i en HSM eller motsvarande skyddad miljö och bekräfta exakt vem som har åtkomst till den, eftersom den åtkomstlistan är det verkliga måttet på exponering.

Plattformsteam bör prioritera automatiserad förnyelse av alla wildcard-certifikat som fortfarande spåras manuellt, med början i de som backar upp det största antalet underdomäner.

Compliance-team bör bekräfta att det finns register över undantagsgodkännanden och CP/CPS-dokumentation för varje jokercertifikat som för närvarande används, så att styrningsbevis är tillgängliga på begäran snarare än att samlas in i efterhand.

Hur krypteringskonsulting kan hjälpa

Merparten av risken som behandlas i den här guiden handlar om en lucka: ingen har en korrekt och realistisk registrering av var en organisations wildcard-certifikat är distribuerade, vem som kan nå den privata nyckeln bakom varje certifikat, eller när det förnyas. CertSecure Manager täcker den luckan genom att upptäcka varje certifikat på publika och privata CA:er, molnplattformar och lokala servrar, och sedan tillämpa HSM-baserad nyckellagring och automatiserad, policydriven förnyelse så att ett wildcard-certifikat aldrig är beroende av att någon kommer ihåg en deadline. För organisationer som behöver formalisera det arbetsflöde för undantagsgodkännande som den här guiden rekommenderar kan Encryption Consultings PKI Services-team hjälpa till att bygga eller uppdatera certifikatpolicyn (CP) och certifikatpraxisutlåtandet (CPS) som styr när ett wildcard utfärdas från första början. Och eftersom nyckeln bakom varje wildcard-certifikat också är en kandidat för den slutliga övergången till postkvantalgoritmer, utökar CBOM Secure samma upptäcktsarbete till en fullständig kryptografisk inventering, så att wildcard-styrning och PQC-beredskapsplanering baseras på samma data istället för två separata kalkylblad. Encryption Consulting är ISO/IEC 27001:2022- och SOC 2-certifierade. Om du vill se hur automatiserad identifiering och förnyelse skulle stå sig mot din egen certifikattillgång är en genomgång av CertSecure Manager det snabbaste sättet att ta reda på det.

Slutsats

Organisationer bör implementera starka policyer och säkerhetsrutiner för certifikathantering (CP/CPS), regelbundet granska och övervaka användningen av jokercertifikat och överväga alternativ som att använda separata certifikat för kritiska underdomäner eller implementera mer detaljerade säkerhetskontroller där det behövs. Även om jokercertifikat kan vara ett värdefullt verktyg, bör de användas med eftertanke och säkert inom en organisations övergripande säkerhetsstrategi.

Om du granskar ett befintligt wildcard-certifikat just nu, visar vår kostnadsfria OpenSSL CSR & Certificate Decoder dig 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ö.

Några frågor dyker ofta upp när team utvärderar wildcard-certifikat:

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Allt du behöver veta om Wildcard-certifikat? Wildcard-certifikat byter administrativ enkelhet mot koncentrerad risk: ett certifikat och en privat nyckel kan säkra dussintals underdomäner, men en enda komprometterad eller misskött nyckel exponerar var och en av dem samtidigt. De bör styras medvetet, genom en godkännandeprocess, starkt nyckelskydd och automatisk förnyelse, snarare än att användas som ett standardalternativ för bekvämlighet.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel? Det är viktigt eftersom ett wildcard-certifikat multiplicerar effekten av varje enskilt certifikatlivscykelfel. Certifikatrelaterad driftstopp påverkar redan 45 % av företagen under ett givet år, och 37.5 % av den driftstoppet kan spåras till ett utgånget certifikat (DigiCert Trust Pulse Survey, juli 2025); ett wildcard-fel koncentrerar samma risk över varje underdomän det täcker istället för bara en.

Vilka team ansvarar för att agera utifrån denna vägledning? PKI-teamet äger utfärdande av wildcard-certifikat och underdomäninventering, säkerhetsteamet äger skydd av privata nycklar och komprometteringshantering, plattformsteamet äger automatisering och distribution av förnyelser, och efterlevnadsteamet äger register över godkännande av undantag och revisionsbevis. Styrning av wildcard-certifikat misslyckas när ansvaret för dessa fyra funktioner inte är tydligt tilldelat.

Vilka risker ökar om detta ämne hanteras manuellt? Manuell hantering av jokercertifikat ökar risken för missade förnyelser som påverkar alla beroende underdomäner samtidigt, spridning av privata nycklar över de många system där ett jokercertifikat installeras, en falsk känsla av säkerhet som maskerar underliggande DNS- eller serverkonfigurationer och en oförmåga att producera bevis för undantagsgodkännande under en granskning.

Hur minskar automatisering risken för certifikatavbrott? Automatisering tar bort de manuella steg som gör wildcard-certifikat riskabla i stor skala: automatiserad identifiering hittar varje underdomän och system som ett wildcard-certifikat faktiskt skyddar, automatiserad förnyelse håller jämna steg med krympande giltighetsfönster utan att förlita sig på att någon kommer ihåg en deadline, och automatiserad nyckelrotation minskar den ad hoc-hanteringen av privata nycklar som ökar risken för kompromettering.

Vilka mätvärden bör team spåra efter implementeringen? Spåra antalet underdomäner och system som provisionerats från varje jokercertifikat, andelen jokercertifikat som förnyats utan manuell åtgärd, antalet utestående kontra beviljade godkännanden av jokercertifikatundantag, och den tid som krävs för att återkalla och återutfärda om en privat jokernyckel någonsin misstänks vara komprometterad.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap? Ett wildcard-certifikat som backar upp många underdomäner samtidigt förvärrar problemet med förnyelsefrekvensen bakom CA/Browser Forums 47-dagars TLS-certifikatschema, inte bättre: manuell förnyelse som redan är ansträngande under dagens 200-dagarscykel blir ogenomförbar när samma wildcard behöver förnyas mer än sju gånger om året. Automatiserad, zero-touch-förnyelse är en förutsättning specifikt för wildcard-certifikat, inte en valfri uppgradering.

Hur ska detta hanteras i miljöer med flera moln eller hybrida PKI-system? I miljöer med flera moln och hybrider utfärdas ofta wildcard-certifikat separat per molnleverantör eller lokalt system utan någon central insyn, vilket återskapar exakt det upptäcktsgap som den här artikeln varnar för. Lösningen är en enda, centraliserad certifikat- och nyckelinventering som omfattar varje certifikatutfärdare och miljö, så att ett wildcards fullständiga underdomänavtryck är känt och styrs konsekvent överallt där det distribueras.