AUTENTIZACE WEBOVÝCH SLUŽEB PROSTŘEDNICTVÍM

AUTENTIZACE WEBOVÝCH SLUŽEB PROSTŘEDNICTVÍM VLASTNÍ CERTIFIKAČNÍ AUTORITY Bc. Radek Doležel Ústav telekomunikací Fakulta elektrotechniky a komunikačních technologií Vysoké učení technické v Brně Česká Purkyňova 118, 612 00 Brno, Česká republika Email: xdolez35@stud.feec.vutbr.cz Článek prakticky popisuje zprovoznění vlastní certifikační autority a následně její využití pro bezpečnou autentizaci webových služeb. V první části je vytvořena vlastní certifikační autorita, vygenerován serverový a klientský digitální certifikát i s klíčem a jejich následné podepsání certifikační autoritou. Druhá část uvádí nastavení webových služeb pro možnost využití právě vytvořené infrastruktury digitálních certifikátů a klíčů. Při popisu je v maximální možné míře využito možností Open Source Software. 1. ÚVOD Pro zvýšení bezpečnosti při využívání webových služeb je vhodné použít pro datová spojení protokol TLS/SSL (Transport Layer Security/Secure Sockets Layer), který je umístěn mezi transportní a aplikační vrstvu v síťovém modelu TCP/IP (Transmission Control Protocol/Internet Protocol) a webové služby jsou potom dostupné prostřednictvím aplikačního protokolu https (Hypertext Transfer Protocol over Secure Socket Layer). Aby datová komunikace mezi dvěma stranami byla považována za bezpečnou, tak nestačí jen šifrovat datová spojení, ale je nutná i autentizace komunikujících stran. Právě tuto autentizaci zajišťuje infrastruktura postavená z důvěryhodných a ověřených digitálních certifikátů a klíčů. Popisovaný model využívá jako základ operační systém Debian GNU/Linux [1], pro vytvoření vlastní certifikační autority počítačovou službu OpenSSL [2], pro webové služby webový server Apache [3] a aplikační server Apache Tomcat [4]. Při popisu bylo využíváno dokumentace a návodů umístěných na webových stránkách jednotlivých projektů, ale také manuálových stránek příslušných programů (openssl [5], apache2 [6]). 2. VYTVOŘENÍ INFRASTRUKTURY DIGITÁLNÍCH CERTIFIKÁTŮ A KLÍČŮ Nejsnadnější cesta k vytvoření vlastní certifikační autority (v tomto případě se jedná o počítačovou službu) je možnost použití některé z volně dostupných počítačových služeb např. OpenSSL. OpenSSL je počítačová služba provozovaná na operačním systému GNU/Linux z čehož také vyplývá jistá svoboda při použití. OpenSSL bývá často součástí základní instalace operačního systému GNU/Linux, ale pokud by nebyla, tak se nainstaluje i s větší podporou pro práci s digitálními certifikáty a klíči tímto příkazem: apt-get install openssl ssl-cert Nejprve je však potřeba nastavit konfigurační soubor (/etc/ssl/openssl.cnf) podle požadavků na generované digitální certifikáty a klíče (umístění potřebných souborů, doba platnosti apod.). Změny mohou být následující: [ CA default ] dir = /etc/ssl certs = $dir/certs crl dir = $dir/crl database = $dir/index.txt new certs dir = $dir/newcerts certificate = $dir/ca/ca.crt serial = $dir/serial crlnumber = $dir/crlnumber CRL crl = $dir/crl.pem private key = $dir/ca/ca.key default days = 190 29-1

Vzhledem k tomu, že se změnila struktura pro ukládání digitálních certifikátů a klíčů, tak je nutné vytvořit tomu odpovídající adresáře a soubory: mkdir /etc/ssl/ca mkdir /etc/ssl/certs mkdir /etc/ssl/crl mkdir /etc/ssl/newcerts mkdir /etc/ssl/private mkdir /etc/ssl/requests touch /etc/ssl/index.txt echo "01" > /etc/ssl/serial chmod 700 /etc/ssl/* Proces vytvoření vlastní certifikační autority spočívá ve vygenerování kořenového digitálního certifikátu a k němu příslušného klíče. Obě tyto položky vytvoří následující příkaz: openssl req -config /etc/ssl/openssl.cnf \ -new -x509 -days 200 -sha1 -newkey rsa:1024 \ -keyout /etc/ssl/ca/ca.key -out /etc/ssl/ca/ca.crt \ -subj '/O=Org-test/OU=Org-test/CN=Org-test Root CA' 1 Pro zpřehlednění příkazu jsou uvedeny i adresářové cesty k příslušným souborům. Kdyby zmíněné cesty nebyly do příkazu zadány, tak by se soubory vygenerovaly do adresářů, které jsou nastaveny v konfiguračním souboru OpenSSL. Nyní může být vygenerován serverový digitální certifikát a také klientský digitální certifikát a jejich klíče. Serverový digitální certifikát vygeneruje příkaz: openssl req -new -sha1 -newkey rsa:1024 -nodes \ -keyout /etc/ssl/private/server.key \ -out /etc/ssl/requests/server_request.pem \ -subj '/O=Org-test/OU=Org-test/CN=Org-test Server' Právě vygenerovaný digitální certifikát je potřeba podepsat pomocí certifikační autority: openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything \ -infiles /etc/ssl/requests/server_request.pem \ -out /etc/ssl/newcerts/server_signed.pem Je několik datových formátů digitálních certifikátů, proto je dobré převést digitální certifikát do datového formátu, se kterým bude následně pracováno: openssl x509 -in /etc/ssl/newcerts/server_signed.pem \ -out /etc/ssl/certs/server.crt Po těchto krocích je vygenerovaný digitální certifikát s klíčem pouze pro server. Aby mohl být celý proces bezpečné autentizace úspěšně dokončen, tak je potřeba vygenerovat také klientský digitální certifikát a klíč. Vygenerování klientského digitálního certifikátu a klíče se provede následovně: openssl req -new -sha1 -newkey rsa:1024 -nodes \ -keyout /etc/ssl/private/client.key \ -out /etc/ssl/requests/client_request.pem \ -subj '/O=Org-test/OU=Org-test/CN=Org-test Client' Opět je potřeba podepsat certifikační autoritou právě vygenerovaný digitální certifikát: openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything \ -infiles /etc/ssl/requests/client_request.pem \ -out /etc/ssl/newcerts/client_signed.pem I u klientského digitálního certifikátu je vhodné změnit jeho datový formát na požadovaný: 1 V tomto případě a ještě dále v textu se jedná o dlouhý příkaz rozdělený na více řádků. 29-2

openssl pkcs12 -export -clcerts -in /etc/ssl/newcerts/client_signed.pem \ -inkey /etc/ssl/private/client.key -out /etc/ssl/certs/client.p12 Vzhledem k tomu, že vygenerované digitální certifikáty jsou v různých datových formátech, tak pro opětovné zobrazení jejich informací slouží následující příkaz: openssl x509 -in /etc/ssl/certs/server.crt -text -noout V této chvíli je vytvořena infrastruktura digitálních certifikátů a klíčů skládající se z digitálního certifikátu a klíče certifikační autority, podepsaného certifikační autoritou serverového a klientského digitálního certifikátu a klíče. Proto je nyní možné přejít k nastavení jednotlivých počítačových služeb a programů pro práci s digitálními certifikáty a klíči. 3. NASTAVENÍ WEBOVÝCH SLUŽEB Mezi nejčastěji používané zástupce serverů (opět se jedná o počítačovou službu) pro poskytování webových služeb z oblasti Open Source Software patří webový server Apache a aplikační server Apache Tomcat. Následující text bude popisovat nastavení právě těchto dvou serverů. Při popisu bude předpokládáno, že zobrazovaný obsah webové služby bude shodný jak pro nezabezpečenou, tak i zabezpečenou variantu datového spojení. V opačném případě se pouze vytvoří adresář pro zabezpečený obsah, nastaví se oprávnění k přístupu pomocí uživatelských přístupových práv a také se změní odkaz na jeho umístění v konfiguračních souborech, který jinak odkazuje na původní obsah. 3.1. WEBOVÝ SERVER APACHE Webový server Apache se řadí k předním nejpoužívanějším webovým serverům a to především pro své velké množství nastavení, přídavných modulů (např. podpora pro TLS/SSL, virtuální hosty, skriptovací jazyky atd.), výbornou dokumentaci další možnosti. Webový server Apache se v základu nainstaluje pomocí příkazu: apt-get install apache2 Po nainstalování je nutné provést základní nastavení a také nastavení pro možnost použití TLS/SSL. V hlavním konfiguračním souboru (/etc/apache2/apache2.conf) je možné nastavit např. jméno serveru, informace o serveru v případě chyby, různá omezení apod. Potom je potřeba upravit konfigurační soubor (/etc/apache2/ports.conf) pro TCP (Transmission Control Protocol) porty, na kterých bude webový server Apache očekávat datová spojení. Připíše se tento řádek: Listen 443 Následujícím příkazem se zavede modul s podporou pro TLS/SSL: a2enmod ssl Nyní je vhodné vytvořit adresář, kam se uloží digitální certifikáty a klíče: mkdir -p /etc/apache2/certs Do právě vytvořeného adresáře se zkopíruje serverový digitální certifikát s příslušným klíčem a také digitální certifikát certifikační autority: cp /etc/ssl/certs/server.crt /etc/apache2/certs cp /etc/ssl/private/server.key /etc/apache2/certs cp /etc/ssl/ca/ca.crt /etc/apache2/certs Aby se nekombinovaly záznamové soubory, tak je vhodné vytvořit i adresář pro TLS/SSL záznamové soubory: mkdir -p /var/log/apache2/ssl Vzhledem k tomu, že budou současně v provozu jakoby dva webové servery (bez podpory TLS/SSL a s podporou TLS/SSL), tak je nutné vytvořit v konfiguračním souboru (/etc/apache2/sites-available/default) také tzv. dva 29-3

virtuální hosty. Nejjednodušší řešení je zkopírovat současné nastavení konfiguračního souboru do spodní části tohoto konfiguračního souboru obsahující pouze nastavení webového serveru bez podpory TLS/SSL a provést jen úpravu nově zkopírované části pro webový server s podporou TLS/SSL. Také je potřeba odlišit od sebe samostatné virtuální hosty a potom ještě zbývá sdělit webovému serveru Apache kam se mají ukládat záznamové soubory s podporou TLS/SSL a kde se nachází digitální certifikát a klíč serveru a digitální certifikát certifikační autority. Výsledné nastavení konfiguračního souboru může vypadat následovně: NameVirtualHost *:80 NameVirtualHost *:443 <VirtualHost *:80> původní nastavení webového serveru Apache bez podpory TLS/SSL </VirtualHost> <VirtualHost *:443> DocumentRoot /var/www/ # v případě odlišného obsahu změnit umístění ErrorLog /var/log/apache2/ssl/error.log CustomLog /var/log/apache2/ssl/access.log combined SSLEngine on SSLVerifyClient require SSLVerifyDepth 1 SSLCertificateFile /etc/apache2/certs/server.crt SSLCertificateKeyFile /etc/apache2/certs/server.key SSLCACertificateFile /etc/apache2/certs/ca.crt </VirtualHost> Nakonec je potřeba webový server Apache restartovat: /etc/init.d/apache2 restart Zadáme-li adresu webového serveru do adresního řádku webové prohlížeče klienta, tak se automaticky webový prohlížeč připojí k webovému serveru pomocí protokolu http (Hypertext Transfer Protocol). Pokusíme-li se připojit protokolem https, tak dojde k chybě, protože webový server vyžaduje od webového prohlížeče klienta podepsaný klientský digitální certifikát. Proto je potřeba předat klientovi jeho digitální certifikát (client_signed.pem) s klíčem (client.key) v bezpečném úložišti (čipová karta, šifrovací USB (Universal Serial Bus) token apod.) nebo přímo naimportovat digitální certifikát (client.p12) do bezpečného úložiště webového prohlížeče. Pro webový prohlížeč Mozilla Firefox verze 3 a jeho následné odnože, které mají podobné nastavení, je možné provést import digitálního certifikátu do jeho bezpečného úložiště tak, že se otevře okno Správce certifikátů kliknutím na položku Nástroje v hlavním menu a vybere se z nabídky položka Možnosti. V okně Možnosti přejít na kartu Rozšířené a vybrat záložku Šifrování, kde se klikne na tlačítko Certifikáty. V nově otevřeném okně Správce certifikátů ponechat aktivní záložku Osobní a kliknout na tlačítko Importovat Následně je potřeba vybrat umístění digitálního certifikátu client.p12 a nakonec klikat na tlačítko OK pro potvrzení voleb. Ostatní druhy webových prohlížečů mají podobné nastavení, kdy je vždy potřeba přes správce certifikátů importovat požadovaný digitální certifikát do bezpečného úložiště. Nyní po opětovném připojení klienta k webovému serveru pomocí protokolu https dojde k výměně a ověření digitálních certifikátů a pokud je vše v pořádku, tak i k navázání bezpečného datového spojení. 3.2. APLIKAČNÍ SERVER APACHE TOMCAT Aplikační server Apache Tomcat je implementací Java Servlet a JavaServer Pages (JSP) a slouží tedy jako webové prostředí pro programy napsané ve zdrojovém kódu programovacího jazyka Java. Proto většina dalších nastavení musí být v souvislosti s programovacím jazykem Java a jeho nástroji. Ještě před instalací aplikačního serveru Apache Tomcat je potřeba nainstalovat vývojové prostředí jazyka Java JDK (Java Development Kit). Pro bezproblémovou instalaci JDK bylo čerpáno z následujícího zdroje [7]. Nejdříve se upraví zdroje distribučních programových balíčků pro možnost stažení aktuální verze JDK s následujícím nastavením v konfiguračním souboru (/etc/apt/sources.list): ### unstable ####### deb http://ftp.debian.org/debian/ unstable main non-free 29-4

Nastavení velikosti vyrovnávací paměti se provede přidáním následujícího řádku do konfiguračního souboru (etc/apt/apt.conf.d/70debconf): APT::Cache-Limit "100000000"; Ještě je potřeba vytvořit konfigurační soubor (/etc/apt/preferences) k upřesnění priority stahování a instalace mezi stabilní a nestabilní verzí programových balíčků: Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=unstable Pin-Priority: 600 Nakonec stačí provést aktualizaci zdrojů distribučních programových balíčků a nainstalovat JDK: apt-get update apt-get install sun-java6-jdk Po instalaci JDK je možné nainstalovat aplikační server Apache Tomcat: apt-get install tomcat6 tomcat6-admin tomcat6-webapps Doporučuji po skončení instalace zakomentovat nebo smazat řádek s odkazem na unstable verze programových balíčků v konfiguračním souboru (/etc/apt/sources.list), protože následně by docházelo k aktualizacím operačního systému prostřednictvím nestabilních verzí programových balíčků. Druhy verzí distribučních programových balíčků z pohledu operačního systému Debian GNU/Linux popisuje následující zdroj [8]. Pokud je vše potřebné připraveno, tak se může importovat digitální certifikát certifikační autority jako důvěryhodný digitální certifikát: keytool -import -alias "Org-test Root CA" \ -trustcacerts -file /etc/ssl/ca/ca.crt \ -keystore /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/cacerts Vzhledem k tomu, že nástroj keytool [9], který slouží k práci s digitálními certifikáty a klíči v prostředí programovacího jazyka Java, neumožňuje přímé importování klíčů vygenerovaných pomocí OpenSSL, tak je potřeba toto omezení obejít exportováním digitálního certifikátu a klíče serveru v datovém formátu *.pem do datového formátu *.p12 [10]: openssl pkcs12 -export -clcerts -out /etc/ssl/certs/keystore.p12 \ -in /etc/ssl/newcerts/server_signed.pem \ -inkey /etc/ssl/private/server.key Následný import, který je popsán v tomto zdroji [11] včetně možnosti stažení potřebných nástrojů, se provede pomocí příkazu: java -cp jetty-6.1.7.jar org.mortbay.jetty.security.pkcs12import \ /etc/ssl/certs/keystore.p12 /etc/tomcat6/keystore.jks Ze změn na serverové části je potřeba ještě patřičně změnit konfigurační soubor aplikačního serveru Apache Tomcat (/etc/tomcat6/server.xml): <Connector port="8443" protocol="http/1.1" SSLEnabled="true" maxthreads="150" scheme="https" secure="true" keystorefile="/etc/tomcat6/keystore.jks" keystorepass="heslo" clientauth="true" sslprotocol="tls"/> Nakonec je potřeba restartovat aplikační server Apache Tomcat: /etc/init.d/tomcat6 restart 29-5

Pro úspěšné datové spojení je opět nutné, aby klient měl svůj klientský digitální certifikát s klíčem uložen ve svém bezpečném úložišti, což by mělo být nastaveno z předchozí části. K zajištění bezproblémové koexistence webového serveru Apache a aplikačního serveru Apache Tomcat bylo použito takové nastavení, že každý server očekává datové spojení na jiném transportním portu TCP (webový server Apache: http = 80, https = 443, aplikační server Apache Tomcat: http = 8080, https = 8443). 4. ZÁVĚR V jednotlivých částech je popsán postup pro instalaci a nastavení počítačových služeb a serverů jako je počítačová služba OpenSSL, webový server Apache a aplikační server Apache Tomcat pro vytvoření modelu bezpečné autentizace webových služeb pomocí digitálních certifikátů a klíčů s využitím protokolu TLS/SSL k zabezpečení datového spojení. Jako základ celého modelu byl použit operační systém Debian GNU/Linux a celý tento model byl tedy zprovozněn pomocí programů z oblasti Open Source Software. Název organizace a případná další jména použitá při generování digitálních certifikátů a klíčů jsou smyšlená a slouží především k názorným účelům taktéž jako použití slabých hesel. Nejprve byla vytvořena vlastní certifikační autorita nastavením konfiguračního souboru OpenSSL a strukturou potřebných adresářů a souborů, která následně sloužila ke generování a podepisování serverového a klientského digitálního certifikátu s klíči. Základní instalace jak webového serveru Apache tak i aplikačního serveru Apache Tomcat je přednastavena pro datové spojení pomocí nezabezpečeného protokolu, které bylo ponecháno beze změny. Ke stávajícímu nezabezpečenému spojení bylo přidáno nastavení pro zabezpečené datové spojení pomocí protokolu TLS/SSL a jednotlivá příchozí datová spojení serverů (Apache a Apache Tomcat) jsou odlišena podle transportních portů TCP. Nastavení serverů se liší a to především v tom, že aplikační server Apache Tomcat neumožňuje přímý import serverového digitálního certifikátu společně s klíčem vygenerovaným pomocí počítačové služby OpenSSL do svého bezpečného úložiště. Proto byl tento nedostatek vyřešen převedením podepsaného serverového digitálního certifikátu a klíče do jiného datového formátu a následně pomocí dodatečného nástroje importován do bezpečného úložiště. Digitální certifikát certifikační autority byl importován do bezpečného úložiště pro důvěryhodné digitální certifikáty. Všechny bezpečná úložiště aplikačního serveru Apache Tomcat jsou chráněna přístupovým heslem. Webový server Apache nemá uloženy digitální certifikáty a klíče v bezpečném úložišti, které by bylo chráněné heslem, proto je potřeba upravit přístup pomocí uživatelských přístupových práv. Stejný postup je potřeba zvolit k zamezení přístupu k digitálním certifikátům a klíčům v adresáři počítačové služby OpenSSL. Klientský digitální certifikát byl importován do bezpečného úložiště, opět chráněného heslem, webového prohlížeče na klientském počítači. Potom pokud se chce klient ze svého počítače připojit k serveru, na kterém jsou zabezpečené autentizací webové služby, tak se musí prokázat platným a podepsaným klientským digitálním certifikátem, který má uložen v bezpečném úložišti webového prohlížeče vyžadující přístupové heslo pro přístup k digitálnímu certifikátu a klíči. LITERATURA [1] Debian Univerzální operační systém [online]. 1997 2009, poslední aktualizace 11.4.2009 [cit. 2009-04-11]. Dostupné z WWW: <http://www.debian.org>. [2] Engelschall, R., S. OpenSSL The Open Source toolkit for SSL/TLS [online]. 1999 2005, [cit. 2009-04-11]. Dostupné z WWW: <http://www.openssl.org>. [3] The Apache HTTP Server Project [online]. 2009, [cit. 2009-04-11]. Dostupné z WWW: <http://httpd.apache.org>. [4] Apache Tomcat Apache Tomcat [online]. 1999 2009, [cit. 2009-04-11]. Dostupné z WWW: <http://tomcat.apache.org>. [5] openssl(1ssl) manuálová stránka pro GNU/Linux, verze 0.9.8c, poslední aktualizace 4.1.2004 [cit. 2009-04-11]. [6] apache2(8) manuálová stránka pro GNU/Linux, poslední aktualizace 2/1997 [cit. 2009-04-11]. [7] Installing Labs 3 Stable on Debian Etch AlfrescoWiki [online]., poslední aktualizace 17.2.2009 [cit. 2009-04-11]. Dostupné z WWW: <http://wiki.alfresco.com/wiki/installing_labs_3_stable_on_debian_etch>. [8] Debian Verze Debianu [online]. 1997 2009, poslední aktualizace 18.2.2009 [cit 2009-04-11]. Dostupné z WWW <http://www.debian.org/releases/> [9] keytool-key and Certificate Management Tool, [online]. [2001], [cit. 2009-04-11]. Dostupné z WWW <http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html>. 29-6

[10] public:development:tools:add private key to jks Enterprise Lab Documentation, [online]., poslední aktualizace 27.2.2009 [cit. 2009-04-11]. Dostupné z WWW <https://www.enterpriselab.ch/wiki/doku.php?id=public:development:tools:add_private_key_to_jks>. [11] Singh, R. Linux Ramblings And Musings Converting PEM certificates and private keys to JKS, [online]., poslední aktualizace 3.12.2008 [cit. 2009-04-11]. Dostupné z WWW: <http://roopindersingh.com/tag/linux/> 29-7