Používáte ve vaší IT infrastruktuře interní domény jako .local a zároveň SSL certifikáty pro ověření jejich identity? V tom případě by neměl následující obsah uniknout Vaší pozornosti.
V následujících letech bude veřejnými certifikačními autoritami ukončena podpora SSL certifikátů, které používají právě interní doménová jména jako například server.domena.local.
Jak tento fakt ovlivní právě vaše použití SSL certifikátů pro zabezpečení šifrované komunikace a konfiguraci vašeho prostředí? Na úvod je nutné přednést, že veškeré změny řídí konsorcium výrobců internetových prohlížečů a veřejných certifikačních autorit CA/B Forum a jejich důvodem je zvýšení bezpečnosti šifrované komunikace a samotné důvěryhodnosti digitálních certifikátů.
Minimální délka klíče
První změnou v problematice digitálních certifikátů, která proběhla již k 1. lednu 2014 bylo zvýšení minimální povinné délky pro klíče certifikátů na 2048 bitů a certifikáty s nižší délkou klíče byly k tomuto datu zneplatněny. Veřejné certifikační autority již delší dobu neumožňovali nákup certifikátů s menší délkou klíče, dopad této změny je tak minimální.
I společnost Microsoft vydala pro tuto změnu potřebné aktualizace vztahující se k použití v rámci interních certifikačních autorit a produktů jako Internet Explorer a sady Office. Aplikace Outlook 2010 a novější tak neumožňuje podepsání či šifrování e-mailu s certifikátem o kratší délce klíče než 2048 bitů. Nadále ovšem umožňuje otevření a validaci zpráv, které jsou takovými certifikáty chráněny. Stejně tak není podporováno spojení k serverům Exchange, které pro SSL/TLS používají certifikáty o kratší délce klíče.
Tato změna souvisí se zvětšením výpočetního výkonu dnešních počítačů a snížení bezpečnosti certifikátů s kratší délkou klíče, které lze tak napadnout a rozluštit jimi chráněnou komunikaci mnohem dříve v rámci pro útočníka snesitelné doby.
Bez interních jmen
Druhá a zásadnější změna zvětšuje ochranu proti možným útokům Man in the Middle, kdy útočník vystupuje jménem interního zdroje (například server.firma.local) a zmátne klienta, který tam komunikuje s ním místo legitimního příjemce informace. Došlo tedy k rozhodnutí certifikáty obsahující takovéto interní jména přestat podporovat.
Tato změna má dopad především na firmy, které využívají prostředí Active Directory a například produkty jako Exchange Server, Lync Server nebo Small Business Server. Zároveň pak pro ochranu komunikace šifrováním a pro ověření identity využívají SSL certifikáty od veřejně důvěryhodné CA obsahující jak externí, tak především interní názvy serverů. Toto byl obvyklý scénář především u takzvaných SAN certifikátů.
Ovšem i na firmy, které využívají služeb interní certifikační autority (CA), může tato změna mít dopad na nutnost provést některé konfigurační změny prostředí či revizi způsobu používání SSL certifikátů.
Tato změna již také přišla v platnost a důvěryhodné veřejné CA upravily svoje procesy pro vydávání certifikátů. Pro stávající uživatele těchto certifikátů jsou ale zásadní následující milníky:
- Platnost aktuálně vydávaných certifikátů obsahující interní názvy nesmí překročit 1. listopadu 2015.
- Všechny veřejné CA 1. října 2016 odvolají všechny vydané a dosud platné certifikáty, které obsahují interní názvy.
Nepovolené názvy
Po zavedení této změny nebudou v certifikátech vydávaných veřejnými certifikačními autoritami povolovány následující interní názvy v polích CN (Common Name) a SAN (Subject Alternative Names):
- Názvy serverů (například EXCHSRV01)
- Názvy serverů s nevalidní doménou prvního řádu (například ADSRV2012.firma.local)
- Jakákoliv IPv4 adresa v rozsahu interních sítí definovaném v RFC 1918.
- Jakákoliv IPv6 adresa v rozsahu interních sítí definovaném v RFC 4193.
V praxi jsou tedy v podstatě nepovolené všechny názvy, které nejsou dostupné a přeložitelné z veřejných DNS. Domény nejvyššího řádu, které jsou vyhrazeny pro interní a testovací účely:
- .test
- .example
- .invalid
- .localhost
- .local
- .lan
- .priv
- .localdomain
Především doména .local pak bývá často využívána zvláště v prostředích AD pro identifikaci interní domény a následně i serverů v tomto jmenném prostoru a přístupů na servery ve tvaru http://server nebo http://server.firma.local/. Pokud byl tento přístup chráněn například na IIS pro HTTPS nebo RDS opatřen SSL certifikátem s tímto názvem, tento scénář nadále nebude podporován.
Což samozřejmě nebude po stránce technické, po RDP se stále na server připojíte, pouze certifikát se bude jevit jako neplatný a nový pro něj od veřejné CA již neobdržíte. Nutné je tedy začít používat veřejná URL, interní CA, nebo další v případě, pokud chcete mít komunikaci dále opatřenou ochranou pomocí SSL.
Domény prvního řádu
Aby byla situace ještě o trochu zajímavější, v roce 2011 organizace ICANN schválila program, kdy jakákoliv organizace, vláda či jednotlivec může požádat o přidělení domény prvního řádu (gTLD), například .firma a mít tak pod správou například doménu www.pocitacova.firma. Mimo obvyklé a standardizované domény prvního řádu jako národní .cz a generické .net tak mohou po patřičném schválení přibýt zcela nová jména.
Pokud takovouto doménu ovšem využíváte právě ve svém prostředí a máte pro její účely vydán patřičný SSL certifikát, certifikační autorita 120 dní po schválení této domény tyto certifikáty automaticky zneplatní a vám zároveň hrozí, že uživatelé budou směrování na zcela cizí zdroje pomocí běžných procesů DNS dotazů.
V současné době jsou v procesu schválení například následující domény prvního řádu:
- APPLE
- CISCO
- CITY
- CLOUD
- COMPANY
- COMPUTER
- CONSULTING
- CONTACT
- CORP
- DATA
- DELL
- DEV
- GOOGLE
- HELP
- HOME
- HOST
- HOSTING
- INC
- INTEL
- JUNIPER
- MAIL
- MICROSOFT
- NETWORK
- ONLINE
- SAP
- SITE
- STORAGE
- SUPPORT
- TECH
- VIP
- WEB
- WORK
Co si počít ve světě Microsoft technologií
Tato změna tedy přináší nutnost změn v prostředích, které využívají scénáře, které se nyní stanou nepodporovanými. Jako správce tohoto prostředí máte hned několik možností.
Obecným doporučením do budoucna je ale pečlivé plánování a návrh infrastruktury s ohledem na dané prostředí a jednotlivé služby. Pokud jste byli například pečlivými čtenáři TechNet Knihovny, pak jste se mohli u Windows Server 2003 dočíst, že varianta .local je jedna z možných a doporučovaných, pro verzi 2008 pak, že toto je sice podporovaný, ale nedoporučovaný scénář. U nejnovějších článků KB se tato doporučení právě pro jednotlivé scénáře zásadně liší.
Změna konfigurace služeb
Pro dotčené produkty jako například Exchange Server lze využít odděleného DNS prostoru pro interní a externí URL a pro jednotlivé služby jako například OWA a funkcí jako virtuálních adresářů. Máte tak možnost přejít na použití pouze externích URL i pro interní uživatele a používat tak FQDN názvy serverů posta.firma.cz místo postovni-server.local.
Přejmenování či migrace Active Directory
Tento krok má zásadní vliv na prostředí, a pokud to není bezpodmínečně nutné, není doporučován, ale je možný. Možná je také migrace do nové domény navržené v souladu s novými doporučeními. Například i postavěné již na nejnovějším Windows Server 2012 R2. V případě tohoto scénáře je doporučeno mít dokonale zmapováno prostředí, připraven postup přejmenování či migrace a záložní plán pro případ chyby či selhání.
Interní certifikační autorita
Vhodnou možností je použití kombinace privátní a veřejné certifikační autority, která sice přináší nutnost správné konfigurace přístupu pro interní a externí uživatele. Výhodná je především ve větších prostředích, kde je nutné zabezpečit komunikace systémů Exchange, Lync či System Center.
Outsourcing a cloudové služby
Například pro poštovní služby můžete také přejít k jednomu z poskytovatelů hostovaného e-mailového řešení nebo cloudovými službám Office 365, kdy se v podstatě zcela zbavíte starostí o problematice certifikátů.
Hlavně se v tom neztratit
Především v komplexních prostředích více systémů může být složité zvážit všechny možné scénáře a dopady těchto změn v problematice digitálních certifikátů. Vždy záleží na konkrétním prostředí a jeho konfiguraci. Předtím, než se rozhodnete pro některé z nabízených řešení, doporučujeme kontaktovat některého z partnerů společnosti Microsoft, který doporučí plán, který bude pro vaše prostředí nejvhodnější.
- Petr Vlk (WUG, KPCS CZ)
Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.