Začlenění do zákazníkovy infrastruktury

Tato kapitola popisuje vzájemný vztah našich větších (ne-outsourcovaných) zákazníků a nás - dodavatelů IS/STAG. Neberte prosím níže sepsané věci jako neměnná dogmata, vždy lze napsat a zeptat se, domluvit se na změně a podobně. Tento dokument je zde sepsán takto velmi detailně především kvůli některým výjimečným případům, které vyžadují precizní soupis stavu věcí.

Zde sepsané věci jsou v kapitole "webové aplikace" a proto pro jistotu upozorňujeme, že vše zde popsané se týká provozu webových/portálových aplikací a nikoliv databáze Oracle či aplikačního serveru WebLogic!

Vzájemný vztah a domluva na provozu aplikace, souhrn stavu

Během let provozu jsme se postupně dohodli a ustálili na následujícím modelu, který (dle naší zkušenosti) všichni vzájemně dodržujeme.

• Provoz ve virtualizačním prostředí daného zákazníka - zákazník garantuje provoz virtuálního serveru, umí dělat případně snapshoty a podobně, zálohuje data svojí technologií.
• Zhruba řečeno platí, že dodavatel IS/STAG má pod kontrolou a správou celou platformu - tj. již od úrovně operačního systému výše. Dodavatel má pod kontrolou verze a stav všech komponent, na kterých naše webové aplikace závisejí.
• Dodavatel bude udržovat klíčové komponenty aktuální (tj. bude zodpovídat mimo jiné za nasazování bezpečnostních záplat)
• Nicméně zákazník musí dodat server tak, aby byl dodavatel tohoto schopen (tj. nainstalovaný Debian musí být schopen aktualizace, firewall musí být dle dohodnutých pravidel atd.)
• Při instalaci je třeba se individuálně domluvit na způsobu začlenění do infrastruktury zákazníka (vždy je někde nějaká specialita) - viz kapitoly níže
• Aktualizace a nasazování nových verzí našich aplikací může zajišťovat dodavatel IS/STAG a nebo si je mohou administrátoři zákazníka nasazovat sami (prostřednictvím našeho nástroje na webu IS/STAG) - popsáno na samostatné stránce.
• Vedle provozního serveru lze provozovat i testovací variantu, na které je možno si nové verze nejprve otestovat. Zároveň lehká specifika znamená i varianta pro servery začleněné do státní sítě CMS.

Technické podrobnosti týkající se správy a provozu

Detailní rozpis kompetencí mezi dodavatelem IS/STAG a zákazníkem, v jehož infrastruktuře se server provozuje.

Obecně platí, že máme tři (čtyři) druhy serverů podle toho, co na nich běží. Proto níže uvádíme některé parametry podle toho, kde je lze očekávat:

• portál - provozní portál - portálová aplikace, většina aplikací,
• ws - provozní modul webových služeb (WS) - pouze aplikace WS + komunikace s některými externími systémy,
• demo - DEMO instalace - typicky obsahuje i portál i modul WS dohromady, obojí ale jen testovací (bez zátěže, bez takových nároků na místa na disku),
• cms - provozní modul webových služeb nakonfigurovaný jako rozhraní pro propojení IS/STAG se státními registry (velmi omezená konfigurace); konfigurace stejná jako ws.

Poznámka: Pouze VFU má provozní portál i provozní WS na stejném serveru, jinde je to vždy oddělené

Co zajišťuje dodavatel IS/STAG

• Operační systém
  • Poté, co nám předáte čistý nainstalovaný Debian Linux 11 (viz dále) se o operační systém staráme my
  • V Debianu jsou zapnuté bezpečnostní aktualizace, které se automaticky pravidelně aplikují (ale podmínkou je, že server má dostupné a Vámi nakonfigurované zdroje pro Debian aktualizace - viz. kapitola "co zajišťuje zákazník" níže)
    
    • Každou noc mezi 23-1h se provede upgrade balíčků z /Debian-Security/. Rebooty se neprovádí.
    • Výjimky u několika balíčků (viz níže): tomcat9, openjdk-XX-jdk (tj. upgradují se jednotlivé meziverze, ale pouze v rámci hlavní verze Javy)
    • (poznámka - nastavení lze vidět: apt-mark show-hold )
  • Upgrade samotného Debianu na další stabilní verze provádíme řízeně, organizovaně pro všechny zákazníky v jednu dobu (naposled během května - července 2022), cca 1x za 3 roky, dle dostupnosti a nutnosti
• Konfigurace OS a námi vyžadovaných aplikací
  • Veškerá konfigurace je automatizovaně prováděna nástrojem puppet, který se v spouští každých 20 minut. Propagace nových změn v produkčním prostředí je prováděna jednou denně. Na vývojových strojích se propagace provádí každých 20 minut. Veškeré ručně provedené změny v mnoho konfiguračních souborech budou puppetem nejpozději za 20 minut navráceny do původního stavu, proto nikdy nic takového nedělejte! Případně nás kontaktujte.
  • Významné aplikace/balíčky, které používáme:
    • Java (OpenJDK 17.x / od léta 2024 Adoptium Java 21.x)
      
    • Tomcat - Aktualizace webového kontejneru Tomcat se nedějí automaticky, jeho vývoj i bezpečnostní rizika sledujeme a aktualizace děláme po našem uvážení. Máme s automatickou aktualizací špatné zkušenosti a potřebujeme držet verzi, kterou máme otestovanou (je až příliš pevně vázán na naše aplikace.
    • TeXLive
    • AppArmor (pro zabezpečení spouštení Texu)
    • Icinga - pro monitoring
    • Puppet - pro správu systému
    • Postfix - na portálovém serveru samotném provozujeme lokální postfix, přes který maily naše webové aplikace odesílají. Postfix je nakonfigurován na přeposlání na Vámi definovanou SMTP relay
• Monitoring (částečně)
  
  • My sami monitorujeme dostupnost serveru (ping), HTTPS + certifikát, místo na disku jen omezeně (jen ve vybraných adresářích, nemáme totiž představu jak přesně máte kdo namapované diskové oddíly) a především stav našich aplikací.
  • Pro základní sledování používáme nástroj icinga2 (certifikáty, ping, https). V přípravě je sledování také detailnějších informací o provozu stroje (zaplnění disků, zátěž, NTP, statistika sítě, …)

Co zajišťuje zákazník

Zákazník zajišťuje a provozuje následující komponenty:

• Server (preferováno virtuální) připojený do sítě internet
  
  • IP adresa, DNS název
  • CPU (plus počet fyzických jader)
    
    • portál - Pro portály větších škol doporučujeme minimálně 8 jader, portály menších škol stačí 4
    • ws, cms - Modul WS všech škol alespoň 4 jádra
    • demo - alespoň 2 jádra, doporučená také 4
  •  RAM
    • portál - Pro portály větších škol doporučujeme minimálně 8 GB, portály menších škol 4 GB
    • ws, demo, cms - Modul WS a demo portály všech škol minimálně 4 GB
• Operační systém: Nainstalovaný čistý Debian Linux stabilní větve - aktuálně 11, konkrétní verzi domluvíte s námi (my se posunujeme řízeně každé zhruba 3 roky)
  
  • Nakonfigurované zdroje pro aktualizaci/zabezpečování Debianu jako takového - tedy zdroje pro apt - Debianí repository musejí být ze serveru dostupné. (můžete využívat ty světové a nebo například překonfigurujte apt na vaše lokální univerzitní mirrory, ale musejí být dostupné a aktualizované).
  • Žádné jiné významné aplikace - nelze garantovat jejich funkčnost při upgradech systému
  • Výjimkou jsou nástroje pro Váš monitoring, Vaše zálohování, Vaše synchronizování času (NTP) atd. samozřejmě nejsou problém - jen o nich potřebujeme pro jistotu vědět
• Disk, partitions
  
• Obecně je nám jedno, jak přesně budete mít rozdělené a mountované partitions na filesystem, ale několik věcí chceme či preferujeme:
• / (root)
  • prosíme alespoň o 30 GB volného místa poté, co nainstalujete čistý Debian (plus připočtěte případně další hodnoty viz postupně níže)
• /tmp
  • máte-li mountováno na extra partition, prosíme alespoň 20 GB (uploadování dočasných souborů a podobně)
  • máte-li to mountováno společně s root (/), navyšte požadovanou kapacitu root (/) o 20 GB
• /var/lib/tomcat/logs-OLD
  • sem kopírujeme každý den staré zazipované logy a držíme je 2 roky (starší 2 let mažeme). Na provozních systémech může zabírat až 50 GB. Namapujte (či symlinkujte) si to prosím na extra partition
  • máte-li to mountováno společně s root (/), navyšte požadovanou kapacitu root (/) o 50 GB.
  • demo - na demo instalacích jsou logy maličké, stačí 10 GB
• /mnt/stag-data
  • do tohoto adresáře máme udělán symlink (z /var/lib/tomcat/PORTAL-data/read-write/tmp ) na speciální "náš" dočasný adresář pro držení dočasných dat našich aplikací (vygenerované reporty, heap dumpy a další). Jsou to data, která jsou dočasná ve smyslu, že se tam budou nacházet maximálně jednotky dní, ale zároveň je nechceme mít v systémovém /tmp (v případě zaplnění to nezpůsobí problémy celému systému).
  • může být namontováno na pomalejší úložiště, například na nějaké síťové, nepotřebujeme to extra rychlé jako běžný disk.
  • toto bychom VELMI PREFEROVALI mít mountované na extra partition. Toto je novinka od listopadu 2022 a postupně Vás poprosíme o implementaci, tj. čtete-li tento text brzy po 11/2022, ještě o tom asi nevíte :-)
  • VELIKOST: Velikost tohoto místa se odvíjí od množství paměti RAM serveru, protože sem chceme dávat případné dumpy paměti při pádech aplikace, tj. prosíme, aby velikost tohoto místa byla alespoň: 2x velikost paměti RAM + 20 GB (pro server s 8 GB RAM tedy prosíme o 36 GB místa).
  • demo, cms - na demo instalacích není nutné speciální mount ani tolik místa, řekněme že stačí jen o cca 1x velikost paměti RAM plus 10 GB místa na disku více
• [volitelně] /var/lib/tomcat/PORTAL-data/semestralky
  • Pouze portál
  • Používáte-li náš modul pro odevzdávání semestrálních prací, hlídejte si prosím velikost tohoto adresáře, případně si jej namountujte (přímo či přes symlink) na nějaký jiný filesystém. Data sem uložená prakticky neustále pouze přibývají, není nutné je mít na rychlých discích.
  • Začínáte-li s modulem, doporučujeme vyhradit cca 20 GB pro začátek. Pak sledujte, kolik to zabírá místa. Po informace - na ZČU běží modul od roku 2007. Do roku 2021 včetně zabírají uložené semestrálky 520 GB, poslední roky to je cca 70-100 GB ročně.
• [volitelně] /var/lib/tomcat/PORTAL-data/lokalni_repository
  • Pouze portál a ws
  • Pokud chcete používat možnost ukládání souborů na lokální filesystém (ukládání vybraných typů souborů na lokální filesystém místo do databáze), hlídejte si prosím velikost tohoto adresáře, případně si jej namountujte (přímo či přes symlink) na nějaký jiný filesystém. Data není nutné mít na rychlých discích. Typicky se mountuje na nějaké síťové úložiště (na ZČU se jedná například o NFS) a může se hodit mít jej namontováno stejně na portál i na ws.
• SWAP partitions - doporučujeme velikost 2GB
  
• SSL certifikát podepsaný některou z důvěryhodných certifikačních autorit určený pro HTTPS komunikaci
  
  • Detailní popis možností pro správu SSL certifikátů je popsán v samostatné kapitole níže.
• Veřejné klíče správců, kteří provádějí úvodní instalaci nástroje puppet - tyto klíče nám prosím vložte do /root/.ssh/authorized_keys, aby se tam naši správci dostali napoprvé:

  • ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAAzPh8gesJnZtC3txw9OHa8C9G+JeRJrKUR5whpJfb+dRAlnwI7FFeoHBS5qZpkbmCbqZsfzZSZjWEiqkqWH+iyowBGOYa37NkYlEVOf5BgbJcSKX5cZKqW102Pu03Q4t53/Mh7tvJGRvRDGKfMLBH3nHMDwXOYvAVGl5rrxYf/q7f+jA== svamberg
    
        ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMIm7SR5CPqtoMhQYUN6RZNCeNP0mJUsOhjombJxhKxd5XuKFUoFHhs4gzlR30RoHB0/tXAsYWk5wYoYl3f4LoE= honza801@ui424p04-lps.civ.zcu.cz
    
        ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDQzqvEbJRqc4i1Js4XO4WsBp2k6nJEcMNAT3DxM+8CojD+rHg3Zl2MfofPKCcAaYpvH7P+lOdHACCSH0Qlbys15eX1nI50ZzVlucZUGVZdzVotwMnd4+F9/siSRLqYhThWR0tF3QssfSd2BOthQNAkFNHtXJQcO5NYDYsRDRqww0X6gMl6NNghKxuThI8r3zVD3i86JwZ5V3mmwPxni3MoF6fh8sRTILyTNalO2K+7WIQlYB2pFdEqH6Kmt8W3NauJVhCABRpA33XpiJG8qsod6emearl79Bul7TnRMHaL/hezqnWnPA9wfd6BHTBssAUkurOlIZMa08MQgRpcFVfD0FFCS664jJ4Qm1JqGVBTxI/90JaPNBFrXdLQyT8Rwsa7ADkRBDROhgTAmvuRynCMVkWiir4VapL9V1vugTZ04q9/TscaiiwtzG2g+4n+7Gqva6/mVhOP9ecNjSh3hzZk506MNzs+2HgDqeRvcGtjBDXkfEvYPMCCGRT5Qs2jzR4QHB+uRWjFQFJCqRADAnmIUpCFiCQ5vRd3QSTixg5yPM4AbTBEjPTbudoNmkF3qVNwH+3vW8S87e4EwAuzpGKfrII8YZhcD6lgPnmKZSf7uvf728stQmtIWHBirCRgZrPxOPLCYlCPL9+GsE7aEMph5dD/r5c95scTfZe7Uz+JuQ== anetkold-root
    

  • Následující údržbu těchto klíčů a doplnění přístupů vývojářů a správců provádí již náš nástroj puppet.
• Nastavený firewall - viz detailní popis v podkapitole níže.
• Monitorování - monitorujte prosím Vašimi prostředky veškerý stav serveru tak, jak jste zvyklí u svých vlastních služeb, tedy:
  
  • dostupnost (ping, https),
  • platnost HTTPS certifikátu,
  • volné místo na všech diskových oddílech (sledujte prosím všude alespoň 2GB, ideálně alespoň 5GB volného místa)
  • ... a veškeré dalsí sondy, které umíte
  • + Monitorovat lze stav portálu i na aplikační úrovni (stav/funkčnost jednotlivých aplikací).
  • + Monitorovat lze URL https://_SERVER_NAME_/PortalUpdaterClient/monitor?type=ServerState , na kterém se nachází buď textový řetězec začínající prefixem "OK:" (vše ke v pořádku) a nebo "WARNING:" či "ERROR:".
  • (poslední dvě věci monitorujeme i my, viz výše)
  • Používaný systém icinga2 je ze standardního balíku a je na standardním portu, monitorovaný klient se připojuje k serveru. Server ověřuje klienta a předává mu konfiguraci. Je tedy řízen z monitorovacího serveru. Z tohoto důvodu není vhodné zasahovat do konfigurace. Je možné stroj sledovat jinými nástroji nebo jinou instancí icingy. Je možné doplnit libovolnou kompatibilní sondu a nastavit patřičné notifikace.
• Zálohování
  • Zálohování serveru je zcela ve Vašich rukách, my žádné zálohy neděláme. Zálohujte prosím:
    • ideálně celý filesystém stroje či například pravidelně jeho snapshoty
    • není-li možné, alespoň adresář /opt/tomcat (a veškeré podadresáře - a pozor, vedou-li odtamtud někam symlinky, tak i cílová místa)
• Přesný čas na serveru (NTP?) - podle zvyklostí Vaší školy prosím zajistěte na serveru například NTP tak, aby datum a čas na stroji byl vždy aktuální.
• SMTP relay server - pro odesílání e-mailů z aplikací IS/STAG

Zajišťuje zákazník - Nastavení Firewallu - jaké přístupy potřebují naše servery/aplikace

Pozor, tato kapitovla se týká jen webové platformy (portál, WS, CMS) popis přístupů potřebných pro databázové servery se nachází zde.

Kapitola obsahuje kompletní popis toho, jaké přístupy server vyžaduje pro své správné fungování. Nebudou-li některé přístupy k dispozici, nemůžeme pak garantovat plnou funkčnost služeb (nejen v daný okamžik instalace, ale kdykoliv v čase). Upozorňujeme, že ZČU (dodavatel) se na serverech nestará o žádné firewally - to je plně v kompetenci zákazníka (my nevíme, jak jste zvyklí u sebe provozovat kaskádu firewallů a související infrastrukturu) - tedy i lokální firewally v Debianu na daném serveru jsou plně pod vaší kontrolou. Dodavatel při instalaci ani provozu firewall nijak neovlivňuje.

Pro následující řádky platí, že zkratka SRV znamená "tento server, o kterém mluvíme".

Servery lze podle účelu rozdělit na několik skupin a u nich se pak liší typické potřeby na firewall - některé věci jsou společné, některé pak navíc specifické pro konkrétní kategorii:

Firewall - nastavení společné všem kategoriím

Jaká jsou vyžadovna funkční odchozí spojení ze serveru SRV:

• ze SRV do Vámi nakonfigurovaných Debian repositářů (tj. potřebujeme prostě aby Vámi dodaný Debian byl funkční - tj. konfigurace debianích zdrojů balíčků je na vás - buď použijete originální zdroje a nebo např. mirror na vaší škole - ať tak jako tak, musí vaše firewally zajistit přístup k těmto repository)
• ze SRV do příslušné (produkce / demo) databáze IS/STAG (typicky port 1521 nebo 1526)
• ze SRV k portu 443 serverů: is-stag.zcu.cz, ipmil.civ.zcu.cz, ftp.zcu.cz  (tam máme my naše Debian/GIT repositáře našich modulů)
• ze SRV k portu 8140 serveru talos.civ.zcu.cz   (správa puppet konfigurace)
• ze SRV k portu 5665 serveru icinga.zcu.cz    (komunikace monitoring agenta icinga se serverem)
• ze SRV k SMTP relay zákazníka, typicky port 25 (viz dále)
• ze SRV ke všem dalším systémům, se kterými je IS/STAG na dané škole integrován (individuální domluva podle toho, kam všude stroj komunikuje - spisovky, Moodly, finance, RUIAN, UZIS, Marbes, ...)

Jaká jsou vyžadovna funkční přímá příchozí spojení na server SRV (přímá = přímo po běžném internetu, nikoliv přes jakoukoliv VPN/tunel):

• Dostupný SRV na portu 443 ze serverů: is-stag.zcu.cz, icinga.zcu.cz, z příslušného (produkce / demo) databázového serveru IS/STAG Vaší školy  (první dva stroje správa, monitoring, poslední na komunikaci mezi komponentami IS/STAG)
• V případě, že se jedná o server kde běží modul WS (či je to server CMS): Dostupný SRV na portu 80 ze serveru: z příslušného (produkce / demo) databázového serveru IS/STAG Vaší školy (komunikace mezi komponentami IS/STAG)
• Dostupný SRV na portech 443 a 22 ze všech IP adres vývojářů a správců (lze využít adresní rozsahy 147.228.101.0/24 a 147.228.1.0/24, netřeba konfigurovat per vývojář).
  • V případě, že vy jako škola máte pro nás vývojáře VPN pro přístup, pak přístup na SSH lze omezit pouze přes VPN. Přístup na HTTPS prosíme ideálně nechat dostupný přes běžnou síť.

Firewall - nastavení pro produkční servery - tedy provozní portály IS/STAG a servery delegované pro modul WS

Navíc oproti společnému nastavení: Jaká jsou vyžadovna funkční přímá příchozí spojení na server SRV (přímá = přímo po běžném internetu, nikoliv přes jakoukoliv VPN/tunel):

• Dostupný SRV na port 443 bez omezení zdrojové adresy (tj. z celého světa) - typicky jsou produkční webové servery dostupné z celého světa :-)

Firewall - nastavení pro TEST / DEMO servery - tedy zkušební portály IS/STAG či zkušební moduly WS

Navíc oproti společnému nastavení: Jaká jsou vyžadovna funkční přímá příchozí spojení na server SRV (přímá = přímo po běžném internetu, nikoliv přes jakoukoliv VPN/tunel):

• Dostupný SRV na port 443 z oblasti definované zákazníkem - například pouze z jeho školního adresního rozsahu a podobně - zde záleží na vás, jak omezíte přístup. Explicitně definované přístupy na HTTPS ze společného nastavení je však třeba zachovat!

Firewall - nastavení pro servery, které jsou součástí státní sítě CMS

Jedná se typicky o stag-cms.XXX.cz servery, které zajišťují konektor IS/STAG do státní sítě CMS, například napojení na základní registry ISZR (popis viz. zde).

Navíc oproti společnému nastavení: Jaká jsou vyžadovna funkční odchozí spojení ze serveru SRV:

• ze SRV do státní sítě CMS (řešeno typicky separátním síťovým interfacem s odchozí konektivitou bez omezení)

Navíc oproti společnému nastavení: Jaká jsou vyžadována funkční příchozí spojení na server SRV:

• Nic navíc není vyžadováno. HTTPS port serveru nemusí být otevřen (kromě zdrojových serverů definovaných ve společném nastavení) vůči světu ani vůči zákazníkově síti, pro běžné uživatele na tomto portu žádná služba neběží.
• Směrem ze sítě CMS taktéž není očekáváno žádné příchozí spojení.

Správa SSL certifikátů pro https

Nejprve obecná pravidla platná pro SSL certifikáty:

• V případě serveru s více doménovými jmény je nutné, aby certifikát pokrýval jméno vracené z DNS PTR záznamem
• Certifikát je požadován už při instalaci (je tedy vyžadován certifikát i na případných dočasných doménových jménech)
• Nezapomeňte případně pokrýt i název aplikace pro ECTS course catalog, tj. například "ects.zcu.cz"

Od června 2023 nabízíme školám možnost automatické správy certifikátu získaného od certifikační autority Let's Encrypt. Existují tedy dvě varianty:

Varianta #1: Certifikáty od Let's Encrypt a jejich automatická správa/výměna

Aktuálně tuto variantu používají: ZČU, JČU, UTB pro portál a test, VFU, UPCE, UJEP, všechny "malé" outsourcované školy.

V případě této varianty platí, že po vzájemné domluvě dojde k převzetí správy certifikátů dodavatelem. První výměna za Let's Encrypt proběhne nikoliv nutně hned, ale až vyprší původní dobíhající certifikát.

Jako dodavatel Vám tuto variantu nabízíme jako pro Vás především bezstarostnou možnost (mající své výhody i nevýhody, zvažte). Pokud u vás převáží výhody vlastního certifikátu, využijte druhou možnost:

Poznámka: Na ZČU nelze použít pro servery sloužící pro napojení IS/STAG na státní síť CMS / KIVS, kvůli bezpečnostním politikám (server je "schovaný" před světem a proto tam automatická výměna přes Let's Encrypt není realizovatelná). Uvidíme v budoucnu.

Varianta #2: Certifikáty od kohokoliv jiného - spravuje si zákazník sám

Aktuálně tuto variantu používají: UPOL, OSU, TUL, UHK, UTB pro WS.

V případě této varianty platí, že o správu/výměnu certifikátu se stará zákazník sám. Dodavatel vypršení certifikátu nemonitoruje, na vypršení neupozorňuje. K dispozici je od dodavatele konkrétní postup, jak certifikát na serverech vyměnit:

1. Úpravy provádějte jako root
2. Zazálohujte si obsah adresáře /opt/tomcat/conf/ssl
3. Nový certifikát nahrajte do /opt/tomcat/conf/ssl, jedná se o soubory: <URL SERVERU>.crt, <URL SERVERU>.key, chain.pem (tento se Vám pravděpodobně nebude měnit, pokud nebudete měnit dodavatele certifikátu, obsahuje certificate chain - správně seřazený!)
   • Poznámka: Na některých serverech jsou certifikáty v souborech server.crt, server.key a pak jsou vedle symlinky pojmenované podle URL serveru... zachovejte prostě ten stav, jak tam je
4. Spustit příkaz 'puppet-test' - tim se nastaví správě práva k souborům
5. Restartujte tomcat příkazem 'tomcat restart'. - dojde tedy k řádově 1-2 minutovému výpadku serveru.
6. Po naběhnutí tomcatu v každém případě zkontrolovat příkazem (na konci musí vypsat "Verify return code: 0 (ok)"):
   openssl s_client -host <URL SERVERU> -port 443 -verify 9

V případě problémů nás kontaktujte přes RT, děkujeme.