Bedrijven hebben lang gebruik gemaakt van certificaten om de interne servers van hun topleveldomeinen te beveiligen maar het CA/B Forum vond dit geen veilige keuze. Het CA/Browser Forum, dat de Baseline Requirements (BR's) beheert en de industrienorm voor het gebruik van SSL-certificaten bepaalt, heeft op 1 november 2015 vastgelegd dat er niet langer openbaar vertrouwde SSL-certificaten voor Internal Server Names of gereserveerde IP-adressen uitgegeven mogen worden.
Toen de BR op 1 juli 2012 van kracht werden, werd gespecifieerd dat “een CA geen certificaat mag uitgeven na 1 november 2015 waar de Subject Common Name of SAN een gereserveerd IP-adres of interne server bevat. Vanaf 1 oktober 2016 zullen CA's alle geldige certificaten revoceren." GlobalSign geeft in overeenstemming met deze tijdslijn geen certificaten meer uit en heeft ondertussen ook allen geldige certificaten ongeldig verklaard.
Heel wat bedrijven hebben natuurlijk hun hele interne structuur op deze interne servers draaien maar willen ze toch nog graag beveiligen. En daar helpen we natuurlijk graag bij. Bedrijven die Internal Server Names gebruiken hebben een aantal mogelijkheden:
Wat is een internal server name?
Een internal server name (deze kan al dan niet een ongeregistreerde domeinnaam bevatten) is er eentje dat geen gebruik maakt van openbare DNS, zoals bijvoorbeeld:
- Een naam van een niet-publiek toegankelijke domeinsuffix (e.g. mydomain.local, mydomain.internal)
- NetBIOS namen of korte hostname, kortom alles zonder een publiek domein
Wat is een reserved IP address?
Een reserved IP , of zogenoemd gereserveerd IP-adres, is een IPv4- of IPv6-adres dat door het IANA als gereserveerd gemarkeerd is, bijvoorbeeld:
- Elk IPv4-adres in de RFC 1918-bereik e.g. 10.0.0.0, 172.16.0.0, 192.168.0.0)
- Elk IPv6-adres in de RFC 4193-bereik
Maar waarom mogen interne servers geen publiek vertrouwde SSL hebben?
De eerste reden is eigenlijk nogal logisch, ze zijn nergens geregistreerd, ze zijn niet uniek. Omdat ze enkel intern gebruikt worden en vaak niet publiek toegankelijk zijn, kan de certificaatsautoriteit de identiteit te controleren van het bedrijf dat eigenaar is (vb. veel bedrijven maken gebruik van interne mailservers op het adres “https://mail/”).
Er is ook een risico van misbruik wanneer openbaar vertrouwde certificaten uitgegeven worden aan deze niet-unieke namen. Laten we nu het volgende scenario even als voorbeeld bekijken: een organisatie maakt gebruik van “https://mail/” voor hun mailservers. Aangezien deze naam niet uniek is kan iedereen er eigenlijk gebruik van maken en een certificaat aanvragen voor “https://mail/”. Wanneer ze dit in het bedrijfsnetwerk toevoegen kan met spoofing van de local name de echte bedrijfsserver geïmiteerd worden om zo toegang te krijgen tot de inhoud van alle e-mails.
Dit is natuurlijk een wat oppervlakkige uitleg, mocht je nu op zoek zijn naar nog meer gedetailleerde uitleg, ga dan zeker even een kijkje nemen in deze white paper van het CA/Browser Forum.
Opties voor internal of local SSL-certificaten
Dus wat kan je nu doen als je servers hebt met interne servernamen en/of gereserveerde IP's maar die je toch graag wil beveiligen met SSL? Dan zijn er toch nog een paar opties voor jou:
- Migreren naar geregistreerde domeinnamen – op lange termijn een zeer goede oplossing en je kan certificaten blijven aanschaffen bij uw CA provider
- Een eigen CA installeren en gebruiken - maar hier zijn natuurlijk ook kosten aan verbonden voor de aankoop, de configuratie en het beheer van de eigen CA en OCSP-services.
- Selfsigned of zogenaamde “zelfondertekende” SSL-certificaten gebruiken - maar dit is enkel aan te raden in een beperkte omgeving (vb met testservers) Het toont ons hoe foutmeldingen bij belangrijke browsers tot beveiligingsrisico's kunnen leiden wanneer ze een self-signed certificaat buiten het bedrijf ook gaan accepteren
- SSL-certificaten kopen onder een trusted root CA van een vertrouwde CA-provider - dit is een goede optie wanneer je dezelfde namen wil blijven gebruiken en niet voor een eigen CA of selfsigned certificaten wil kiezen.
- Maar de eenvoudigste oplossing bij GlobalSign is simpelweg SSL-certificaten kopen onder een niet-openbare hiërarchie.
Die laatste aanpak is waarschijnlijk de beste als je niet wil, of kan, migreren naar FQDN's omdat je het huidige CA-portaal wil blijven gebruiken om al je SSL-certificaten op één plaats te beheren. Hier kan je dan Extended Validation (EV), Organization Validation (OV) bestellen en daarbij kunnen certificaten voor intern gebruik uitgegeven worden onder niet-openbare roots. Hierdoor kunnen bedrijven gebruik maken van alle voordelen van een gehoste CA-oplossing, inclusief verlengingsherinneringen/rapporten, centrale rapportering en inventarisbeheer, API's voor de volledig automatische uitgifte van certificaten, gedelegeerd gebruikersbeheer met de flexibiliteit om interne servers en toepassingen te ondersteunen.
GlobalSign IntranetSSL
Wij wouden bedrijven graag de mogelijkheid geven om SSL te gebruiken om toch hun internal server names en gereserveerde IP’s te beveiligen zonder hun eigen CA te runnen of self-signed certificaten te gaan gebruiken. Daarom hebben we IntranetSSL, ontwikkeld, een product als toevoeging in onze cloud-based portaal voor certificaatbeheer waarmee rechtstreeks certificaten voor bedrijven kunnen worden uitgegeven op basis van vooraf gevalideerde bedrijfsprofielen en -domeinen en Internal Server Names. IntranetSSL maakt gebruik van niet-openbaar vertrouwde rootcertificaten (roots die niet worden verdeeld door de browsers en verdelers van besturingssystemen); bovendien worden de certificaten niet beperkt door de Baseline Requirements.
Bedrijven kunnen op een eenvoudige manier de nodige IntranetSSL niet-openbare roots beschikbaar maken aan hun gebruikers via Group Policy Object (GPO) of een ander centraal beheersysteem dat ervoor zorgt dat hun gebruikerscommunity IntranetSSL-certificaten vertrouwt.
Drie belangrijkste kenmerken van IntranetSSL
| 1 |
Internal Server names en reserved IP-adressen: |
| 2 |
Flexibele soorten keys/hashingalgorithmen: |
| 3 |
Langere geldigheidsduur: |
Zit je nu na deze uitleg toch nog met vragen over het gebruik van SSL voor interne servernamen? Aarzel dan zeker niet om contact met ons op te nemen. Mocht je nog op zoek zijn naar meer informatie over de Baseline Requirement en de afschaffing van openbaar vertrouwde SSL-certificaten voor interne servers, dan raden we deze white paper aan.
