en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Den 1 november kommer - Är din Exchange Server redo?

1 november 2015: Nya regler träder i kraft

Dina vänner på SSL.com vill berätta om det från början November 1st, 2015, Vissa mycket viktiga förändringar om vad som kan täckas i SSL-certifikat träder i kraft:

  • Nya certifikat som innehåller interna namn kommer inte längre att utfärdas av någon certifikatutfärdare enligt CA / Browser Forum-riktlinjerna (dvs alla ansedda)
    Observera att SSL.com under en tid inte har utfärdat intranätcertifikat till interna namn med utgångsdatum efter den 1 november 2015 och SSL.com-kunder bör därför inte stöta på några omedelbara problem, men vi uppmanar dig att dubbelkolla dina certifikat för potentiella sätt som dessa beslut kan påverka dig.
  • Befintliga certifikat som innehåller interna namn kommer inte att utfärdas igen efter den 1 november 2015.
    Återigen har SSL.com arbetat för att se till att du inte får problem på grund av detta - men vi har presenterat ett värsta fall för din utbyggnad nedan.
  • Befintliga certifikat som innehåller interna namn återkallas automatiskt den 1 november 2016.
    Det här är en heltäckande policy, eftersom vissa säkerhetsarkitekturer kan ha gamla existerande certifikat som inte följer dessa regler.

Dessa förändringar innebär att e-post - internetets första och ändå mest användbara verktyg - kan påverkas negativt av förändringar, särskilt om du använder Microsofts Exchange Server (vilket marknadsundersökningen föreslår är 63 procent av alla). Således kan din säkerhetsarkitektur börja påverkas från och med kommande All Saint's Day.

Är du redo?

Vad menar du när du säger ”interna namn”?

Den enklaste definitionen av ett internt namn är vilken nätverksidentifierare som helst del av ett privat nätverk och inte nås med ett namn som använder en toppnivådomän (TLD) eller unik IP-adress. I praktiken kan alla nätverks-ID som är offentligt registrerade hos en central myndighet som ICAAN användas i certifikat

Under de tidigare, enklare dagarna på internet behövde en intern DNS-arkitektur bara oroa sig för att undvika en begränsad uppsättning TLD: er - så AwfulBigCo.coms intranät kunde inte bara stödja ABC.nyc och ABC.london men 1600. Pennsylvania.ave, post och Gandalf. Dessutom, vissa IPv4- och IPv6-adresser är avsatta för rent lokalt bruk - dessa reserverade intervall inkluderar ”192.168. *. *” för routing och 10. *. *. * för lokala nätverk. Att säkra intranät med SSL-certifikat är naturligtvis en bra idé, och fram till det nya beslutet kan alla nätverksadministratörer begära och få ett certifikat som innehåller något av dessa.

Från och med den 1 november 2015 kommer detta inte längre att vara fallet - certifikat kommer inte längre att utfärdas - eller, avgörande, RE-utfärdad - som innehåller interna namn. Dessa nya regler är utformade för att både förbättra säkerheten och möjliggöra korrekt användning av nya domännamn på toppnivå (till exempel är både .london och .nyc offentliga toppdomäner nu). De kräver dock att alla Exchange-användare tittar hårt på nätverks- och säkerhetsinställningarna och gör ändringar för att erkänna dessa nya regler. Eftersom många Exchange säkerhets mönster har historiskt utnyttjat interna namn, kan detta leda till allvarliga problem med din e-posttjänst när och som dina certifikat löper ut, eftersom nya certifikat med interna namn inte kan utfärdas för att ersätta dina befintliga - ännu värre, alla multi-domain certifikat som innehåller till och med ett internt namn kommer att misslyckas vid förnyelse, vilket potentiellt kan utsätta din e-posttrafik för skadliga exploateringar.

Om du inte gör detta kan det påverka din e-posttrafik, ditt företag och / eller ditt rykte negativt.

Låter dyster.

Det kan mycket väl vara - det beror verkligen på hur beredd du är. Detta kan vara ett mycket enkelt problem att missa, och konsekvenserna kan vara helt ödesdigra för ditt företag - if du misslyckas med att agera i förväg.

Exempelvis: Robert Dobbs är seniorsadmin för AwfuBigCo. Bland andra jobb hanterar han (teoretiskt) företagets säkerhetscertifikat. De har emellertid ställts in på automatisk förnyelse varje 2 november - vilket har hänt som urverk sedan långt innan Bob kom hit, och han ser aldrig ens fakturan. Någonstans innan Dres comebackalbum konfigurerades AwfulBigCos nätverksarkitektur för att inkludera fyra Exchange-servrar med namnet “Abc.exchange”"Post", "Mail2" och ”Gandalf”, plus en intern IP-adress (10.10.10.10) inställd för säkra FTP-säkerhetskopior och två servrar som används för utvecklingsteamet i London och New York. De har skyddat sina Exchange-servrar OCH sina andra domäner med en UCC-certifikat som innehåller följande poster:

* .awfulbigco.com
* .awfulbigco.co.uk
awfulbigco.london
hemsktbigco.nyc
abc.exchange

Gandalf
Post
mail2
10.10.10.10

2 november 2015. Bob får ett telefonsamtal från Elaine i International Fulfillment - hon har problem med Outlook. Medan han pratar med henne genom att kontrollera hennes inställningar får han en text från Nathan i den brittiska filialen - några av bilderna på webbplatsen är trasiga och beställningsformulärets tidsavbrott. Sedan en ny text från en VP för marknadsföring som vill veta varför hans demo i Singapore precis kratererade framför ett styrelserum med potentiella investerare ... Och tro det eller inte, Bobs dag kommer att bli mycket, mycket värre innan det blir bättre.

Se, AwfulBigCos certifikatleverantör sprang sin begäran förbi sina robotar, upptäckte de interna namnen och (enligt CA / B-forumreglerna) avvisade förnyelsen.

Det här är ett problem. UCC kommer INTE att förnyas och inte bara kommer tjänster som använder de tillåtna interna namnen (dvs. all företagsmail och FTP-säkerhetskopior) inte längre skyddas - inte heller några ÖVRIGA domäner som ingår i UCC, som primär och .co. uk domäner för AwfulBigCo.

Visst, detta är ett extremt värsta fall - men vi tror verkligen att full säkerhet beror på att förbereda för just det.

Observera att vårt team på SSL.com definitivt skulle ha flaggat AwfulBigCos installation vid sin senaste förnyelse för att hjälpa Bob att undvika dessa exakta problem. Faktum är att alla ansedda CA skulle vidta åtgärder för att hjälpa sina kunder före tidsfristen den 1 november - om de ställdes, och om Bob visste vilka frågor han skulle ställa - hej, det är därför vi presenterar den här artikeln.

Okej, jag är Legit Scared - Vad gör jag nu?

Om du använder interna namn i dina SSL-certifikat kommer du att behöva vidta åtgärder för att hantera detta, och ju tidigare desto bättre.

I grund och botten finns det några alternativ du kan välja:

  1. Konfigurera systemet för att endast använda offentligt registrerade domännamn.
    Detta är förmodligen den bästa lösningen - det gör det interna namnet problem och kommer att vara enklare totalt sett att underhålla och utöka framöver. Tyvärr kommer det här alternativet troligen att kräva betydande arbete framåt, men Microsoft Exchange-servrar kan ställas in att använda fullt kvalificerade allmänna domännamn (och detta CA / webbläsarforum vitt papper berättar mer om implementering av FQDN i Active Directory-nätverk). Administration efter övergången kommer nästan säkert att vara så enkel eller enklare än tidigare (ett stort plus för Bob) och framöver kommer AwfulBigCo att kunna använda offentligt betrodda certifikat för att säkra all trafik både internt och externt. En möjlig nackdel med denna metod är att den kan tillåta att information om ett företags interna infrastruktur för att bli upptäckt via DNS, men kunniga konfiguration av DNS-zoner kan bidra till att lösa detta - till exempel genom att använda underdomäner som ”interna” eller separata domännamn och begränsad upplösning av dessa utanför företagsnätverk.
  2. Registrera interna namn som FQDN.
    Tyvärr är inget alternativ för den reserverade IP-adressen, och "Mail" och "Gandalf" naturligtvis rätt. (Vi antar för Bobs förnuft att domänerna .com och .co.uk redan är säkert registrerade - hans dag är tillräckligt tuff som den är.)
    Även om abc.exchange finns - och kom ihåg att .exchange är en av de nya toppdomänerna vars introduktion hjälper till att driva denna regeländring - det kan mycket väl vara på huk på och endast tillgänglig för en orimliga pris- enklare och billigare alternativ kommer sannolikt tillgängliga.
  3. Ställ in en Enterprise CA
    Detta är en metod som redan används av riktigt stora enheter som främst behöver säkra intern kommunikation. Ett företagscertifikat fungerar som en företagscertifikatmyndighet - i huvudsak, i stället för att kedjan av förtroende körs upp till en extern CA, skyddas alla certifikat i slutändan av ett internt genererat rotcertifikat. Även om detta ger större anpassning (och skulle göra det möjligt för Bob att upprätthålla arvet namngivningsstrukturen AwfulBigCo har på plats) det finns allvarliga säkerhetsproblem att tänka på - en Sony-stil hack kan utsätta företaget rotcertifikatet och / eller privat nyckel, vilket gör att nästan obegränsad utnyttjande av nätet. Också certifikat som utfärdas internt kommer INTE att lita på någon annanstans - det här är en metod som säkerställer intern kommunikation men som inte kan utöka förtroendet utanför ditt företagsnätverk. Slutligen är upprättandet av ett företags CA inte alls en lösning över natten, och det kan vara mycket svårare än de andra alternativen som listas här och därmed endast genomförbara för mycket stora (eller växande) nätverk.
    SSL.com erbjuder gärna konsult- och hanteringstjänster som hjälper dig att förhandla vägen till att skapa din egen Enterprise CA - bara skicka ett meddelande till enterpriseca@ssl.com och en av våra ledande administratörer kommer att kontakta dig snart.
  4. Använd självsignerade certifikat
    Det här alternativet har liknande nackdelar som för Enterprise CA, men skala inte bra - eftersom varje självsignerat certifikat inte har någon kedja av förtroende utöver sig själv, måste varje enskilt certifikat installeras på varje klient för att undvika felmeddelanden . Hantering över ett brett nätverk skulle också skapa en helt ny massa huvudvärk för stackars Bob - något så enkelt som automatiska webbläsaruppdateringar kan orsaka kaos om inte kontinuerlig vaksamhet bibehålls på varje enhet.

Som alltid, kontakta oss på SSL.com om du har några frågor. Kom ihåg - ett säkrare internet är ett bättre internet.

Relaterade artiklar

Prenumerera på SSL.coms nyhetsbrev

Vad är SSL /TLS?

Spela filmen

Prenumerera på SSL.coms nyhetsbrev

Missa inte nya artiklar och uppdateringar från SSL.com