1 november komt eraan - Is uw Exchange Server gereed?

1 november 2015: Nieuwe regels van kracht

Uw vrienden op SSL.com willen u dat begin laten weten November 1st, 2015sommige zeer belangrijke veranderingen over wat kan worden gedekt SSL-certificaten worden van kracht:

  • Nieuwe certificaten met interne namen worden niet langer uitgegeven door een certificeringsinstantie volgens de richtlijnen van het CA / Browser Forum (dwz alle gerenommeerde)
    Merk op dat SSL.com al geruime tijd geen intranetcertificaten meer uitgeeft aan interne namen met vervaldatums na 1 november 2015 en dat SSL.com-klanten dus geen directe problemen mogen ondervinden, maar we raden u ten zeerste aan om uw certificaten nogmaals te controleren voor mogelijke manieren waarop deze uitspraken van invloed kunnen zijn op u.
  • Bestaande certificaten met interne namen worden na 1 november 2015 niet opnieuw uitgegeven.
    Nogmaals, SSL.com heeft er alles aan gedaan om ervoor te zorgen dat u hierdoor geen problemen zult ondervinden - maar we hebben hieronder een worstcasescenario voor uw opbouw gepresenteerd.
  • Bestaande certificaten met interne namen worden AUTOMATISCH INGETROKKEN op 1 november 2016.
    Dit is een allesomvattend beleid, aangezien sommige beveiligingsarchitecturen mogelijk al lang bestaande verouderde certificaten hebben die deze regels niet naleven.

Deze veranderingen betekenen dat e-mail - de eerste en nog steeds handigste tool van internet - negatief kan worden beïnvloed door wijzigingen, vooral als u Microsoft's Exchange Server gebruikt (waarvan marktonderzoek suggereert dat 63 procent van jullie allemaal bestaat). Zo kan uw beveiligingsarchitectuur vanaf de komende Allerheiligen worden beïnvloed.

Ben je klaar?

Wat bedoel je als je "interne namen" zegt?

De eenvoudigste definitie van een interne naam is elke netwerk-ID die onderdeel van een particulier netwerk en niet bereikbaar met een naam via een top level domain (TLD) of uniek IP-adres. Als gevolg hiervan zal elke netwerk-ID die openbaar is geregistreerd bij een centrale autoriteit zoals ICAAN, bruikbaar zijn in certificaten

In de vroegere, eenvoudigere dagen van internet hoefde een interne DNS-architectuur zich alleen zorgen te maken over het vermijden van een beperkte set TLD's - dus het intranet van AwfulBigCo.com kon niet alleen ABC.nyc en ABC. Londen maar 1600. pennsylvania.ave, mail en Gandalf. Voorts sommige reeksen IPv4- en IPv6-adressen zijn gereserveerd voor puur lokaal gebruik - deze gereserveerde bereiken omvatten "192.168. *. *" voor routing en 10. *. *. * voor lokale netwerken. Het beveiligen van intranetten met SSL-certificaten is natuurlijk een goed idee, en tot de nieuwe uitspraak kon elke netwerkbeheerder een certificaat aanvragen en ontvangen dat een van deze certificaten bevatte.

Met ingang van 1 november 2015 is dit niet meer het geval - certificaten worden niet meer uitgegeven - of, cruciaal, opnieuw uitgegeven - die interne namen bevatten. Deze nieuwe regels zijn ontworpen om zowel de veiligheid te verbeteren als om het juiste gebruik van nieuwe domeinnamen op het hoogste niveau mogelijk te maken (bijvoorbeeld, zowel .london als .nyc zijn nu openbare TLD's). Ze vereisen echter dat elke Exchange-gebruiker zijn netwerk en beveiligingsinstellingen goed bekijkt en wijzigingen aanbrengt om deze nieuwe regels te erkennen. Aangezien veel Exchange-beveiligingsontwerpen in het verleden interne namen hebben gebruikt, kan dit ernstige problemen met uw e-mailservice veroorzaken wanneer en naarmate uw certificaten verlopen, aangezien nieuwe certificaten met interne namen niet kunnen worden uitgegeven om uw bestaande te vervangen - erger nog, elk multi-domein certificaat met zelfs maar één interne naam zal mislukken bij verlenging, waardoor uw e-mailverkeer mogelijk wordt blootgesteld aan kwaadaardige exploits.

Als u dit niet doet, kan dit een negatief effect hebben op uw e-mailverkeer, uw bedrijf en / of uw reputatie.

Klinkt verschrikkelijk.

Het zou heel goed kunnen - het hangt er echt van af hoe goed je bent voorbereid. Dit kan een heel gemakkelijk probleem zijn om over het hoofd te zien, en de gevolgen kunnen absoluut fataal zijn voor uw bedrijf - if u handelt niet van tevoren.

Voorbeeld: Robert Dobbs is een senior sysadmin voor AwfuBigCo. Hij beheert onder meer (theoretisch) de beveiligingscertificaten van het bedrijf. Die zijn echter ingesteld om elke 2 november automatisch te vernieuwen - wat al lang voordat Bob hier aankwam als een uurwerk ging, en hij ziet zelfs de factuur nooit. Ergens terug voor het comeback-album van Dre, was de netwerkarchitectuur van AwfulBigCo geconfigureerd om vier Exchange-servers te bevatten met de naam "Abc.exchange""Mail", "Mail2" en “Gandalf”, plus een intern IP-adres (10.10.10.10) dat is ingesteld voor veilige FTP-back-ups en twee servers die worden gebruikt voor de ontwikkelingsteams van Londen en New York. Ze hebben hun Exchange-servers EN hun andere domeinen beschermd met één DWU-certificaat met de volgende vermeldingen:

* .awfulbigco.com
* .awfulbigco.co.uk
verschrikkelijkbigco.london
verschrikkelijkbigco.nyc
abc. uitwisseling

Gandalf
E-mailadres
Post2
10.10.10.10

2 november 2015. Bob krijgt een telefoontje van Elaine in International Fulfilment - ze heeft problemen met Outlook. Terwijl hij haar door het controleren van haar instellingen praat, krijgt hij een sms van Nathan in het Britse filiaal - sommige afbeeldingen op de website zijn kapot en het bestelformulier loopt uit. Dan nog een sms van een VP Marketing die wil weten waarom zijn demo in Singapore zojuist kraterde voor een directiekamer van potentiële investeerders ... En geloof het of niet, Bob's dag gaat veel worden, veel erger voordat het beter wordt.

Kijk, de certificaatprovider van AwfulBigCo heeft hun verzoek voorbij hun robots geleid, die interne namen gedetecteerd en (volgens de CA / B-forumregels) de verlenging afgewezen.

Dit is een probleem. De UCC wordt NIET vernieuwd en niet alleen services die de gekozen interne namen gebruiken (dwz alle zakelijke mail en de FTP-back-ups) worden niet langer beschermd - evenmin zullen ANDERE domeinen die in de UCC zijn opgenomen, zoals de primaire en .co. uk-domeinen voor AwfulBigCo.

Natuurlijk, dit is een extreem worstcasescenario, maar we geloven echt dat volledige beveiliging afhangt van de voorbereiding op precies dat.

Merk op dat ons team bij SSL.com de installatie van AwfulBigCo zeker zou hebben gemarkeerd bij hun laatste verlenging om Bob te helpen deze exacte problemen te vermijden. Elke gerenommeerde CA zou inderdaad stappen ondernemen om hun klanten te helpen vóór de deadline van 1 november - indien gevraagd, en als Bob wist welke vragen hij moest stellen - hey, daarom presenteren we dit artikel.

Oké, ik ben bang - wat moet ik nu doen?

Als u interne namen gebruikt in uw SSL-certificaten, MOET u maatregelen nemen om dit aan te pakken, en hoe eerder hoe beter.

In principe zijn er een paar opties die u kunt kiezen:

  1. Configureer het systeem opnieuw om alleen openbaar geregistreerde domeinnamen te gebruiken.
    Dit is waarschijnlijk de beste oplossing - het maakt de interne naamkwestie betwistbaar en zal in het algemeen eenvoudiger te onderhouden en uit te breiden zijn. Helaas vereist deze optie waarschijnlijk veel werk van tevoren, maar Microsoft Exchange-servers kunnen worden ingesteld om volledig gekwalificeerde openbare domeinnamen te gebruiken (en dit CA / Browser Forum wit papier vertelt meer over het implementeren van FQDN's in Active Directory-netwerken). Administratie na de omschakeling zal vrijwel zeker net zo eenvoudig of eenvoudiger zijn dan voorheen (een groot pluspunt voor Bob) en in de toekomst zal AwfulBigCo in staat zijn om publiekelijk vertrouwde certificaten te gebruiken om al het verkeer zowel intern als extern te beveiligen. Een mogelijk nadeel van deze methode is dat informatie over de interne infrastructuur van een bedrijf kan worden ontdekt via DNS, maar een slimme configuratie van DNS-zones kan dit helpen aanpakken - bijvoorbeeld door subdomeinen zoals 'interne' of afzonderlijke domeinnamen te gebruiken en de resolutie te beperken hiervan buiten de bedrijfsnetwerken.
  2. Registreer interne namen als FQDN's.
    Helaas is er geen optie voor dat gereserveerde IP-adres, en "Mail" en "Gandalf" zijn natuurlijk gelijk. (We gaan er omwille van Bob's verstand van uit dat de .com- en .co.uk-domeinen al veilig zijn geregistreerd - zijn dag is al moeilijk genoeg.)
    Zelfs als abc. uitwisseling is beschikbaar - en onthoud dat .exchange een van de nieuwe TLD's is waarvan de introductie helpt om deze regelwijziging te stimuleren - het zou best gekraakt kunnen worden en alleen beschikbaar zijn voor een exorbitante prijs - gemakkelijkere en goedkopere alternatieven zijn waarschijnlijk beschikbaar.
  3. Stel een Enterprise CA in
    Dit is een methode die al wordt gebruikt door echt grote entiteiten die voornamelijk interne communicatie moeten beveiligen. Een enterprise-CA fungeert als een bedrijfscertificeringsinstantie - in feite worden in plaats van de vertrouwensketen die naar een externe CA loopt, alle certificaten uiteindelijk beveiligd door een intern gegenereerd rootcertificaat, hoewel dit meer maatwerk oplevert (en Bob in staat zou stellen om behoud van de oude naamgevingsstructuur die AwfulBigCo heeft), zijn er serieuze beveiligingsproblemen waarmee rekening moet worden gehouden - een hack in Sony-stijl kan het rootcertificaat en / of de privésleutel van het bedrijf blootleggen, waardoor bijna onbeperkte exploitatie van het netwerk mogelijk is. Bovendien zullen intern uitgegeven certificaten NIET elders worden vertrouwd - dit is een methode die de interne communicatie beveiligt, maar het vertrouwen niet buiten de muren van uw bedrijfsnetwerk kan strekken. Ten slotte is het opzetten van een bedrijfs-CA geenszins een oplossing van de ene op de andere dag en kan het veel moeilijker zijn dan de andere opties die hier worden vermeld, en dus alleen haalbaar voor zeer grote (of groeiende) netwerken.
    SSL.com biedt u graag advies- en beheerservices om u te helpen het pad te vinden om uw eigen Enterprise CA op te zetten - stuur gewoon een bericht naar enterpriseca@ssl.com en een van onze senior beheerders neemt spoedig contact met u op.
  4. Gebruik zelfondertekende certificaten
    Deze optie heeft vergelijkbare nadelen als die van de Enterprise CA, maar schaalt niet goed - aangezien elk zelfondertekend certificaat geen vertrouwensketen heeft buiten zichzelf, zou elk afzonderlijk certificaat op elke client moeten worden geïnstalleerd om foutmeldingen te voorkomen . Beheer over een breed netwerk zou ook voor een hele reeks nieuwe kopzorgen zorgen voor arme Bob - zoiets eenvoudigs als automatische browserupdates kunnen grote schade aanrichten, tenzij voortdurende waakzaamheid op elk apparaat wordt gehandhaafd.

Als altijd, deze link op SSL.com als u vragen heeft. Onthoud: een veiliger internet is een beter internet.

Abonneer u op de nieuwsbrief van SSL.com

Mis geen nieuwe artikelen en updates van SSL.com

Blijf geïnformeerd en veilig

SSL.com is een wereldleider op het gebied van cyberbeveiliging, PKI en digitale certificaten. Meld u aan om het laatste branchenieuws, tips en productaankondigingen te ontvangen van SSL.com.

We willen graag uw feedback

Vul onze enquête in en laat ons uw mening over uw recente aankoop weten.