Wildcard- vs SAN-certificaat: welke heb je echt nodig?

Een wildcardcertificaat beveiligt één subdomeinniveau, helemaal links, onder één naam (*.example.com). Een SAN-certificaat (ook wel UCC- of multidomeincertificaat genoemd) somt daarentegen een expliciete set hostnamen op in de Subject Alternative Name-extensie. Geen van beide is per definitie "beter". Ze lossen verschillende dekkingsproblemen op, en een verkeerde keuze merk je meestal pas later: als onverwachte certificaatfout op een subdomein dat niemand had toegevoegd.

Wat een wildcardcertificaat precies dekt

Een wildcardcertificaat gebruikt een asterisk in het meest linkse label, zoals in *.example.com. Volgens RFC 6125 mag die asterisk alleen één volledig label helemaal links vervangen. *.example.com is geldig en *.sub.example.com is geldig als aparte wildcard, maar f*.example.com (een gedeeltelijk label) en *.*.example.com (meerdere labels) zijn geen standaard wildcardsyntax die publieke certificaatautoriteiten (CA's) uitgeven.

Het detail waar veel mensen over struikelen: een wildcard dekt het kale apex-domein niet, en reikt ook niet dieper dan één niveau. *.example.com beschermt www.example.com en api.example.com, maar niet example.com zelf of a.b.example.com. Wil je het apex-domein ook dekken, dan voeg je het als tweede SAN-vermelding aan hetzelfde certificaat toe. De meeste uitgevers doen dat automatisch als je via hun standaardproces een wildcard aanvraagt, maar controleer de uiteindelijke SAN-lijst in plaats van ervan uit te gaan.

Publieke CA's geven ook geen wildcard uit op of boven het niveau van het publieke suffix. Je krijgt *.co.uk om voor de hand liggende redenen niet van een publiek vertrouwde CA.

WarningPublieke CA's geven wildcardcertificaten alleen uit via DNS-01-domeinvalidatie: je bewijst dat je de DNS-zone beheert door een TXT-record te publiceren. Validatie via HTTP kan geen controle aantonen over subdomeinen die nog niet bestaan. Is je DNS dus verdeeld over meerdere providers of zit die achter een change-controlproces, houd dan bij verlengingen rekening met die doorlooptijd.

Wat een SAN-certificaat precies dekt

Een SAN-certificaat vermeldt elke hostnaam die het beschermt afzonderlijk in de subjectAltName-extensie van het certificaat. www.example.com, app.example.com, example.net en shop.example.org kunnen allemaal op één certificaat staan, zelfs als het om volledig ongerelateerde domeinen gaat. Op protocolniveau is er geen maximum aan het aantal namen dat een certificaat kan bevatten (RFC 5280 stelt er geen), maar CA's hanteren hun eigen praktische limieten, vaak ergens tussen de 100 en 250 namen, afhankelijk van de leverancier en het productniveau. Stel je een lange lijst samen, raadpleeg dan de actuele documentatie van de uitgevende CA.

Elke naam op een SAN-certificaat kan in principe een andere validatiemethode gebruiken, en een SAN-lijst kan exacte hostnamen combineren met wildcardvermeldingen, bijvoorbeeld *.example.com, example.com en api.partner-domain.com op één certificaat. Die flexibiliteit is de belangrijkste reden dat SAN-certificaten bestaan: één certificaat dekt een verspreide set diensten die geen net subdomeinpatroon delen.

Wildcard vs SAN in één oogopslag

Wanneer kies je een wildcardcertificaat?

Kies een wildcard als er onder één naam vaak en voorspelbaar subdomeinen bijkomen. Denk aan subdomeinen per klant op een SaaS-platform (tenant1.example.com, tenant2.example.com), of een microservices-omgeving waarin nieuwe interne services onder *.internal.example.com sneller verschijnen dan iemand een SAN-lijst wil bijhouden. Eén certificaat dekt dat allemaal ongemerkt, en je hoeft niet opnieuw uit te geven telkens als er een nieuw subdomein live gaat.

De keerzijde: een gecompromitteerde private key van een wildcard legt in één keer alle huidige en toekomstige subdomeinen onder die naam bloot. Dat is een grotere impact dan één gestolen SAN-certificaat met een vaste lijst. Gebruik je een wildcard, bescherm die private key dan navenant en houd de certificate transparency-logs in de gaten op certificaten voor je domein die je niet zelf hebt aangevraagd.

Wanneer kies je een SAN-certificaat?

SAN-certificaten zijn zinvol als je een bekende, relatief stabiele set hostnamen hebt die geen vast patroon volgen: een marketingsite op het apex-domein, een app op een subdomein, een API op een ander TLD en misschien een partnerdomein waarvoor je ook TLS afhandelt. Door ze expliciet te vermelden blijft de impact kleiner (alleen de genoemde hosts zijn gedekt) en blijft de validatie per naam controleerbaar.

De keerzijde werkt hier andersom: elke nieuwe hostnaam betekent de SAN-lijst aanpassen en het certificaat opnieuw uitgeven. Verandert je lijst wekelijks, dan lopen die kosten snel op en wordt een wildcard (of automatisering) aantrekkelijker.

TipJe hoeft niet exclusief te kiezen. Eén certificaat kan een wildcardvermelding combineren met expliciete SAN-hostnamen: *.example.com plus example.com plus api.partner.com op één certificaat is geldig en in de praktijk gebruikelijk.

Controleren wat er echt op een certificaat staat

Leid de dekking niet alleen af uit de common name van het certificaat. De common name is tegenwoordig vaak alleen informatief; voor de matching telt de SAN-lijst. Haal een live certificaat door onze gratis SSL-checker om alle SAN-vermeldingen, de vervaldatum en de keten in één overzicht te zien. Zo bevestig je het snelst dat een wildcard echt dekt wat je denkt, of ontdek je dat er een hostnaam op een SAN-certificaat ontbreekt voordat een browser het je vertelt.

Twijfel je nog tussen een gratis geautomatiseerd certificaat en een commercieel certificaat, los van de vorm (SAN of wildcard)? Bekijk dan onze vergelijking Let's Encrypt vs commerciële SSL. De keuze tussen wildcard en SAN staat los van die beslissing, en beide uitgiftemethoden ondersteunen beide vormen.

Alles verlengd houden zonder spreadsheet

Welke vorm je ook kiest, het operationele risico is hetzelfde: een certificaat dat ongemerkt verloopt of een hostnaam die iemand vorige maand heeft toegevoegd niet meer dekt. Het certificaatbeheer van InfraNest houdt elk certificaat bij bij elke provider, signaleert hiaten in de SAN-dekking en automatiseert verlenging, zodat wildcard- en SAN-certificaten allebei vóór het verlopen opnieuw worden uitgegeven, en niet pas nadat een klant een browserwaarschuwing meldt.