Máme za sebou hromadu teorie o certifikátech. Pak jsme si prošli praktickou cestu k vytvoření SSL certifikátu, který bychom měli mít uložený někde na disku. Teď je čas ten certifikát použít u Exchange serveru. Budu to ukazovat na jiném certifikátu, než který jsem minule generoval. Jediný důvod je ten, že jsem měl certifikát hotový dřív, než jsem se rozhodl, že o tom napíšu. Takže jsem nemohl znovu vygenerovat certifikát se stejným jménem. A nechci tam dávat certifikát se jménem, které nepoužívám. Vzhledem k tomu, že máte certifikáty vytvořené na vaše jména, tak to je jedno.

Dneska už budeme pracovat na našem Exchange serveru. Budeme potřebovat Exchange Management Consoli, Exchange Management Shell a IIS manager. Na začátek ještě jedno připomenutí teorie. SSL certifikát musí obsahovat jméno, které použijete v adrese k připojení. V mém případě to bude mail.tnx.cz. Nemusí tam být FQDN serveru, pokud ho nebudete používát pro připojení. To je důležité. Máte doménu firma.local a jméno serveru je srv01, takže FQDN je srv01.firma.local. To jméno vůbec v certifikátu být nemusí, pokud máte v DNS jméno mailserver.company.com, které se použije pro připojení. Konec teorie, přihlašte se na server a otevřete IIS manager. Klikneme na jméno našeho serveru a v pravo vidíme Server Certificates.



Otevřeme. Můžete tam vidět všechny certifikáty, které na serveru máte. Pokud je to nový Exchange server, tak tam bude minimálně jeden self-signed certifikát, který si vytvořil instalátor. Klikneme v pravo v Actions na Import.



Otevře se nové okno pro zvolení certifikátu.



Musíme najít náš certifikát, který jsme si vygenerovali. Hlavně nezapomeňte přepnout přípony, ať zobrazí všechny. Ten průvodce čeká příponu *.pfx a my máme *.p12. Ale na funkci rostlináře to nebude mít vliv.



Otevřít. Napsat heslo a rozhodnout se, jestli certifikát bude exportovatelný. Nebudu rozepisovat plus a mínusy, resp. rizika. Pokud tohle zkoušíte na nějakém testovacím serveru, tak nechejte klíč exportovatelný. Pokud konfigurujete Exchange pro velkou firmu, kde udržujete aktuální dokumentaci, máte nastaveny procesy, tak určitě neexportovatelný a postarejte se, ať ten soubor s certifikátem je uložený na bezpečném místě (paměťové médium v trezoru) a v dokumentaci máte napsáno kde to je a jaké je heslo k tomu certifikátu.



OK. Tím by se měl naimportovat nový certifikát do IIS. A měli byste ho vidět v seznamu.

Nejsem si už jistý, jestli bylo potřeba restartovat IIS. Ale protože tím nic nezkazíme, tak to uděláme.

Thumbprint potřebujeme k identifikaci. Musíme certifikátu přiřadit služby, které chceme používat. Možnosti jsou: POP,IMAP,SMTP,IIS. První dvě jsou asi k ničemu. Třetí je jasná. U čtvrté záleží, jestli váš Exchange komunikuje ven. Pokud ano, tak se to hodí. Pokud máte smart host jako já, tak je to k ničemu. Teda ještě je tu možnost, že máte víc HUB transport serverů v organizaci. Pak potřebujete certifikát, ale otázka je, jestli si v tom případě nenecháte ten self-signed, který výtvořil instalátor. Ale tím to teď nebudu komplikovat. Nastavím si tam, že chci jen IIS. (Já tam píšu HROMADAZNAKU, protože tam nechci dávat můj skutečný Thumprint. Samozřejmě tam musíte dát to, co má váš certifikát.)

Teď můžeme smazat ostatní certifikáty s výjimkou toho, které si necháme pro SMTP komunikaci mezi HUBy. Následující příkaz vybere certifikáty, které nemají Thumbprint jako ten náš nový a odstraní je.

A to by bylo, ne? Můžete vyzkoušet OWA. Měli byste mít důvěryhodný certifikát. Ovšem, jestli si myslíte, že máme hotovo, tak vás musím zklamat. To nejhorší teprve přichází. Budeme se prát s nastavením autodiscoveru, takže s nastavením virtuálních adresářů. A pak nás čeká boj s DNS.

OK, během teorie jsem psal, jak funguje autodiscover. Začneme s nastavením z venku. To je primitivní. Vytvořím A záznam pro mail.tnx.cz, který bude směřovat na veřejnou IP adresu mého firewallu, kde mám pravidlo pro forwarding na Exchange server. A stejný záznam vytvořím pro tnx.cz (doménové jméno). A smažu záznam pro autodiscover.tnx.cz. Ten už nechci. K vnitřnímu DNS se vrátíme na konci. Teď jdeme nastavovat Exchange a budeme potřebovat shell.

Nejdřím upravíme SCP. To se dělá nastavení CASu. Chci nastavit adresu autodiscoveru na https://mail.tnx.cz/Autodiscover/Autodiscover.xml

Teď budeme postupně nastavovat virtuální adresáře pro Outlook anywhere, OWA, ECP, Active Sync, OAB, EWS. Všude potřebujeme mít uvedený server mail.tnx.cz, aby to fungovalo. Trochu si to zjednoduším v shellu. Abych nemusel vypisovat identity, tak udělám get a na to pustím set. Myslím, že to bude pochopitelné z konkrétních příkladů. Jen ještě upozorním, že pokud máte víc Exchange serverů, tak tímhle se to nastaví stejně na všech. To se hodí třeba pro případ použití load balanceru.

Nemělo by to být potřeba, ale jistota je jistota. Restartneme IIS.

Předpokládejme, že mám ve vnitřním DNS taky A záznam na mail.tnx.cz, který směřuje na IP adresu Exchange serveru. Když si projdu možnosti. Vezměme PC, které je na internetu. Pokud se připojí přímo k službě jako je OWA a použije mail.tnx.cz, tak bude certifikát OK. Pokud to bude Outlook a kontaktuje autodiscover, tak to bude na adrese domény. DNS záznam máme a doménové jméno je v certifikátu taky, takže opět OK. Pokud bude počítač v doméně, tak opět přímo služby na mail.tnx.cz budou mít správný certifikát. Pokud bude potřeba autodiscover, tak od SCP dostane zase jméno mail.tnx.cz a všechny služby jsou konfigurovány na tohle jméno, takže to bude v pořádku. Ale co když mám ve vnitřní síti stroj, který není členem domény, ale potřebuje použít autodiscover? Ten podle logiky použije doménové jméno. Bude to fungovat? Nebude. Ony totiž doménové řadiče, které fungují jako DNS servery registrují A záznam domény do DNS s vlastní IP adresou. My můžeme samozřejmě tyto záznamy smazat a vytvořit nový s IP adresou Exchange serveru. Jenže pokud máte zapnuté dynamick update v DNS a nejspíš máte, tak se vám tam objeví znovu. Jediným řešením je vypnout na síťové kartě doménových řadičů dynamické aktualizace DNS. Pozor, ja nevypínám službu jako takovou. Dynamické aktualizace (nebo registrace, či jak to nazvete) budou dál fungovat. Ale doménový řadič si své jméno dynamicky registrovat nebude. Bežte do nastavení TCP-IP doménového řadiče.



Klikneme na Advanced a na záložku DNS.



Zrušíme zaškrtnutí u políčka Register this connection's addresses in DNS. Teď můžeme jít do DNS a smazat A záznamy domény, které ukazují na doménové kontrolery. Vytvoříme tam záznam, který směřuje na Exchange. Otevřeme na doméňáku DNS konzoli, otevřeme si forward lookup zones, najdeme naši doménu. Klikneme pravým do volného místa, zobrazí se menu.



Klikneme na New Host (A or AAA). Je to záznam pro doménu, takže vyplníme jen IP adresu Exchange serveru a klikneme na OK.



Teď bychom měli vidět záznam v seznamu.



Pokud tam máte další A záznamy pro doménu, které odkazují na jiné IP adresy, tak je pomažte. Pokud to rovnou někde testujete, tak nezapomeňte promazat DNS cache. ipconfig /flushdns

A pokud jsem na nic nezapomněl, tak máme hotovo. Můžeme otestovat v shellu. K tomu nám poslouží příkaz: test-outlookwebservices. Tak ho pustíme.




Pokud nikde nenajdete Warning nebo Error, tak máte všechno v pořádku a můžete slavit. Případně testovat, jak vám všechno funguje v praxi. Pokud je někde chyba, tak nezbývá, než číst, co píše a hledat, kde je chyba.

A to je všechno. Pokud jste úspěšně došli až sem, tak gratuluji.