Windows Server 2008 R2 PKI: vystavujeme certifikáty se SAN a EV

Miroslav Knotek – knotek@kpcs.cz – Microsoft MVP: Security, IT Senior konzultant KPCS CZ, s.r.o.

Úvod

Certifikační autorita a pomocí ní vydané digitální certifikáty se v posledních letech staly v podstatě samozřejmou součástí každé IT infrastruktury. I tato oblast ale podléhá svému vývoji, a tak s nástupem mnoha nových technologií můžeme být jako správci certifikačních autorit žádáni o vystavení různých “speciálních” certifikátů, jako je např. certifikát s rozšířením SAN (Subject Alternative Name) nebo EV (Extended Validation). Jak si prakticky poradit s těmito požadavky na platformě Windows Server 2008 R2 se dozvíte v následujících odstavcích.

Certifikát se SAN – teorie

Každý digitální certifikát je vždy vystaven na jedno konkrétní jméno, které je uvedeno v subjektu certifikátu. Ono prokázání vazby mezi jménem subjektu a jeho veřejným klíčem je nakonec přece primárním důvodem pro existenci certifikátů. V praxi to ale může být mnohdy omezující. Co když potřebuji provozovat například webový server s přístupem HTTPS dostupný pod různými jmény?

Řešením je využití rozšiřujícího atributu certifikátu s názvem Subject Alternative Name (SAN). SAN umožňuje kromě jména uvedeného v předmětu do certifikátu zapsat v podstatě libovolné množství dalších alternativních jmen.

Pokud je v certifikátu SAN použit, je dokonce možné ponechat atribut subjekt zcela prázdný. Ale vždy je třeba dát pozor, zda je SAN rozšíření opravdu podporováno ve všech aplikacích, které ho ověřují. Například pro IMAP4S a POP3S přístup k poštovní schránce je SAN certifikát podporován až v MS Outlook 2010 resp. MS Outlook 2007 + KB 968858. Proto je přece jen běžnou praxí primární jméno uvádět vždy v subjektu certifikátu a ostatní v SAN.

V zásadě se nejedná o žádnou horkou novinku, neboť SAN je součástí standardu X509 v3 již z roku 1999. Nicméně na platformě Microsoft se s tímto typem certifikátu setkáváme častěji od doby, kdy jej začal využívat MS Exchange Server 2007 a OCS 2007.

Certifikát se SAN – praxe

Přestože certifikáty se SAN se dají vystavovat i z certifikačních autorit ve starších verzích MS Windows, zaměříme se na postup platný pro CA Windows 2008 R2.

Vystavit certifikát se SAN je možné 3 způsoby:

Z webového rozhraní CA
Pomocí MMC konzole Certifikáty (Windows Server 2008 R2, Windows Server 2008, Windows 7 a Windows Vista)
Nebo z příkazové řádky pomocí certreq.exe

První metodu již na nových systémech pokud možno nepoužívejte, neboť využívá zastaralou metodu zadání SAN pomocí RequestAttributes, což je dokonce ve výchozím stavu na certifikační autoritě zakázáno.

Na Internetu naleznete stovky článků, které radí pomocí příkazu certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 tuto možnost povolit. Ale již se málokde píše o tom, že je to naprosto nevhodné pro Enterpise CA, neboť tím povolujete, aby kterýkoliv subjekt, který má práva na některou z šablon, si do certifikátu bez jakéhokoliv dalšího ověření přidával libovolná alternativní jména. Tím je funkce CA samozřejmě naprosto znehodnocena a nesplňuje tak svoji primární funkci – garantovat, že daný veřejný klíč patří k uvedenému jménu subjektu.

Zbylé dvě metody již používají pro zadání SAN jména Extensions namísto RequestAttributes, což zvyšuje bezpečnost práce se SAN certifikáty. Pokud šablona certifikátů definuje, že jméno subjektu se načítá z Active Directory, všechna další jména uvedená v žádosti v Extensions jsou ignorována a nestanou se součástí certifikátu.

Obrázek 1: Žádost o SAN pomocí Extensions nebo RequestAttributes

Nevhodným nakládáním se SAN tak může být kompromitována bezpečnost celého systému, proto je doporučeno dodržovat následující zásady:

Omezit práva na vystavování certifikátů se SAN pomocí šablon certifikátů jen pro konkrétní skupiny – např. správce webových serverů
Vystavení certifikátu se SAN jmény by mělo vždy podléhat schválení certifikačním manažerem
Na Enterprise CA nikdy nezapínat EDITF_ATTRIBUTESUBJECTALTNAME2. Pokud je to zapnuto, tak je možné vystavit jakýkoliv certifikát s jakýmkoliv jménem bez dalšího schvalování.
Pokud je potřeba zapnout EDITF_ATTRIBUTESUBJECTALTNAME, a tím pádem používat RequestAttributes místo Extensions, je doporučeno nasadit samostatnou Standalone CA.

Dále se zaměříme na praktický postup vygenerování certifikátu pro webový server se SAN z Enterprise CA pomocí MMC konzole.

Spustíme si MMC konzolu Certifikáty pro počítač. Personal -> Certificates -> All tasks -> Request new certificate
Zvolíme šablonu, která má nastaveno Subject – Supplied in the request. V našem případě použijeme výchozí šablonu Web server.
V Certificate Properties vyplníme primární jméno do položky Subject name a v sekci Alternative name zadáme všechna další požadovaná SAN jména.

Obrázek 2: Žádost o certifikát se SAN
Po potvrzení žádosti již jen stačí ověřit, že alternativní jména jsou v certifikátu opravdu uvedena.

Obrázek 3: Certifikát se SAN

Certifikát EV – teorie

Konkurenční boj v oblasti komerčních CA bohužel dospěl k tomu, že řada z nich vydává certifikáty bez důkladné kontroly žadatele a ověřením bývá často jen doručení mailu nebo dokonce jen platba. To vedlo k potřebě vytvořit jakýsi „vyšší“ standard důvěryhodných certifikátů. Proto v roce 2007 fórum CA/Browser vydalo závazné pokyny pro způsob ověřování žadatele, kterými se musí každá komerční CA řídit, pokud vystavuje EV (Extended Validation) certifikáty.

Protože součástí fóra byli i tvůrci Internetových prohlížečů, drtivá většina z nich zcela jasně uživateli graficky znázorňuje, zda je připojen ke stránce chráněné pomocí EV certifikátu.

Obrázek 4: Grafické znázornění zelenou barvou v IE 8 pro stránku s EV certifikátem

Podpora EV je garantována v těchto prohlížečích:

IE 7+
Opera 9.5+
Safari 3.2+
Firefox 3+
Google Chrome

Certifikát EV – praxe

Novinkou Windows 2008 R2 PKI je možnost vydat si pro interní potřeby certifikát s EV příznakem, a tak ušetřit nemalé prostředky za nákup tohoto certifikátu od komerční certifikační autority. Kompletní postup pro nasazení:

Vytvoříme novou šablonu na základě existující šablony Web Server s názvem například EV Web Server
V této šabloně na záložce Extensions v sekci Issuance Policies přidáme novou politiku například “KPCS EV Policy“, která by měla odkazovat na URL, kde jsou popsána interní pravidla pro ověření žádosti a vystavení tohoto certifikátu uvnitř firmy. Tato politika musí mít kromě svého názvu také definovaný jednoznačný číselný identifikátor tzv. OID. Můžeme použít OID, který za nás automaticky vygeneruje průvodce. Tento OID si ale musíme poznamenat, neboť ho budeme potřebovat v dalším kroku.

Obrázek 5: EV Issuance policy ve vlastnostech EV Web Server šablony
Spustíme si Group Policy Management ve verzi pro Windows 2008 R2 nebo Windows 7.
Vytvoříme nový Group Policy objekt na úrovni domény (případně využijeme již některý existující) a v sekci Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities provedeme import certifikátu naší kořenové CA.
Ve vlastnostech naimportovaného certifikátu na záložce Extended Validation přidáme OID, který jsme získali v bodě 2.

Obrázek 6: Konfigurace GPO pro EV certifikáty
Nyní již stačí pouze vystavit certifikát na základě šablony EV Web Server z této CA, přiřadit ho k webovému serveru a po aplikování politiky již bude při přístupu z IE panel adresa správně zeleně označovat zabezpečený přístup s EV certifikátem.

Závěr

V tomto článku jsme si vysvětlili, co se přesně skrývá za zkratkami EV a SAN v oblasti PKI a prakticky ověřili, že certifikační úřad na platformě Windows 2008 R2 dokáže velmi jednoduše a bezpečně požadavek na vystavení takovéhoto certifikátu splnit.