SAN begrijpen in X.509 SSL-certificaten

Wat is een Subject Alternative Name (SAN) in SSL/TLS-certificaten? 

De Subject Alternative Name (SAN) is een belangrijke uitbreiding van de X.509-certificaat standaard, gedefinieerd in RFC 5280Hiermee kunnen SSL/TLS-certificaten meerdere identiteiten bevatten die verder gaan dan alleen het veld Common Name (CN). Deze identiteiten kunnen domeinnamen, subdomeinen, IP-adressen, e-mailadressen en meer omvatten, waardoor veilige communicatie via een breed scala aan eindpunten mogelijk wordt. 

Door gebruik te maken van de SAN-extensie kunnen organisaties de flexibiliteit, schaalbaarheiden veiligheid van hun SSL-certificaten. In plaats van aparte certificaten voor elk domein of elke dienst te beheren, kan één SAN-certificaat alle vereiste identiteiten onder één certificaat beveiligen, wat het certificaatbeheer vereenvoudigt en de operationele overhead verlaagt. 

Vóór SAN: de beperking van de Common Name (CN) 

Bij eerdere SSL-certificaten werd de door het certificaat beveiligde domeinnaam voornamelijk geïdentificeerd via het CN-veld. 

 Voorbeeld: 

 Als de CN was: 

CN = www.voorbeeld.com 

Het certificaat is alleen geldig voor: 

• www.example.com 

Als een gebruiker het volgende heeft bezocht: 

• example.com 
• blog.voorbeeld.com 
• www.voorbeeld.net 

Ze zouden een beveiligingswaarschuwing ontvangen omdat het certificaat niet overeenkomt met het aangevraagde domein. Moderne browsers vertrouwen niet langer op het CN-veld voor domeinvalidatie; ze valideren alleen op basis van gegevens in het SAN-veld voor betere beveiliging en consistentie, conform de huidige industrienormen. 

Nadelen van uitsluitend vertrouwen op CN

• Er kon slechts één volledig gekwalificeerde domeinnaam (FQDN) worden vastgelegd. 

• Geen flexibiliteit om subdomeinen of alternatieve domeinen op te nemen. 

• Voor meerdere services/domeinen zijn afzonderlijke certificaten vereist. 

• Verouderde praktijk:Het wordt afgeraden om uitsluitend op CN te vertrouwen vanwege veiligheidsrisico's en compatibiliteitsproblemen, omdat veel moderne browsers CN negeren en alleen de SAN-lijst vertrouwen voor domeinvalidatie. 

Na SAN: meerdere domeinen, één certificaat 

Via de SAN extensie, een enkele SSL/TLS-certificaat kan beveiligen meerdere identiteiten over verschillende diensten. Deze identiteiten kunnen het volgende omvatten: 

• subdomeinen (bijv. blog.example.com) 
• Geheel verschillende domeinen (bijv. example.net) 

• IP adressen (bijv. 203.0.113.5) – Let op: IP-adressen in SAN's moeten exact overeenkomen. Subnetten of gedeeltelijke overeenkomsten worden niet ondersteund. 
• Interne hostnamen (bijv. intranet.local) 
• Wildcard-domeinen (bijv. *.example.com) – Wildcard-vermeldingen in SAN-velden hebben beperkingen: ze komen slechts overeen met één subdomeinniveau (bijv. *.example.com komt overeen met blog.example.com maar niet met dev.blog.example.com) en niet alle certificeringsinstanties (CA's) ondersteunen wildcard-vermeldingen in SAN's. Controleer altijd de ondersteuning en het beleid van de CA voordat u ze gebruikt. 

Voorbeeld: 

Een SAN-compatibel certificaat kan het volgende bevatten: 

CN = www.voorbeeld.com 

SAN: 

  DNS.1 = www.voorbeeld.com 

  DNS.2 = voorbeeld.com 

  DNS.3 = blog.voorbeeld.com 

  DNS.4 = www.voorbeeld.net 

  IP.1 = 203.0.113.5 

Dit certificaat is geldig voor alle vermelde DNS- en IP-vermeldingen. 

Voordelen: 

• Met één certificaat kunt u meerdere services beveiligen. 
• Vereenvoudigt beheer: één verlenging, één installatie. 
• Het is kosteneffectief omdat het niet nodig is om afzonderlijke certificaten aan te schaffen. 
• Ondersteunt moderne webinfrastructuur zoals microservices, API's en multidomeinplatforms. 
• SAN is nu een verplicht onderdeel van alle publiekelijk vertrouwde
• SSL-certificaten, volgens de CA / Browser Forum Basisvereisten: moderne browsers vertrouwen uitsluitend op het SAN-veld voor domeinvalidatie. 

Waarom een ​​SAN SSL-certificaat gebruiken?  

• Beveilig meerdere domeinen met één certificaat
  Beveilig alle domeinen onder één SSL-certificaat, zodat organisaties eenvoudiger meerdere websites kunnen beheren.
  Het is echter belangrijk om te weten dat elke SAN-vermelding afzonderlijk moet worden gevalideerd tijdens de certificaatuitgifte. De meeste CA's vereisen DNS- of HTTP-gebaseerde domeinvalidatie voor elk domein in de SAN-lijst om eigendom en naleving van de beveiliging te garanderen.
• Vereenvoudigd certificaatbeheer
  Vermindert de complexiteit en menselijke fouten door slechts één certificaat te beheren, te vernieuwen en te implementeren in plaats van meerdere certificaten.
• Kostenefficiënt toezicht
  Bespaart kosten omdat u niet meerdere certificaten hoeft aan te schaffen: veel SAN-certificaten ondersteunen maximaal 100 domeinen.
• Ondersteunt complexe infrastructuren
  Ideaal voor moderne configuraties zoals microservices, API's en cloudplatforms die gebruikmaken van verschillende subdomeinen of domeinen.
• Vereist voor browsercompatibiliteit
  Moderne browsers gebruiken het SAN-veld, waardoor SAN een verplicht onderdeel is van openbare SSL-certificaten.
• Schaalbaar voor toekomstige uitbreiding
  Het toevoegen van domeinen aan het certificaat bij het verlengen of opnieuw uitgeven is eenvoudig, wat ideaal is voor groeiende bedrijven.
• Verhoogt vertrouwen en SEO
  HTTPS op alle domeinen wekt vertrouwen bij de gebruiker, beschermt gegevens en verbetert de positie in de zoekresultaten van Google.

Hoe werkt een SAN-certificaat? 

Certificaatcreatie met SAN's 

Tijdens het genereren van een certificaatondertekeningsaanvraag (CSR) specificeert de beheerder een lijst met SAN-vermeldingen. Deze kunnen zijn: 

• Volledig gekwalificeerde domeinnamen (FQDN's) 
• subdomeinen 
• IP adressen 
• E-mailadressen 
• URI's (voor gespecialiseerde toepassingen) 

Om deze SAN-waarden op te nemen, moet de beheerder ze definiëren in het veld subjectAltName in het CSR-configuratiebestand (meestal openssl.cnf of een equivalent). 
Zodra de CSR is aangemaakt en ingediend bij een CA, verifieert de CA het eigendom of de controle van elke SAN-vermelding. Na succesvolle validatie geeft de CA een certificaat uit met de SAN-vermeldingen gecodeerd in de SAN-extensie. 

Browser/client doet een beveiligd verzoek 

Wanneer een client (zoals een browser of app) verbinding maakt met een beveiligde website via HTTPS: 

• Tijdens het TLS-handdruk, presenteert de server zijn SSL-certificaat aan de client. 
• Het certificaat omvat: 
  1. De openbare sleutel 
  2. Het CN (oude veld) 
  3. De SAN-extensie met alle geldige identiteiten

Als onderdeel van de handshake voert de client een hostnaamverificatie uit, waarbij wordt gecontroleerd of het aangevraagde domein overeenkomt met een van de vermeldingen in het SAN-veld. Deze verificatiestap is cruciaal voor het opbouwen van vertrouwen: moderne clients vertrouwen uitsluitend op de SAN-extensie voor deze controle en negeren het CN-veld. 

Client valideert de SAN-lijst 

Moderne browsers vertrouwen in plaats daarvan op de SAN-lijst en negeren de CN. De client zoekt naar een match tussen: 

• De domeinnaam waarmee verbinding gemaakt moet worden. 
• Een van de namen die in het SAN-veld staan. 

De verbinding wordt alleen veilig tot stand gebracht als er een exacte of geldige wildcard-match wordt gevonden. 

• Jokergedrag: Browsers ondersteunen SAN-vermeldingen met wildcarddomeinen (bijv. *.example.com), maar de wildcard kan slechts op één subdomeinniveau overeenkomen. Zo komt *.example.com overeen met blog.example.com, maar niet met shop.dev.example.com. 
• Interne namenModerne browsers en CA's accepteren geen interne namen (zoals localhost of server.local) meer in openbare certificaten. Het opnemen van dergelijke namen leidt ertoe dat het certificaat als ongeldig of onbetrouwbaar wordt beschouwd. 

Als er geen overeenkomst wordt gevonden, geeft de browser een beveiligingswaarschuwing weer, bijvoorbeeld 'Uw verbinding is niet privé' of 'Ongeldig certificaat'. 

Eén certificaat, vele domeinen 

Omdat de SAN-lijst meerdere identiteiten bevat, kan één certificaat worden gebruikt voor: 

• Meerdere websites (bijv. example.com, example.net) 
• Meerdere subdomeinen (bijv. shop.example.com, blog.example.com) 
• Verschillende services (bijv. Exchange Server, mailserver, API-gateway) 

Dit maakt het beheer eenvoudig en overzichtelijk, aangezien u niet langer voor elk domein aparte certificaten hoeft te installeren en beheren. 

Veelvoorkomende gebruiksscenario's voor SAN-certificaten (Subject Alternative Name) 

SAN-certificaten worden in veel sectoren en infrastructuren gebruikt vanwege hun ondersteuning voor meerdere domeinen. Ze helpen u meerdere domeinen, subdomeinen en IP-adressen te beschermen met één certificaat, wat het ideaal maakt voor organisaties die schaalbaarheid én eenvoud zoeken. 

 Het beveiligen van meerdere websites onder één organisatie 

Use Case

Een bedrijf is eigenaar van meerdere websites of merkdomeinen: 

• example.com 
• example.net 
• example.org 
• product.voorbeeld.com 
• support.example.net 

Het is niet langer nodig om voor elke domeinnaam een ​​apart SSL-certificaat te kopen en beheren. Een bedrijf kan nu één enkel SAN-certificaat gebruiken om alle domeinen en subdomeinen te beschermen. 

Note: Elk subdomein moet expliciet worden vermeld in het SAN-veld, tenzij er een joker (bijv. *.example.com) is opgenomen. Zonder joker is de subdomeinmatching exact en worden niet-vermelde subdomeinen niet door het certificaat gedekt. 

Voordelen:

• Gecentraliseerd beheer 
• Kostenbesparingen 
• Gemakkelijker vernieuwen en installeren 

Beveiliging van multi-subdomeintoepassingen 

Use Case 

Een webapplicatie werkt op verschillende subdomeinen: 

• login.example.com (authenticatie) 
• api.example.com (backend API) 
• dashboard.example.com (gebruikersportaal) 
• cdn.example.com (levering van statische inhoud) 

Alle subdomeinen worden als SAN-vermeldingen aan één certificaat toegevoegd. 

Voordelen:

• Vereenvoudigt de implementatie 
• Vermindert de wildgroei aan certificaten 
• Geünificeerde verval- en verlengingscyclus 

Cloudgebaseerde en microservicesarchitecturen 

Use Case

Moderne applicaties, die gebruikmaken van microservices of cloudplatforms, werken op: 

• Verschillende subdomeinen 
• Afzonderlijke regio's of instanties 
• Verschillende topleveldomeinen (TLD's) 

Voorbeeld: 

• us.api.example.com 
• eu.api.example.net 
• static.cdnexample.org 

U kunt een SAN-certificaat gebruiken om al deze services te beschermen, zelfs als ze geografisch verspreid zijn of zich over meerdere domeinen uitstrekken. 

Overweging: Hoewel SAN-certificaten het beheer vereenvoudigen, kan het koppelen van te veel services aan één certificaat een single point of failure creëren. Als het certificaat verloopt, gecompromitteerd raakt of opnieuw moet worden uitgegeven, worden alle services die ervan afhankelijk zijn, tegelijkertijd beïnvloed. Om dit te beperken, moeten organisaties services zorgvuldig groeperen op risico en omgeving en waar nodig afzonderlijke SAN-certificaten gebruiken. 

Voordelen:

• Eenvoudigere certificaatautomatisering (bijvoorbeeld via CI/CD) 
• Minder certificaten om te vernieuwen, minder verkeerde configuraties 
• Veilige servicecommunicatie in hybride cloudconfiguraties 

Ontwikkelings-, staging- en testomgevingen 

Use Case

Ontwikkelaars willen HTTPS gebruiken op lokale of staging-domeinen: 

• dev.voorbeeld.lokaal 
• staging.example.com 
• test-api.example.org 

Alle omgevingen worden beveiligd met SAN-certificaten. Er zijn geen meerdere certificaten nodig. 

Voor interne omgevingen zoals .local-domeinen (bijv. dev.example.local) is het raadzaam om een ​​interne CA of een zelfondertekend SAN-certificaat te gebruiken. Openbare CA's geven geen certificaten meer uit voor interne namen vanwege beveiligingsbeperkingen opgelegd door het CA/Browser Forum. 

Voordelen:

• Zorg voor nauwkeurige en veiligere tests in de praktijk HTTPS voorwaarden. 
• Snellere CI/CD-testpijplijnen. 
• De last van handmatig certificaatbeheer wordt verminderd. 

Microsoft Exchange Server en Office 365 

Use Case 

Voor Microsoft Exchange en Skype voor Bedrijven zijn SAN-certificaten vereist, zodat ze correct functioneren met meerdere interne en externe services, zoals: 

• mail.voorbeeld.com 
• autodiscover.example.com 
• smtp.voorbeeld.net 
• Intern.exchange.local 

Om de implementatie te vereenvoudigen, raadt Microsoft certificaten aan die meerdere SAN-vermeldingen ondersteunen. 

A Unified Communications-certificaat (UCC) wordt vaak in deze scenario's gebruikt. Hoewel UCC vaak een speciaal certificaat wordt genoemd, is het in wezen een marketingterm voor een multi-SAN-certificaat dat is geoptimaliseerd voor Microsoft-applicaties zoals Exchange, Skype voor Bedrijven en Office 365. 

Voordelen:

• Ondersteunt volledig het vertrouwde Microsoft-framework voor certificaatbeheer. 
• Er zijn geen meerdere certificaten nodig: één certificaat kan alle services beveiligen (e-mail, agenda, automatische detectie, enz.) 
• Eenvoudige installatie voor hybride Office 365-implementaties 

Waar u op moet letten bij het kiezen van een CA voor SAN-certificaten

Reputatie en vertrouwensniveau

Kies een wereldwijd vertrouwde CA die: 

• Erkend door alle toonaangevende browsers en besturingssystemen. 
• Volgens alle richtlijnen van het CA/Browser Forum. 
• Bekend om de implementatie van hoge veiligheidsnormen. 

Populaire vertrouwde CA's: 

• DigiCert 
• Sectigo (voorheen Comodo) 
• Toevertrouwen 
• GlobalSign 
• GoDaddy 
• Let's Encrypt (voor beperkte gebruiksgevallen, ondersteunt SAN) 

Let op: Terwijl Laten we versleutelen is algemeen vertrouwd en ideaal voor geautomatiseerde implementaties op korte termijn, het kan niet geschikt voor langere certificaatlevensduur or complexe bedrijfsbehoeften dat vereisen uitgebreide validatie (EV), organisatievalidatie (OV) of geavanceerde ondersteunings- en rapportagefuncties. 

Waarom dit belangrijk is: Met publiek vertrouwen zien gebruikers de waarschuwingen over 'Niet-vertrouwd certificaat' niet. 

Prijzen en licenties 

De prijzen van SAN-certificaten kunnen fluctueren, afhankelijk van: 

• Aantal opgenomen SAN's (sommige bevatten standaard 2-5 SAN's) 
• Kosten per extra SAN-vermelding 
• Validatieniveau (DV, OV, EV) 

Voorzichtigheid: Wees je bewust van het potentieel vendor lock-in en onverwachte verlengingskostenSommige CA's bieden lage initiële prijzen, maar rekenen aanzienlijk hogere kosten bij verlenging of bij het toevoegen van nieuwe SAN-items. Bekijk altijd het volledige prijsmodel en de verlengingsvoorwaarden voordat u een contract afsluit. 

Waarom het uitmaakt: Schaalbaarheid kan worden beïnvloed door de prijs, vooral als er veel domeinen tegelijkertijd worden beheerd. 

Certificaatvalidatietype 

CA's bieden drie soorten validatie: 

Validatietype	Verificatieniveau	Vertrouwensindicatoren	beste voor
DV (Domeinvalidatie)	Verifieert alleen domeineigendom	Hangslot in browser	Interne sites, persoonlijke blogs, applicaties met een laag risico
OV (Organisatievalidatie)	Verifieert domein- en organisatie-identiteit	Hangslot + organisatiegegevens in certificaatinfo	Zakelijke websites, API's, openbare apps
EV (Uitgebreide Validatie)	Uitgebreide screening van het bedrijf en het juridische bestaan	Hangslot + organisatienaam in de adresbalk van de browser (in sommige browsers)	Financiële dienstverlening, e-commerce, gereguleerde sectoren

Voor het verwerken van gevoelige gegevens, het uitvoeren van openbare diensten of het streven naar een hoog vertrouwen, kunt u het beste kiezen voor OV of EV. 

Gemakkelijk certificaatbeheer 

Zoek naar CA's die het volgende aanbieden: 

• Managementdashboards of API's 
• Certificaatautomatisering (bijvoorbeeld via ACME protocol) 
• Herinneringen voor verlenging 
• SAN ondersteunt flexibele heruitgifte (eenvoudig domeinen toevoegen/verwijderen) 

Waarom dit belangrijk is: Efficiënt en vereenvoudigd beheer vermindert de overheadkosten en helpt bij het oplossen van problemen met het verlopen van certificaten. 

Ondersteuning voor aangepaste vereisten

Overwegen: 

• Wildcard SAN-ondersteuning (bijv. *.example.com) 
• IP-adresopname 
• Ondersteuning voor interne domeinen (bijv. dev.local) 
• Integratie met uw infrastructuur (bijv. Microsoft Exchange, AWS, Kubernetes) 

Let op: Niet alle CA's ondersteunen de combinatie van wildcarddomeinen en SAN-vermeldingen in hetzelfde certificaat. Sommige leggen beperkingen op of vereisen mogelijk een andere productlaag. Controleer deze mogelijkheid als uw use case beide omvat. 

Waarom het uitmaakt: Sommige CA's hebben mogelijk speciale configuraties nodig of bieden beperkte ondersteuning voor interne namen, IP-adressen of complexe wildcard-/SAN-instellingen. Als u deze limieten begrijpt, kunt u implementatieproblemen voorkomen. 

Klantenservice en SLA's 

Bij het evalueren van een CA, geef prioriteit aan die welke het volgende bieden: 

• 24/7 Klantenservice 
• Snelle uitgifte en heruitgifte van SLA's 
• Speciale ondersteuning voor grote ondernemingen (voor grote implementaties) 

Tijd tot uitgifte is belangrijk:Sommige CA's kunnen binnen enkele minuten Domeinvalidatie (DV)-certificaten uitgeven, terwijl OV/EV uren of dagen kan duren, afhankelijk van het verificatieproces. 
Downtime bij heruitgifte Ook moet rekening worden gehouden met vertragingen bij het vervangen van verlopen of gecompromitteerde certificaten. Dit kan leiden tot serviceonderbrekingen of beveiligingswaarschuwingen voor gebruikers. 

Waarom het uitmaakt: Tijdige ondersteuning is essentieel bij storingen of verlengingen. 

Hoe encryptieconsultancy kan helpen 

Het beheren van SAN-certificaten voor meerdere domeinen, subdomeinen en IP-adressen kan al snel een uitdaging worden, vooral op grote schaal. Daar komt CertSecure Manager van Encryption Consulting om de hoek kijken. 

Het Certificaatlevenscyclusbeheer (CLM) De oplossing automatiseert en stroomlijnt het hele proces – van detectie en uitgifte tot verlenging en intrekking. Of u nu interne services, cloudworkloads of complexe multidomeinomgevingen beveiligt, CertSecure Manager biedt: 

• Gecentraliseerde certificaatinventaris, inclusief SAN-vermeldingen 
• Geautomatiseerde uitgifte en verlenging met behulp van toonaangevende CA's 
• Beleidsgestuurde controles en goedkeuringsworkflows 
• Realtime waarschuwingen om vervaldata of verkeerde configuraties te voorkomen 
• Gedetailleerde auditlogs en nalevingsrapportage 

Ondersteunde integraties: CertSecure Manager integreert naadloos met grote CA-platforms zoals DigiCert, Sectigo en andere via hun APIsHet ondersteunt ook op het ACME-protocol gebaseerde clients (bijvoorbeeld Let's Encrypt) en kan verbinding maken met infrastructuurtools zoals Microsoft CA, AWS en Azure Key Vault. 

Met CertSecure Manager kunnen organisaties vol vertrouwen SAN SSL-certificaten beheren met efficiëntie, zichtbaarheid en controle, allemaal vanaf één platform. 

Conclusie 

SAN-certificaten bieden een slimme, schaalbare oplossing voor het beveiligen van meerdere domeinen, subdomeinen en services met één certificaat. Of u nu een complexe infrastructuur beheert of gewoon SSL-beheer wilt vereenvoudigen, SAN-certificaten bieden flexibiliteit, kostenefficiëntie en sterke beveiliging, waardoor ze essentieel zijn voor moderne digitale omgevingen.