V dobách Windows 2003 jsem často zprovozňoval interní certifikační autoritu na back-end serveru a CA Web Enrollment a web s CRL na front-end serveru. U Windows 2008 mi identický postup nefungoval, tak jsem to vždy obešel automatickým zprovozněním aplikace /CertSrv po instalaci v Default Web Site. Dnes jsem však potřeboval tuto aplikaci rozchodit na jiném webovém serveru, protože Default Web Site již byl používaný Exchange Serverem 2010. Je to k neuvěření, ale dnes jsem našel jeden blog post z roku 2009, který vše potřebné naprosto geniálně popisuje. Už jen lahůdkou je fakt, že front-end běžící na Windows Serveru 2008 může bez problémů komunikovat s certifikační autoritou spuštěnou na Windows Serveru 2003.
Zmíněným článkem je How to configure the Windows Server 2008 CA Web Enrollment Proxy. První část, tj. instalaci příslušné Role Service, zvládne každý bez problémů. Co však zvládnout bez problémů nejde, je správné nastavení počítače s webem, IIS, AD v závislosti na použité identitě aplikačního poolu a požadovaném typu delegace. Článek automaticky počítá s instalací v rámci Default Web Site, nicméně já raději dávám přednost dedikovaným web site, už kvůli vlastnímu certifikátu a z toho vyplývající dedikované IP adrese.
Nejdříve ale pár poznámek k druhé části. Aplikační pool, v němž bude spouštěn web s /CertSrv aplikací, může běžet buď pod Network Service nebo pod doménovým uživatelským účtem. Snadnější je konfigurace s Network Service, ale třeba u web farem je potřeba použít doménový účet.
Každá z těchto dvou identit pak může být kombinována se dvěma, resp. třemi typy delegace – Open Delegation, Constrained Delegation a Constrained delegation with Protocol Transition.
- Network Service, Open delegation – nejjednodušší, nicméně se nedá omezit, ke kterým back-end službám na libovolném serveru bude mít server s webem přístup pomocí Kerberos autentizace
- Network Service, Constrained delegation – pořád snadné ke konfiguraci, serveru s webem povoluji delegaci pomocí Kerberosu pouze ke službám HOST a rpcss ze serveru s certifikační autoritou
- Doménový účet, Open delegation – doménový účet musí být členem AD skupiny Windows Authorization Access Group a členem lokální skupiny IIS_IUSRS na serveru s webem. Nastavení identity AppPoolu je už docela rutina. Záludností je u Windows autentizace zaškrnutí volby Enable Kernel-mode authentication. Delegace v AD je totožná s první zde popisovanou možností.
- Doménový účet, Constrained delegation – požadavky na členství doménového účtu jsou totožné s předchozí možností. Delegace v AD se již nespoléhá jen na Kerberos, ale na jakýkoliv autentizační protokol, server s webem tím získává přístup ke službám HOST a rpcss na serveru s CA. V dalším kroku se již čaruje s nastavováním SPN pro doménový účet. Následně se v AD nastavuje delegace doménového účtu pro služby HOST a rpcss ze serveru s CA a dále pro službu HOST ze serveru s webem. V konfiguraci IIS musí u Windows autentizace zůstat volba Enable Kernel-mode authentication odškrtlá.
- Doménový účet, Contrained delegation with Protocol Transition – tato možnost je poslední, nejsložitější a jako jediná umožňuje přistoupit k /CertSrv pomocí Basic autentizace, tj. například z Internetu. Všechny předešlé možnosti fungují pouze tehdy, pokud klient přistupující k /CertSrv má možnost se autentizovat pomocí Kerberosu nebo NTLM. Nastavení této poslední možnosti zahrnuje všechny kroky předchozího bodu. Následně se na aplikaci /CertSrv povolí Basic Authentication. Posledním požadavkem je úprava %systemroot%\system32\inetsrv\config\applicationHost.config, v němž je potřeba najít příslušnou Location a zde v basicAuthentication elementu je nutné přepsat logonMethod=”Network” na logonMethod=”ClearText”.
Jak už jsem se zmínil na začátku, front-end pro CA rozkládám do dvou webu. První, většinou pojmenovaný crl.firma.cz, slouží k publikaci CRL, případně zde připravuji stránku s odkazy na stažení root CA v DER I PEM formátu. Tento web je přístupný jak z intranetu, tak z Internetu a může sdílet již používanou IP adresu s definicí HTTP/1.1 hlavičky. Podstatné je, že tento web má nadefinovaný virtuální adresář CertEnroll, který může být umístěn klidně ve standardním umístění. Na něm je vytvořena sdílená složka, do níž má právo zápisu (jak na sdílené složce, tak na ACL) účet počítače, na němž běží CA. Jen tak budou korektně kopírovány a aktualizovány CRL a CRL+.
Další web je přístupný většinou pouze z intranetu a zpravidla se jmenuje ca.firma.local apod. V tomto webu vytvářím virtuální adresář /CertSrv. Web zpravidla běží na dedikované IP adrese, kterou si vyžaduje certifikát a povinnost SSL šifrování. Zpravidla u tohoto webu volím Windows i Basic autentizaci, tj. výše uvedený model “Doménový účet, Constrained delegation with Protocol Transition”.
Špekem u dedikovaného ca.firma.local webu je nutnost doplnění direktivy
<asp enableParentPaths="true" />
do souboru %systemroot%\system32\inetsrv\config\applicationHost.config v rámci <location path="ca.firma.local/CertSrv"> uvnitř sekce <system.webServer>
Nyní již jen stačí upravit v konfiguraci CA rozšíření CDP a AIA, aby obsahovalo správné publikační UNC a URL, restartnout CA, zkusit si vypublikovat CRL a hotovo. Jelikož je úprava CDP a AIA přes GUI docela pruda, tak v poslední době používám způsob, kdy zastavím službu CA, pustím regedit, upravím dva klíče a nastartuji CA.
Těmito klíči jsou:
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\nazev CA\CACertPublicationURLs
a
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\nazev CA\CRLPublicationURLs