Et wildcard-certifikat dækker hvert underdomæne under et domæne med ét certifikat og én privat nøgle. Én fornyelse, én installation, alt er dækket. Appellen er indlysende. Risikoen er at en enkelt kompromitteret privat nøgle ugyldiggør sikkerheden for alle tjenester under det domæne simultant — og de fleste teams har ikke et klart billede af hvor mange tjenester det faktisk er.
Wildcard-certifikater — angivet med en asterisk i subjektet, som *.ditdomæne.dk — er et legitimt og udbredt værktøj. Brugt korrekt reducerer de certifikatstyring overhead for organisationer med mange underdomæner på konsistent infrastruktur. Brugt skødesløst skaber de et single point of failure der udsætter alt under et domæne for konsekvenserne af en enkelt sikkerhedshændelse. En komplet oversigt over jeres TLS-certifikater giver det nødvendige fundament for at vurdere, om jeres wildcard-brug er under kontrol.
Hvad et wildcard-certifikat dækker — og hvad det ikke dækker
Et wildcard-certifikat til *.ditdomæne.dk er gyldigt til ethvert enkelt-niveau underdomæne: api.ditdomæne.dk, app.ditdomæne.dk, mail.ditdomæne.dk. Det dækker ikke ditdomæne.dk selv (selvom dette normalt tilføjes som et SAN), og det dækker ikke dybere underdomæner som api.intern.ditdomæne.dk.
Det betyder at teams undertiden bruger wildcard-certifikater i situationer hvor de giver falsk dækning — i troen på at *.ditdomæne.dk dækker hele deres underdomæne-navnerum, mens enhver anden-niveau underdomænestruktur faktisk ikke er dækket. Afvejningerne mod andre muligheder gennemgås i vores sammenligning af single-domæne, wildcard og SAN-certifikater.
Blast-radius: Hvad sker der, når den delte private nøgle kompromitteres
Hvert TLS-certifikat har en tilhørende privat nøgle. Certifikatets sikkerhed afhænger helt af at den private nøgle forbliver hemmelig. For individuelle tjenestecertifikater er en kompromitteret privat nøgle et alvorligt problem — men omfanget er begrænset til de tjenester der bruger det certifikat.
For et wildcard-certifikat er omfanget alle tjenester under domænet. Hvis din wildcard private nøgle kompromitteres, kan en angriber efterligne ethvert underdomæne — din hovedapplikation, din API, din administrationsgrænseflade, din kundeportal, dine interne værktøjer. Alle på én gang, med et certifikat som browsere vil acceptere uden klage. Hurtig OCSP-tilbagekaldelse er den primære nødrespons, men afhænger af at I opdager kompromiset og handler inden angriberen udnytter det.
Denne risiko forstærkes af de distributionsmønstre der gør wildcards appellerende i første omgang. Grunden til at teams bruger wildcards er at undgå at styre individuelle certifikater til hver tjeneste. Certifikatet og den private nøgle kopieres til flere servere, flere load balancers, flere miljøer. Hver kopi er et potentielt eksponeringspunkt. Flere kopier betyder mere risikoflade for nøglen — og blast-radius ved et kompromis forbliver det samme uanset hvor nøglen lækkede fra.
Problemet med fornyelsesomfang
Når et wildcard-certifikat fornyes, skal det nye certifikat deployes til alle systemer der bruger det. For teams med god infrastructure-as-code-praksis og centraliseret certifikatstyring er dette en koordineret deployment. For teams der manuelt har distribueret wildcard-certifikater over tid er fornyelsesomfanget ofte uklart.
Hvilke servere har dette certifikat? Hvilke load balancers? Hvilke CDN-konfigurationer? Hvilke tredjepartsplatforme hvor det er uploadet? En manuel wildcard-certifikatdistributionshistorik er typisk dårligt dokumenteret, og fornyelsesdeployments misser ofte nogle instanser — hvilket fører til udløbsfejl på tjenester der ikke var på nogens fornyelsestjekliste.
Hvornår wildcards giver mening
Wildcards er passende når:
- Tjenester er homogene og centralt styrede. Et CDN eller en load balancer der håndterer trafik til mange tjenester med lignende klassifikation, alle styret af det samme team, er et rimeligt wildcard-anvendelsestilfælde.
- ACME-automatisering håndterer rotation. Når et wildcard fornyes automatisk via DNS-01 challenge og ACME-protokollen og deployes via automatisering, er den operationelle bekvemmelighed reel og fornyelsesomfangsproblemet løses af automatiseringen.
- Underdomæne-navnerummet er stabilt og velkendt. Hvis organisationen har et klart, dokumenteret sæt underdomæner under wildcard og god synlighed i hvad der kører hvor, er risikoen mere håndterbar.
Hvornår wildcards skaber uacceptabel risiko
Wildcards er upassende når:
- Forskellige sikkerhedszoner deler wildcard. Brug af det samme wildcard-certifikat til produktionstjenester og udviklingsmiljøer betyder at et kompromis i dev-miljøet truer produktion.
- Certifikatet distribueres til mange parter. Hvis wildcard-certifikatet skal uploades til partnersystemer, CDN-udbydere, tredjepartsplatforme eller underleverandørmiljøer, er hver distribution et privat nøgle-eksponeringspoint du ikke fuldt ud kan kontrollere.
- Underdomæne-rummet er stort og dårligt dokumenteret. Hvis du ikke ved hvad der kører under dit wildcard, kan du ikke vurdere blast-radius ved et kompromis — og du vil næsten helt sikkert misse systemer under fornyelsesdeployments.
- Regulatoriske krav kræver certifikatisolation. Nogle compliance-frameworks kræver at systemer der behandler forskellige datakategorier bruger separat kryptografisk materiale.
Hvordan CertControl håndterer wildcards
CertControl sporer wildcard-certifikater på tværs af alle endepunkter hvor de er i brug — forbinder certifikatfingerprinting på tværs af flere tjenester så wildcardets udløb er synligt i konteksten af alle tjenester det dækker. Når et wildcard nærmer sig udløb, viser advarslen det fulde omfang af påvirkede tjenester, hvilket gør deploymenttjeklisten for fornyelse eksplicit frem for rekonstrueret fra hukommelse.
Den eksterne scanner opdager wildcard-dækkede tjenester via CT-log-enumeration og aktiv scanning — så wildcardets faktiske omfang i produktion er synligt selv hvis den interne oversigt er ufuldstændig.
Ofte stillede spørgsmål
Hvad dækker et wildcard-certifikat?
Et wildcard til *.ditdomæne.dk er gyldigt til ethvert enkelt-niveau underdomæne som api.ditdomæne.dk, men det dækker ikke det bare domæne (medmindre tilføjet som SAN) eller dybere underdomæner som api.intern.ditdomæne.dk.
Hvorfor er wildcard-certifikater mere risikable end per-underdomæne certifikater?
Et wildcard deler én privat nøgle på tværs af alle underdomæner, så ét nøglekompromis lader en angriber efterligne alle tjenester under domænet på én gang. Per-underdomæne certifikater begrænser blast-radius til én tjeneste.
Hvornår er et wildcard-certifikat et rimeligt valg?
Når tjenester er homogene og centralt styrede, når ACME-automatisering håndterer rotation via DNS-01, og når underdomæne-navnerummet er stabilt, dokumenteret og af én sikkerhedsklassifikation.
Hvornår bør jeg undgå wildcard-certifikater?
Undgå dem når forskellige sikkerhedszoner ville dele nøglen, når certifikatet skal distribueres til mange tredjeparter, når underdomæne-rummet er stort og udokumenteret, eller når regler kræver kryptografisk isolation mellem dataklassifikationer.
Hvordan komplicerer wildcards certifikatovervågning?
Endepunktsliste-overvågning kan misse tjenester der bruger et udløbende wildcard og ikke er i oversigten. Overvågning der opdager endepunkter via CT-logs og aktiv scanning afslører hvert underdomæne der bruger wildcardet og dermed dets reelle omfang.