Når bør du bruke et wildcard-sertifikat?

Et wildcard-sertifikat kan dekke mange subdomener uten at hvert navn står i sertifikatet. Det er nyttig når navn opprettes dynamisk. Det er ikke nødvendigvis den enkleste eller sikreste løsningen for fem kjente tjenester på fem ulike servere.

Det avgjørende spørsmålet er ikke hvor mange subdomener dere har, men om de samme systemene bør dele én privatnøkkel og ett fornyelsesløp.

Hva dekker `*.bedrift.no`?

Wildcardtegnet erstatter nøyaktig én etikett til venstre:

Navn	Dekket av `*.bedrift.no`?	Hvorfor
`www.bedrift.no`	Ja	Ett nivå under `bedrift.no`
`butikk.bedrift.no`	Ja	Ett nivå under `bedrift.no`
`bedrift.no`	Nei	Wildcardet erstatter ikke et tomt navn
`api.butikk.bedrift.no`	Nei	To nivåer under `bedrift.no`
`butikk.annet.no`	Nei	Et annet domenetre

Hvis både bedrift.no og *.bedrift.no skal virke, må begge navnene finnes i sertifikatets SAN-liste. Ikke anta at utstederen legger til rotdomenet automatisk.

Et wildcard oppretter heller ikke DNS-poster og sender ikke trafikk til riktig tjeneste. DNS, routing, virtuell host og sertifikat må alle være konfigurert.

Wildcard eller eksplisitte SAN-navn?

Behov	Ofte best egnet
`bedrift.no` og `www.bedrift.no`	Ett sertifikat med begge SAN-navn
Fire kjente navn på samme lastbalanserer	Ett SAN-sertifikat eller plattformens automatiske løsning
Kjente navn på uavhengige systemer	Separate sertifikater og separate nøkler
Nye kundenavn opprettes løpende under ett domene	Wildcard eller sikker utstedelse per kunde
Internt miljø med egne tillits- og nøkkelkrav	Løsning valgt etter virksomhetens PKI-policy

Separate sertifikater begrenser skadeomfanget: kompromitteres nøkkelen på én tjeneste, trenger dere ikke nødvendigvis rotere sertifikatet på alle de andre. De gir også tydeligere eierskap når ulike team eller leverandører drifter systemene.

Et wildcard kan være riktig når en sentral proxy eller plattform terminerer TLS for mange dynamiske navn. For en flerleietjeneste bør dere også vurdere automatisk sertifikat per kundenavn. Det reduserer nøkkeldeling, men krever kontroll på validering, rate limits, misbruk og fornyelse.

Wildcard fra Let’s Encrypt krever DNS-validering

Let’s Encrypt kan utstede wildcardsertifikater gjennom ACME, men wildcardnavnet må valideres med DNS-01. ACME-klienten legger da en unik TXT-verdi under _acme-challenge.bedrift.no, og sertifikatutstederen leser verdien fra autoritativ DNS.

TXT-verdien endres ved senere valideringer. Manuell innlegging kan fungere én gang, men gir ikke et robust fornyelsesløp. En produksjonsløsning bør bruke et DNS-API eller delegere bare _acme-challenge til en tjeneste som kan automatiseres.

Let’s Encrypt beskriver både DNS-01 for wildcard og delegering av challenge-sonen og advarer mot å legge fullverdige DNS-rettigheter på webserveren.

Begrens DNS-rettighetene

DNS-legitimasjon som kan endre hele sonen, kan brukes til mer enn sertifikatutstedelse. Begrens derfor:

hvilke soner og poster nøkkelen kan endre
hvilke systemer som kan lese nøkkelen
hvem som kan starte utstedelse
hvor lenge legitimasjonen er gyldig
logging og varsling for endringer

Hvis DNS-leverandøren ikke støtter avgrensede API-rettigheter, kan en delegert challenge-sone være bedre enn å kopiere en administratørnøkkel til hver webserver.

CAA kan i tillegg avgrense hvilke sertifikatutstedere som får utstede for domenet. issuewild gjelder wildcardutstedelse. Les utstederens dokumentasjon før endring; en feil CAA-policy kan stoppe legitim fornyelse. Let’s Encrypt dokumenterer CAA, issuewild og avgrensning til en ACME-konto .

Den private nøkkelen er den største avveiningen

Sertifikatet er offentlig. Den private nøkkelen skal ikke være det.

Hvis samme wildcardnøkkel kopieres til webserver, e-posttjeneste, VPN, kundesystem og ekstern leverandør, kan ett kompromittert system utløse rotasjon overalt. Dere mister også tydelig oversikt over hvem som har en kopi.

En bedre modell er å:

terminere TLS sentralt der det passer arkitekturen
bruke separate nøkler når tjenestene er uavhengige
gjøre private nøkler ikke-eksporterbare når plattformen støtter det
begrense fil- og prosessrettigheter
rotere og tilbakekalle ved mistanke om eksponering
dokumentere alle steder nøkkelen er installert
teste at fornyet sertifikat faktisk lastes av alle tjenester

Ikke send privatnøkler i e-post eller supportsaker.

Wildcard løser ikke alle subdomener

Et sertifikat for *.bedrift.no kan presenteres for et navn som ikke finnes i DNS, men det gjør ikke navnet tilgjengelig. Og fordi wildcardet bare dekker ett nivå, beskytter det ikke automatisk api.butikk.bedrift.no.

Dette er særlig viktig ved HSTS. includeSubDomains kan gjelde alle underdomener og alle dybder, også interne eller gamle navn. Ett wildcard på første nivå er derfor ikke et bevis på at domenet er klart for includeSubDomains eller preload. Les HSTS-guiden før policyen utvides .

Sjekkliste før dere velger wildcard

Er subdomenene dynamiske, eller kjenner dere navnene allerede?
Termineres TLS ett sted, eller må nøkkelen kopieres mellom systemer?
Trenger rotdomenet et eget SAN-navn?
Finnes det navn på dypere nivå som wildcardet ikke dekker?
Kan DNS-01 fornyes uten manuell TXT-oppdatering?
Kan DNS-API-rettigheten begrenses til challenge-postene?
Hvem mottar varsel når fornyelse feiler?
Hvordan roteres sertifikat og nøkkel på alle installasjonssteder?
Krever interne retningslinjer separat nøkkel per tjeneste?

Bruk hovedguiden om SSL-sertifikater og TLS for validering og TLS-begreper, eller feilsøk SSL- og HTTPS-feil hvis serveren leverer sertifikatet for feil navn.

Wildcard og Vymos nettsidetilbud

Den enkle bedriftsnettsiden Vymo setter opp og hoster, trenger normalt ikke et kundeadministrert wildcardsertifikat. Vymo aktiverer HTTPS for siden, men tilbyr foreløpig ikke et selvbetjent SSL-panel.

Har virksomheten flere subdomener, egen proxy eller krav til egen nøkkelforvaltning, må arkitektur og ansvar avklares før bestilling. Beskriv domenene og sikkerhetskravene så kan vi si tydelig om standardtilbudet passer.