To tilgange til multi-domæne dækning
Både wildcard- og SAN-certifikater løser det samme grundproblem: du har flere hostnavne, der skal beskyttes med TLS, og du vil ikke administrere et certifikat per navn.
Men de to typer fungerer fundamentalt forskelligt, og valget har konsekvenser for sikkerhed, fleksibilitet og drift.
Hvad dækker et wildcard-certifikat?
Et wildcard-certifikat dækker alle subdomæner på ét niveau under et bestemt domæne. Et certifikat for *.example.dk dækker:
www.example.dkmail.example.dkapi.example.dkintranet.example.dk- ... og alle andre subdomæner på det niveau.
Det dækker ikke:
example.dk(selve roddomænet, medmindre det er tilføjet som SAN)sub.www.example.dk(to niveauer dybt)example.com(et andet domæne)
Ved bestilling via websitet tilføjer FairSSL automatisk roddomænet gratis, når du bestiller et wildcard. På DigiCert-familien er de navne, wildcardet dækker, også gratis. Med ACME angiver du selv alle navne.
Hvad dækker et SAN-certifikat?
Et SAN-certifikat (Subject Alternative Name, også kaldet Multi-Domain eller UC-certifikat) dækker en eksplicit liste af navne, som du angiver ved bestilling. Navnene kan være fra forskellige domæner:
www.example.dkexample.dkwww.example.commail.andetfirma.dk
Du bestemmer selv, hvilke navne der skal med. De fleste CA'er tillader 100-250 SAN-navne per certifikat. Navnene kan tilføjes og fjernes ved genudstedelse.
Kombinér wildcard og SAN i samme certifikat
Det er muligt at kombinere wildcard og SAN i det samme certifikat. De fleste Multi-Domain (SAN) certifikater tillader, at du tilføjer wildcard-navne som SAN-poster. Det giver flere interessante muligheder:
- Wildcard plus specifikke hostnavne: Et certifikat med
*.example.dksom primært navn ogapi.partner.dk,shop.example.comsom ekstra SAN-navne. Du dækker alle subdomæner under dit hoveddomæne og specifikke navne fra andre domæner. - Flere wildcards i ét certifikat: Et certifikat med
*.example.dk,*.example.comog*.staging.example.dk. Hvert wildcard-navn tæller som én SAN-post. - Wildcard plus roddomæne:
*.example.dkdækker ikkeexample.dkselv (kun subdomæner). Tilføj roddomænet som separat SAN for fuld dækning. Ved bestilling hos FairSSL via websitet sker det automatisk og gratis.
Et wildcard dækker kun ét domæne. *.example.dk dækker ikke *.example.com eller *.andetfirma.dk. Hvis du har brug for dækning på tværs af forskellige domæner, skal hvert domæne tilføjes som separat SAN (enten som wildcard eller specifikt hostnavn).
Kombicertifikater er ofte den mest fleksible løsning for virksomheder med flere domæner og mange subdomæner. Prisen er typisk baseret på antallet af SAN-poster, hvor hvert wildcard-navn tæller som én post.
Sikkerhedsovervejelser
Wildcard-certifikater har en grundlæggende sikkerhedsudfordring: den private nøgle skal installeres på alle servere, der bruger certifikatet.
Hvis du har *.example.dk installeret på din webserver, mailserver, API-gateway og udviklerserver, deler alle fire systemer den samme private nøgle. Hvis én server kompromitteres, kan angriberen bruge nøglen til at udgive sig for alle subdomæner.
Kompromisradius
NSA anbefaler: Adskil sikkerhedszoner
Brug ikke det samme wildcard-certifikat på internetvendte servere og interne administrationspaneler. Hvis den offentlige server kompromitteres, kan angriberen bruge den stjålne nøgle til man-in-the-middle mod interne systemer.
NSA (via NSA Cybersecurity Information Sheet, "Avoid Dangers of Wildcard TLS Certificates") advarer specifikt mod brug af wildcard-certifikater på systemer med forskellige sikkerhedsniveauer. Deres anbefaling: brug ikke det samme wildcard-certifikat på en internetvendt webserver og et internt administrationspanel.
Hvis din offentlige webserver kompromitteres og deler certifikat med dit interne admin-panel, kan angriberen bruge den stjålne nøgle til at opsætte en overbevisende man-in-the-middle mod admin-panelet. Adskillelse er derfor den logiske beskyttelse.
Med SAN-certifikater kan du begrænse kompromisradius ved at gruppere navne efter sikkerhedsniveau. Kundevendte systemer får ét certifikat, interne systemer et andet.
Nøglegenbrug
Wildcard-certifikater inviterer til nøglegenbrug. Samme certifikat (og dermed samme nøgle) installeres på mange servere. Det strider mod princippet om nøgleisolation: ideelt bør hver server have sin egen private nøgle, så kompromittering af én server ikke påvirker andre.
Med SAN-certifikater har du samme problem, men i mindre skala. Du kan begrænse antallet af SAN-navne per certifikat for at holde kompromisradius nede.
Prissammenligning
Wildcard-certifikater er typisk dyrere end et enkelt domænecertifikat, men billigere end mange individuelle certifikater. Prisen er fast uanset, hvor mange subdomæner du bruger.
SAN-certifikater prissættes typisk med et grundbeløb plus et beløb per ekstra SAN-navn. De første 1-5 SAN-navne er ofte inkluderet i grundprisen.
Prissammenligningen afhænger af dit scenarie:
- Mange subdomæner under ét domæne: Wildcard er billigst.
- 3-5 navne fra forskellige domæner: SAN-certifikat er billigst.
- Blanding af begge: Nogle CA'er tilbyder SAN-certifikater med wildcard-SAN'er (f.eks.
*.example.dksom et SAN-navn). Det giver fleksibilitet, men til en højere pris.
Se vores produktoversigt for aktuelle priser, eller brug certifikatvælgeren til at finde den rigtige type.
Kombiner typerne
Der er intet galt i at bruge wildcard til udvikling og staging, mens produktion bruger specifikke SAN-certifikater med strammere nøglekontrol.
Automatisering og levetid
Med SSL-levetider på vej mod 47 dage (i 2029) bliver automatisering af certifikatudstedelse og installation afgørende. Her har de to typer forskellige egenskaber:
Wildcard + ACME: Kræver DNS-01-validering (du kan ikke bruge HTTP-01 til wildcards). Din ACME-klient skal have adgang til at oprette DNS TXT-records. Med FairSSL AutoDNS er det en engangsopsætning med en CNAME-viderestilling.
SAN + ACME: Kan bruge enten HTTP-01 eller DNS-01 for hvert SAN-navn. HTTP-01 er simplere (ingen DNS-adgang nødvendig), men kræver at alle SAN-navne peger på den server, der kører ACME-klienten.
Bedste praksis
- Undgå wildcard på tværs af sikkerhedszoner. Brug ikke det samme wildcard-certifikat på offentlige og interne systemer. Udsted separate certifikater.
- Overvej kompromisradius. Gruppér navne i certifikater efter, hvor kritisk de er. Kundevendte services i ét certifikat, interne i et andet.
- Automatisér. Med 200-dages certifikater (og snart 100 og 47 dage) er manuelle processer ikke holdbare. Brug ACME uanset certifikattype.
- Brug wildcard med omtanke. Et wildcard-certifikat er bekvemt, men det dækker også subdomæner, du aldrig har tænkt over. Hvis en angriber opretter
phishing.example.dkvia en DNS-sårbarhed, har de allerede et gyldigt certifikat. - Kombiner typerne. Der er intet galt i at bruge et wildcard til udvikling og staging, mens produktion bruger specifikke SAN-certifikater med strammere kontrol.
Opsummering
| Egenskab | Wildcard | SAN (Multi-Domain) |
|---|---|---|
| Dækning | Alle subdomæner på ét niveau | Eksplicit liste af navne |
| Krydsdomæne | Nej (kun subdomæner under ét domæne) | Ja (vilkårlige domæner og hostnavne) |
| Kombination | Kan kombineres: wildcard + SAN-navne + flere wildcards i ét certifikat | |
| Kompromisradius | Høj (alle subdomæner) | Begrænset (kun listede navne) |
| ACME-validering | DNS-01 påkrævet | HTTP-01 eller DNS-01 |
| Pris ved mange navne | Fast pris | Stiger med antal SAN'er |
| Validering | DV eller OV | DV, OV eller EV |
| EV tilgængelig | Nej | Ja |