Förstå SAN i X.509 SSL-certifikat

Vad är ett alternativt ämnesnamn (SAN) i SSL/TLS-certifikat? 

Subjektets alternativa namn (SAN) är en viktig utökning av X.509 certifikat standard, definierad i RFC 5280Det gör att SSL/TLS-certifikat kan inkludera flera identiteter utöver bara fältet Common Name (CN). Dessa identiteter kan inkludera domännamn, underdomäner, IP-adresser, e-postadresser med mera – vilket möjliggör säker kommunikation över en mängd olika slutpunkter. 

Genom att använda SAN-tillägget kan organisationer avsevärt förbättra flexibilitet, skalbarhetoch säkerhet av deras SSL-certifikat. Istället för att hantera separata certifikat för varje domän eller tjänst kan ett SAN-aktiverat certifikat säkra alla nödvändiga identiteter under ett enda certifikat, vilket förenklar certifikathanteringen och minskar driftskostnaderna. 

Före SAN: Begränsningen av vanliga namn (CN) 

I tidigare SSL-certifikat identifierades domännamnet som säkrades av certifikatet huvudsakligen genom CN-fältet. 

 Exempel: 

 Om CN var: 

CN = www.example.com 

Certifikatet skulle endast vara giltigt för: 

• www.example.com 

Om en användare besökte: 

• example.com 
• blogg.exampel.com 
• www.example.net 

De skulle få en säkerhetsvarning eftersom certifikatet inte överensstämmer med den begärda domänen. Moderna webbläsare förlitar sig inte längre på CN-fältet för domänvalidering – de validerar endast mot poster i SAN-fältet för bättre säkerhet och konsekvens, enligt gällande branschstandarder. 

Nackdelar med att enbart förlita sig på CN

• Endast ett enda fullständigt kvalificerat domännamn (FQDN) kunde säkras. 

• Ingen flexibilitet att inkludera underdomäner eller alternativa domäner. 

• Flera tjänster/domäner krävde separata certifikat. 

• Föråldrad praxisAtt enbart förlita sig på CN avråds på grund av säkerhetsrisker och kompatibilitetsproblem, eftersom många moderna webbläsare ignorerar CN och endast litar på SAN-listan för domänvalidering. 

Efter SAN: Flera domäner, ett certifikat 

Med hjälp av SAN förlängning, en enda SSL/TLS-certifikat kan säkra flera identiteter över olika tjänster. Dessa identiteter kan inkludera: 

• domäner (t.ex. blogg.example.com) 
• Helt olika domäner (t.ex. exempel.net) 

• IP-adresser (t.ex. 203.0.113.5) – Obs: IP-adresser i SAN måste matcha exakt; det finns inget stöd för subnät eller ofullständiga matchningar. 
• Interna värdnamn (t.ex. intranät.lokal) 
• Jokerteckendomäner (t.ex. *.example.com) – Jokerteckenposter i SAN-fält har begränsningar: de matchar bara en nivå av underdomänen (t.ex. *.example.com matchar blog.example.com men inte dev.blog.example.com), och inte alla certifikatutfärdare (CA:er) stöder jokerteckenposter i SAN:er. Kontrollera alltid certifikatutfärdarnas stöd och policyer innan du använder dem. 

Exempel: 

Ett SAN-aktiverat certifikat kan ha: 

CN = www.example.com 

SAN: 

  DNS.1 = www.example.com 

  DNS.2 = exempel.com 

  DNS.3 = blogg.example.com 

  DNS.4 = www.example.net 

  IP.1 = 203.0.113.5 

Detta certifikat är giltigt för alla listade DNS- och IP-poster. 

Fördelar: 

• Ett enda certifikat kan skydda flera tjänster. 
• Förenklar hanteringen – en förnyelse, en installation. 
• Det är kostnadseffektivt eftersom det eliminerar behovet av att köpa individuella certifikat. 
• Stöder modern webbinfrastruktur som mikrotjänster, API:er och plattformar med flera domäner. 
• SAN är nu en obligatorisk komponent i alla offentligt betrodda
• SSL-certifikat, enligt CA / Browser Forum Grundkrav, moderna webbläsare förlitar sig enbart på SAN-fältet för domänvalidering. 

Varför använda ett SAN SSL-certifikat?  

• Säkra flera domäner med ett certifikat
  Skydda alla domäner under ett enda SSL-certifikat, vilket gör det enklare för organisationer att hantera flera webbplatser.
  Det är dock viktigt att notera att varje SAN-post måste valideras individuellt vid certifikatutfärdande. De flesta certifikatutfärdare kräver DNS-baserad eller HTTP-baserad domänvalidering för varje domän som ingår i SAN-listan för att säkerställa ägarskap och säkerhetsefterlevnad.
• Förenklad certifikathantering
  Minskar komplexitet och mänskliga fel genom att hantera, förnya och driftsätta bara ett certifikat istället för flera certifikat.
• Kostnadseffektivitet
  Minskar kostnaderna genom att inte köpa flera certifikat – många SAN-certifikat stöder upp till 100 domäner.
• Stöder komplexa infrastrukturer
  Perfekt för moderna konfigurationer som mikrotjänster, API:er och molnplattformar som använder olika underdomäner eller domäner.
• Krävs för webbläsarkompatibilitet
  Moderna webbläsare använder SAN-fältet, vilket gör SAN till en obligatorisk del av publika SSL-certifikat.
• Skalbar för framtida expansion
  Att lägga till domäner till certifikatet under förnyelse eller återutgivning är enkelt, vilket är bra för växande företag.
• Ökar förtroende och SEO
  HTTPS på alla domäner bygger användarförtroende, skyddar data och förbättrar Googles sökrankningar.

Hur fungerar ett SAN-certifikat? 

Skapande av certifikat med SAN 

Under genereringen av en certifikatsigneringsförfrågan (CSR) anger administratören en lista med SAN-poster. Dessa kan vara: 

• Fullt kvalificerade domännamn (FQDN) 
• domäner 
• IP-adresser 
• Mejladresser 
• URI:er (för specialiserade applikationer) 

För att inkludera dessa SAN-värden måste administratören definiera dem i fältet subjectAltName i CSR-konfigurationsfilen (vanligtvis openssl.cnf eller motsvarande). 
När CSR:n har skapats och skickats in till en CA, verifierar CA:n äganderätten till eller kontrollen över varje SAN-post. Efter lyckad validering utfärdar CA:n ett certifikat med SAN-posterna kodade i SAN-tillägget. 

Webbläsare/klient gör en säker begäran 

När en klient (som en webbläsare eller app) ansluter till en säker webbplats via HTTPS: 

• Under TLS handslag, servern presenterar sitt SSL-certifikat för klienten. 
• Certifikatet inkluderar: 
  1. Den offentliga nyckeln 
  2. CN (äldre fält) 
  3. SAN-tillägget med alla giltiga identiteter

Som en del av handskakningen utför klienten värdnamnsverifiering, där den kontrollerar om den begärda domänen matchar någon av posterna i SAN-fältet. Detta verifieringssteg är avgörande för att etablera förtroende – moderna klienter förlitar sig uteslutande på SAN-tillägget för denna kontroll och ignorerar CN-fältet. 

Klienten validerar SAN-listan 

Moderna webbläsare förlitar sig istället på SAN-listan och ignorerar CN. Klienten letar efter en matchning mellan: 

• Domännamnet den försöker ansluta till. 
• Något av namnen som anges i SAN-fältet. 

Anslutningen fortsätter säkert endast om en exakt eller giltig jokerteckensmatchning hittas. 

• Jokerteckensbeteende: Webbläsare stöder SAN-poster med jokerteckendomäner (t.ex. *.example.com), men jokertecknet kan bara matcha en nivå av underdomänen. Till exempel matchar *.example.com blog.example.com men inte shop.dev.example.com. 
• Interna namnModerna webbläsare och certifikatutfärdare accepterar inte längre interna namn (som localhost eller server.local) i offentliga certifikat. Om sådana namn inkluderas kommer certifikatet att anses vara ogiltigt eller opålitligt. 

Om ingen matchning hittas visar webbläsaren en säkerhetsvarning, till exempel ”Din anslutning är inte privat” eller ”Ogiltigt certifikat”. 

Ett certifikat, många domäner 

Eftersom SAN-listan innehåller flera identiteter kan ett certifikat användas för: 

• Flera webbplatser (t.ex. example.com, example.net) 
• Flera underdomäner (t.ex. shop.example.com, blog.example.com) 
• Olika tjänster (t.ex. Exchange Server, e-postserver, API-gateway) 

Detta gör hanteringen enkel och smidig, eftersom det nu inte finns något behov av att installera och hantera separata certifikat för varje domän. 

Vanliga användningsområden för SAN-certifikat (alternativt ämnesnamn) 

SAN-certifikat används inom många branscher och infrastrukturer tack vare deras stöd för flera domäner. De hjälper dig att skydda flera domäner, underdomäner och IP-adresser med ett enda certifikat, vilket gör det idealiskt för organisationer som söker skalbarhet och enkelhet. 

 Säkra flera webbplatser under en och samma organisation 

Användningsfall

Ett företag äger flera webbplatser eller varumärkesdomäner: 

• example.com 
• exempel.net 
• exempel.org 
• produkt.exampel.com 
• support.example.net 

Att köpa och hantera separata SSL-certifikat för varje certifikat är inte alls nödvändigt, eftersom ett företag nu kan använda ett enda SAN-certifikat för att skydda alla domäner och underdomäner. 

AnmärkningarVarje underdomän måste uttryckligen listas i SAN-fältet om inte ett jokertecken (t.ex. *.example.com) anges. Utan ett jokertecken är underdomänmatchningen exakt och olistade underdomäner kommer inte att täckas av certifikatet. 

Fördelar

• Centraliserad förvaltning 
• Kostnadsbesparingar 
• Enklare förnyelser och installationer 

Säkra applikationer med flera underdomäner 

Användningsfall 

En webbapplikation fungerar över olika underdomäner: 

• inloggning.example.com (autentisering) 
• api.example.com (backend-API) 
• dashboard.example.com (användarportal) 
• cdn.example.com (leverans av statiskt innehåll) 

Alla underdomäner läggs till som SAN-poster i ett certifikat. 

Fördelar

• Förenklar driftsättningen 
• Minskar spridningen av certifikat 
• Enhetlig utgångs- och förnyelsecykel 

Molnbaserade och mikrotjänstarkitekturer 

Användningsfall

Moderna applikationer, de som använder mikrotjänster eller molnplattformar, fungerar över: 

• Olika underdomäner 
• Separata regioner eller instanser 
• Olika toppdomäner (TLD:er) 

Exempel: 

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

Ett SAN-certifikat kan användas för att skydda alla dessa tjänster, även om de är geografiskt distribuerade eller sträcker sig över flera domäner. 

Hänsyn: Medan SAN-certifikat förenklar hanteringen, kan det skapa en enda felpunkt om man knyter för många tjänster till ett enda certifikat. Om certifikatet går ut, komprometteras eller behöver utfärdas på nytt påverkas alla tjänster som är beroende av det samtidigt. För att mildra detta bör organisationer noggrant gruppera tjänster efter risk och miljö, och använda separata SAN-certifikat när det är lämpligt. 

Fördelar

• Enklare certifieringsautomation (t.ex. via CI/CD) 
• Färre certifikat att förnya, färre felkonfigurationer 
• Säker tjänstekommunikation i hybridmolninstallationer 

Utvecklings-, staging- och testmiljöer 

Användningsfall

Utvecklare vill använda HTTPS på lokala domäner eller staging-domäner: 

• dev.example.local 
• staging.example.com 
• test-api.example.org 

Alla miljöer är säkrade med hjälp av SAN-certifikat, och det finns inget behov av flera certifikat. 

För interna miljöer som .local-domäner (t.ex. dev.example.local) rekommenderas det att använda en intern CA eller ett självsignerat SAN-certifikat. Publika CA:er utfärdar inte längre certifikat för interna namn på grund av säkerhetsrestriktioner som införts av CA/Browser Forum. 

Fördelar

• Möjliggör noggrann och säkrare testning i verkliga miljöer HTTPS förhållanden. 
• Snabbare CI/CD-testpipelines. 
• Bördan av manuell certifikathantering minskas. 

Microsoft Exchange Server och Office 365 

Användningsfall 

Microsoft Exchange och Skype for Business kräver SAN-certifikat för att fungera korrekt med flera interna och externa tjänster, som: 

• mail.example.com 
• autodiscover.example.com 
• smtp.example.net 
• Intern.utbyte.lokal 

För att förenkla distributionen rekommenderar Microsoft certifikat som stöder flera SAN-poster. 

A Unified Communications-certifikat (UCC) används ofta i dessa scenarier. Även om UCC vanligtvis kallas ett specialcertifikat, är det i huvudsak en marknadsföringsterm för ett multi-SAN-certifikat som är optimerat för Microsoft-applikationer som Exchange, Skype för företag och Office 365. 

Fördelar

• Stöder fullt ut Microsofts betrodda ramverk för certifikathantering. 
• Inget behov av flera certifikat, ett certifikat kan säkra alla tjänster (e-post, kalender, automatisk upptäckt etc.) 
• Enkel installation för hybrid Office 365-distributioner 

Att tänka på när du väljer en CA för SAN-certifikat

Rykte och förtroendenivå

Välj en globalt betrodd CA som är: 

• Erkänd av alla ledande webbläsare och operativsystem. 
• Följer alla riktlinjer som fastställts av CA/Browser Forum-standarder. 
• Känd för att implementera höga säkerhetsstandarder. 

Populära betrodda certifikatutfärdare: 

• DigiCert 
• Sectigo (tidigare Comodo) 
• Anförtro 
• Globalsign 
• Kör pappa 
• Let's Encrypt (för begränsade användningsfall, stöder SAN) 

Obs: Medan Låt oss kryptera är allmänt betrodd och idealisk för kortsiktiga, automatiserade implementeringar, kan det inte lämplig för längre certifikatlivslängder or komplexa företagsbehov som kräver utökad validering (EV), organisationsvalidering (OV) eller avancerade support- och rapporteringsfunktioner. 

Varför det är viktigt: Med offentligt förtroende ser användarna inte varningarna om "Otillförlitligt certifikat" 

Prissättning och licensiering 

Priserna på SAN-certifikat kan variera beroende på: 

• Antal inkluderade SAN:er (vissa inkluderar 2–5 SAN:er som standard) 
• Kostnad per ytterligare SAN-post 
• Valideringsnivå (DV, OV, EV) 

Försiktighet: Var medveten om potential leverantörens inlåsning och oväntade förnyelsekostnaderVissa CA:er erbjuder låga initialpriser men tar ut betydligt högre avgifter vid förnyelse eller när nya SAN-poster läggs till. Granska alltid hela prismodellen och förnyelsevillkoren innan du binder dig. 

Varför är det viktigt Skalbarhet kan påverkas av prissättning, särskilt om många domäner hanteras samtidigt. 

Certifikatvalideringstyp 

CA:er erbjuder tre typer av validering: 

Valideringstyp	Verifieringsnivå	Förtroendeindikatorer	bäst för
DV (Domänvalidering)	Verifierar endast domänägande	Hänglås i webbläsaren	Interna webbplatser, personliga bloggar, lågriskapplikationer
OV (Organisationsvalidering)	Verifierar domän + organisationsidentitet	Hänglås + organisationsuppgifter i certifikatinformationen	Företagswebbplatser, API:er, publika appar
EV (Utökad validering)	Omfattande granskning av verksamheten + juridisk existens	Hänglås + organisationsnamn i webbläsarens adressfält (i vissa webbläsare)	Finansiella tjänster, e-handel, reglerade branscher

För att hantera känsliga uppgifter, driva offentliga tjänster eller sträva efter högt förtroende bör du välja OV eller EV. 

Enkel certifikathantering 

Leta efter CA:er som erbjuder: 

• Hanteringspaneler eller API:er 
• Certifikatautomatisering (t.ex. via ACME protokoll) 
• Påminnelser om förnyelse 
• SAN stöder flexibel återutgivning (lägg till/ta bort domäner enkelt) 

Varför det är viktigt: Effektiv och förenklad hantering minskar omkostnader och hjälper till med problem med certifikatutgångsdatum. 

Stöd för anpassade krav

Överväga: 

• Stöd för Wildcard SAN (t.ex. *.example.com) 
• Inkludering av IP-adress 
• Internt domänstöd (t.ex. dev.local) 
• Integration med er infrastruktur (t.ex. Microsoft Exchange, AWS, Kubernetes) 

Obs: Inte alla certifikatutfärdare har stöd för att kombinera jokerteckendomäner och SAN-poster i samma certifikat. Vissa har restriktioner eller kan kräva en annan produktnivå. Se till att verifiera denna funktion om ditt användningsfall inkluderar båda. 

Varför är det viktigt Vissa certifikatutfärdare kan behöva speciella konfigurationer eller erbjuda begränsat stöd för interna namn, IP-adresser eller komplexa jokertecken-/SAN-inställningar – att förstå dessa begränsningar hjälper till att undvika distributionsproblem. 

Kundsupport och servicenivåavtal 

När man utvärderar en CAprioritera de som erbjuder: 

• 24 / 7 support 
• Snabb utfärdande och återutfärdande av SLA:er 
• Dedikerad företagssupport (för stora implementeringar) 

Tidspunkten för utfärdande är viktigVissa CA:er kan utfärda domänvalideringscertifikat (DV) inom några minuter, medan OV/EV kan ta timmar eller dagar, beroende på verifieringsprocesser. 
Återutgivningsstopp bör också beaktas – förseningar i att ersätta utgångna eller komprometterade certifikat kan leda till avbrott i tjänsten eller säkerhetsvarningar för användare. 

Varför är det viktigt Snabb support är avgörande vid avbrott eller förnyelser. 

Hur krypteringskonsulting kan hjälpa 

Att hantera SAN-certifikat för flera domäner, underdomäner och IP-adresser kan snabbt bli en utmaning – särskilt i stor skala. Det är där Encryption Consultings CertSecure Manager kommer in i bilden. 

Vår Certifikatlivscykelhantering (CLM) Lösningen automatiserar och effektiviserar hela processen – från identifiering och utfärdande till förnyelse och återkallelse. Oavsett om du säkrar interna tjänster, molnarbetsbelastningar eller komplexa miljöer med flera domäner, CertSecure-hanterare erbjuder: 

• Centraliserad certifikatinventering, inklusive SAN-poster 
• Automatiserad utfärdande och förnyelse med hjälp av ledande CA:er 
• Policydrivna kontroller och arbetsflöden för godkännande 
• Realtidsaviseringar för att förhindra utgångsdatum eller felkonfigurationer 
• Detaljerade revisionsloggar och efterlevnadsrapportering 

Integrationer som stöds: CertSecure Manager integreras sömlöst med större CA-plattformar som DigiCert, Sectigo och andra via deras API: erDen stöder även ACME-protokollbaserade klienter (t.ex. Let's Encrypt) och kan ansluta till infrastrukturverktyg som Microsoft CA, AWS och ... Azure Key Vault. 

Med CertSecure Manager kan organisationer tryggt hantera SAN SSL-certifikat med effektivitet, insyn och kontroll – allt från en enda plattform. 

Slutsats 

SAN-certifikat erbjuder en smart och skalbar lösning för att säkra flera domäner, underdomäner och tjänster med ett enda certifikat. Oavsett om du hanterar en komplex infrastruktur eller bara vill förenkla SSL-hanteringen, ger SAN-certifikat flexibilitet, kostnadseffektivitet och stark säkerhet – vilket gör dem viktiga för moderna digitala miljöer.