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.
Hvad wildcards faktisk dækker — og hvad de ikke gør
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.
Problemet med blast radius på den private nøgle
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.
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 deployes via automatisering, er den operationelle bekvemmelighed reel og fornyelsesomfangproblemet 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 mandaterer 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.