IBM i Verze 7.3. Zabezpečení DCM (Digital Certificate Manager) IBM
|
|
- Jarmila Burešová
- před 6 lety
- Počet zobrazení:
Transkript
1 IBM i Verze 7.3 Zabezpečení DCM (Digital Certificate Manager) IBM
2
3 IBM i Verze 7.3 Zabezpečení DCM (Digital Certificate Manager) IBM
4 Poznámka Před použitím těchto informací a produktu, ke kterému se tyto informace vztahují, si přečtěte informace uvedené v části Poznámky na stránce 87. Toto vydání je určeno pro operační systém IBM i 7.3 (číslo produktu 5770-SS1) a pro všechna následná vydání a modifikace, dokud nebude v nových vydáních uvedeno jinak. Tato verze nemůže být provozována na žádném počítači RISC (Reduced Instruction Set Computer) ani na modelech CISC. Tento dokument může obsahovat odkazy na licenční interní kód (LIC). Licenční interní kód je strojový kód, který jste dle podmínek licenční smlouvy IBM pro strojový kód oprávněni užívat. Copyright IBM Corporation 1999, 2015.
5 Obsah DCM (Digital Certificate Manager) Novinky ve verzi IBM i Soubor PDF produktu DCM Koncepty produktu DCM Rozšíření certifikátu Obnovení certifikátu Rozlišovací jméno Digitální podpisy Dvojice veřejného a soukromého klíče Algoritmy certifikátů Vydavatel certifikátů (CA) Umístění seznamu odvolaných certifikátů (CRL)... 6 Paměti certifikátů Šifrování IBM Cryptographic Coprocessors for IBM i Definice aplikace Ověření platnosti Scénáře: DCM Scénář: Použití certifikátů pro externí ověření Vyplnění plánovacích formulářů Vytvoření požadavku na serverový nebo klientský certifikát Konfigurace aplikací pro použití SSL Importování a přiřazení podepsaného veřejného certifikátu Spuštění aplikací v režimu SSL (Volitelné): Definování seznamu důvěryhodných CA pro aplikaci Scénář: Použití certifikátů pro interní ověření Vyplnění plánovacích formulářů Konfigurace HTTP serveru personálních informací pro použití SSL Vytvoření a provozování lokálního CA Konfigurace ověření klientů pro webový server personálních informací Spuštění webového serveru personálních informací v režimu SSL Instalace kopie certifikátu lokálního CA do prohlížeče Vyžádání certifikátu od lokálního CA Scénář: Nastavení vydavatele certifikátů (CA) pomocí produktu DCM Vyplnění plánovacích formulářů pro produkt DCM 26 Spuštění produktu IBM HTTP Server for i na serveru System A Konfigurace serveru System A jako vydavatele certifikátů (CA) Vytvoření digitálního certifikátu pro server System B Přejmenování souborů.kdb a.rdb na serveru System B Změna hesla paměti certifikátů na serveru System B 30 Definování seznamu důvěryhodných CA pro aplikaci IBM i VPN key manager na serveru System B Plánování použití produktu DCM Požadavky pro nastavení produktu DCM Pokyny pro zálohování a obnovu dat produktu DCM 32 Typy digitálních certifikátů Používání veřejných certifikátů versus vydávání soukromých certifikátů Digitální certifikáty pro bezpečnou komunikaci SSL. 36 Digitální certifikáty pro ověření uživatelů Digitální certifikáty a produkt EIM (Enterprise Identity Mapping) Digitální certifikáty pro připojení v rámci VPN Digitální certifikáty pro podepisování objektů Digitální certifikáty pro ověřování podpisů objektů.. 40 Konfigurace produktu DCM Spuštění DCM Prvotní nastavení certifikátů Vytvoření a provozování lokálního CA Správa uživatelských certifikátů Vydávání certifikátů jiným uživatelům než uživatelům systému IBM i pomocí rozhraní API. 49 Získání kopie certifikátu soukromého CA Správa certifikátů od veřejného internetového CA 51 Správa veřejných internetových certifikátů pro komunikační relace SSL/TLS Správa veřejných internetových certifikátů k podepisování objektů Správa certifikátů pro ověřování podpisů objektů 55 Obnovení existujícího certifikátu Obnovení certifikátu lokálního CA Obnovení certifikátu internetového CA Import a obnovení certifikátu získaného přímo od internetového CA Obnovení certifikátu pomocí vytvoření dvojice soukromého a veřejného klíče a CSR Import certifikátu Správa produktu DCM Použití lokálního CA k vydávání certifikátů pro jiné servery IBM i Použití soukromého certifikátu pro SSL/TLS Pamě certifikátů *SYSTEM neexistuje Pamě certifikátů *SYSTEM existuje použití souborů jako jiný systémový certifikát Použití soukromého certifikátu pro podepisování objektů v cílovém systému Pamě certifikátů *OBJECTSIGNING neexistuje Pamě certifikátů *OBJECTSIGNING existuje 65 Správa aplikací v produktu DCM Vytvoření definice aplikace Správa přiřazení certifikátu k aplikaci Definování seznamu důvěryhodných CA pro aplikaci Správa certifikátů prostřednictvím data ukončení platnosti Potvrzování certifikátů a aplikací Přiřazení certifikátu k aplikacím Správa umístění CRL Copyright IBM Corp. 1999, 2015 iii
6 Uložení klíčů certifikátů do produktu IBM Cryptographic Coprocessor Použití hlavního klíče koprocesoru pro zašifrování soukromého klíče certifikátu Správa umístění požadavků pro vydavatele certifikátů PKIX Správa umístění LDAP pro uživatelské certifikáty.. 74 Podepisování objektů Ověřování podpisu objektů Odstraňování problémů s produktem DCM Odstraňování obecných problémů a problémů s hesly 79 Odstraňování problémů s pamě mi certifikátů a databázemi klíčů Odstraňování problémů s prohlížečem Odstraňování problémů s produktem HTTP Server for IBM i Odstraňování problémů s přiřazením uživatelského certifikátu Související informace o produktu DCM Poznámky Informace o programovacím rozhraní Ochranné známky Ustanovení a podmínky iv IBM i: DCM (Digital Certificate Manager)
7 DCM (Digital Certificate Manager) Produkt DCM (Digital Certificate Manager) vám umožní spravovat digitální certifikáty pro vaši sí a používat SSL, a tím zajistit bezpečnou komunikaci pro mnoho aplikací. Digitální certifikát je elektronický prostředek pro ověřování, který lze použít, pokud je nutno v elektronické transakci provádět prokazování totožnosti. Počet možných použití digitálních certifikátů se stále zvyšuje, což umožňuje zdokonalovat opatření pro zabezpečení sítí. Digitální certifikáty jsou např. zásadní pro konfiguraci a použití SSL (Secure Sockets Layer). Použití SSL vám umožní vytvořit zabezpečená spojení mezi uživateli a aplikacemi na serveru v rámci nedůvěryhodných sítí, jakou je např. Internet. SSL poskytuje jedno z nejlepších řešení ochrany soukromých citlivých dat, jako jsou jména uživatelů a hesla, při použití Internetu. Mnoho služeb a aplikací serveru IBM i, jako například FTP, Telnet nebo HTTP server, poskytují za účelem zajištění utajení dat podporu SSL. Server IBM i poskytuje rozsáhlou podporu digitálních certifikátů, což vám umožní použít digitální certifikáty jako doklady v řadě aplikací pro zabezpečení. Kromě použití certifikátů při konfiguraci SSL je můžete použít jako doklady při ověření klientů jak v transakcích SSL, tak v transakcích v rámci sítí VPN (Virtual Private Network). Digitální certifikáty a přiřazené bezpečnostní klíče můžete používat také k podepisování objektů. Podepisování objektů vám umožňuje zaznamenat změny obsahu objektů nebo pokusy o jeho nedovolené užívání, a to pomocí ověřování podpisů objektů, které zajiš ují integritu objektů. Využití podpory certifikátů na serveru IBM i je snadné, jestliže k centrální správě certifikátů pro vaše aplikace použijete bezplatně dodávanou funkci DCM. Produkt DCM vám umožní spravovat certifikáty, které obdržíte od kteréhokoliv vydavatele certifikátů (CA). Produkt DCM můžete také použít k tomu, abyste vytvořili a provozovali vlastního, lokálního vydavatele certifikátů a mohli vydávat soukromé certifikáty pro aplikace a uživatele ve vaší organizaci. Klíčem k efektivnímu použití certifikátů a dosažení přínosů v oblasti bezpečnosti je správné plánování a ohodnocení. Další informace o tom, jak certifikáty fungují a jak lze pomocí produktu DCM spravovat certifikáty a aplikace, které je využívají, uvádějí tato témata: Související informace: SSL (Secure Sockets Layer) Podepisování objektů a ověřování podpisu Novinky ve verzi IBM i 7.3 Přečtěte si o nových nebo významně změněných informacích o produktu DCM (Digital Certificate Manager). Kořenové a intermediační certifikáty CA v Úložiště certifikátů vytvořená v produktu IBM i 7.3 nejsou automaticky naplněna daty s výchozím seznamem kořenových a intermediačních certifikátů CA. Chcete-li přidat certifikáty CA do úložiště, vyberte volbu Spravovat úložiště certifikátů, a pak vyberte volbu Naplnit certifikáty CA, která představuje předdefinovaný seznam certifikátů, které lze přidat do úložiště certifikátů. Kořenové a intermediační certifikáty CA dostupné pro přidání jsou verze certifikátů CA, které používají aktualizovaný algoritmus SHA-2 a zvýšené délky veřejného klíče. Pokud vyžadovaný certifikát CA není v tomto seznamu, spolupracujte s vydavatelem certifikátu a importujte kořenový certifikát CA do úložiště. Informace o změnách a novinkách Technické změny najdete pomocí níže uvedených značek: v Symbol v Symbol označuje začátek nových nebo změněných informací. označuje konec nových nebo změněných informací. Copyright IBM Corp. 1999,
8 Více informací o tom, co je nového a co se změnilo, najdete v tématu Sdělení pro uživatele. Soubor PDF produktu DCM Soubor ve formátu PDF obsahující tyto informace si můžete zobrazit a vytisknout. Chcete-li si toto téma prohlédnout nebo stáhnout ve formátu PDF, vyberte odkaz Digital Certificate Manager. Uložení souborů ve formátu PDF Chcete-li uložit soubor PDF na pracovní stanici za účelem zobrazení nebo tisku: 1. Klepněte pravým tlačítkem myši na odkaz na PDF ve vašem prohlížeči. 2. Klepněte na volbu pro lokální uložení souboru PDF. 3. Přejděte do adresáře, do kterého chcete soubor PDF uložit. 4. klepněte na tlačítko Uložit. Jak stáhnout produkt Adobe Acrobat Reader K prohlížení a tisku souborů ve formátu PDF musíte mít v systému nainstalován program Adobe Reader. Kopii zdarma můžete stáhnout z webového serveru Adobe. Koncepty produktu DCM Digitální certifikát je digitální doklad, který potvrzuje platnost totožnosti vlastníka certifikátu, podobně jako např. cestovní pas. Identifikační informace poskytované digitálním certifikátem jsou známy pod názvem rozlišovací jméno subjektu. Důvěryhodná strana, zvaná vydavatel certifikátů (CA), vydává digitální certifikáty uživatelům nebo organizacím. Důvěra ve vydavatele certifikátů je základem důvěry v certifikát jako platný doklad. Digitální certifikát také obsahuje veřejný klíč, který je součástí dvojice klíčů veřejný-soukromý. Různé zabezpečovací funkce spoléhají na použití digitálních certifikátů a dvojic klíčů k nim přidružených. Pomocí digitálních certifikátů můžete konfigurovat relace SSL (Secure Sockets Layer), čímž zajistíte zabezpečené komunikační relace mezi uživateli a aplikacemi vašeho serveru. Tuto ochranu můžete rozšířit konfigurací mnoha aplikací, které podporují SSL, a požadovat certifikáty místo uživatelských jmen a hesel kvůli lepšímu zajištění uživatelského ověření. Další informace o principu fungování digitálních certifikátů naleznete v těchto tématech: Rozšíření certifikátu Rozšíření certifikátu jsou informační pole, která poskytují dodatečné informace o certifikátu. Rozšíření certifikátu poskytují nástroje k rozšíření původních standardů x.509. Zatímco informace pro některá rozšíření jsou poskytovány za účelem rozšíření identifikačních informací certifikátu, jiná rozšíření poskytují informace o šifrovacích funkcích certifikátu. Ne všechny certifikáty používají pole pro rozšíření, aby rozšířily rozlišovací jméno a další informace. Počet a typ rozšířených polí, která certifikáty používají, se liší mezi vydavateli certifikátů (CA), kteří certifikáty vydávají. Například lokální CA, který poskytuje produkt DCM (Digital Certificate Manager), vám umožní použít pouze rozšíření certifikátu Alternativní jméno subjektu. Toto rozšíření umožňuje přiřadit certifikát ke specifické IP adrese, plně kvalifikovanému jménu domény nebo adrese elektronické pošty. Pokud zamýšlíte používat certifikát k identifikaci koncového bodu připojení IBM i VPN (Virtual Private Network), musíte poskytnout informace pro tato rozšíření. Související pojmy: 2 IBM i: DCM (Digital Certificate Manager)
9 Rozlišovací jméno Rozlišovací jméno (Distinguished name, DN) je termín, který popisuje identifikační informace certifikátu a je součástí certifikátu samotného. Certifikát obsahuje informaci o rozlišovacím jméně jak pro vlastníka, tak pro žadatele certifikátu (takzvané rozlišovací jméno subjektu) a o CA, který vydává certifikát (nazývá se rozlišovací jméno vydavatele). V závislosti na identifikační metodě CA, který certifikát vydává, může DN obsahovat řadu různých informací. Obnovení certifikátu Proces obnovení certifikátu, který používá produkt DCM, se liší dle typu vydavatele certifikátů (CA), který příslušný certifikát vydal. Pokud použijete lokálního CA k podepsání obnoveného certifikátu, použije produkt DCM poskytnuté informace k vytvoření nového certifikátu v aktuální paměti certifikátů a dřívější certifikát zachová. Pokud k vydání certifikátu používáte známého internetového CA, můžete obnovu certifikátu obsluhovat jedním ze dvou způsobů: importovat obnovený certifikát ze souboru, který obdržíte od vydavatele certifikátù pro podepisování, nebo nechat DCM pro certifikát vytvořit dvojici klíčů. Produkt DCM poskytuje první volbu v případě, že dáváte přednost obnovení certifikátu přímo s CA, který jej vydal. Pokud zvolíte vytvoření nové dvojice klíčů, ovládá produkt DCM obnovu stejným způsobem, jakým ovládal vytváření certifikátu. Produkt DCM vytvoří novou dvojici klíčů (veřejný-soukromý) pro obnovený certifikát a vygeneruje požadavek CRS (požadavek na podepsání certifikátu) zahrnující veřejný klíč a další informace, které jste uvedli pro nový certifikát. CSR můžete použít pro požadavek na nový certifikát od VeriSign nebo jiného veřejného CA. Jakmile od CA obdržíte podepsaný certifikát, můžete produkt DCM používat k importu certifikátů do odpovídající paměti certifikátù. Pamě certifikátù potom obsahuje obě kopie certifikátu, původní a nově vydaný, obnovený certifikát. Pokud nenecháte DCM vygenerovat novou dvojici klíčů, DCM vás povede procesem importu obnoveného, podepsaného certifikátu ze stávajícího souboru, který jste obdrželi od CA, do paměti certifikátů. Předchozí certifikát je pak nahrazen importovaným, obnoveným certifikátem. Rozlišovací jméno Rozlišovací jméno (Distinguished name, DN) je termín, který popisuje identifikační informace certifikátu a je součástí certifikátu samotného. Certifikát obsahuje informaci o rozlišovacím jméně jak pro vlastníka, tak pro žadatele certifikátu (takzvané rozlišovací jméno subjektu) a o CA, který vydává certifikát (nazývá se rozlišovací jméno vydavatele). V závislosti na identifikační metodě CA, který certifikát vydává, může DN obsahovat řadu různých informací. Každý CA má určitou strategii, která určuje, jaké identifikační informace tento CA vyžaduje pro vydání certifikátu. Někteří veřejní internetoví CA vyžadují jen málo informací, jako např. jméno a adresu elektronické pošty. Jiní veřejní CA mohou před vydáním certifikátu vyžadovat přísnější prokázání těchto identifikačních informací. Například CA, kteří podporují standardy PKIX (Public Key Infrastructure Exchange), mohou před vydáním certifikátu požadovat, aby žadatel verifikoval identifikační informace prostřednictvím tzv. vydavatele registrace (Registration Authority, RA). Jestliže tedy plánujete používat certifikáty jako prostředek pro ověřování, měli byste se seznámit s požadavky na způsob identifikace u různých CA, abyste zjistili, zda jejich požadavky odpovídají vašim potřebám v oblasti zabezpečení. Pomocí produktu Digital Certificate Manager (DCM) můžete provozovat soukromého vydavatele certifikátů a vydávat soukromé certifikáty. Pomocí produkt DCM také můžete generovat informace v DN a dvojice klíčů pro certifikáty, které vaší organizaci vydává veřejný internetový CA. Informace v DN, které můžete vygenerovat pro oba typy certifikátu, obsahují tyto údaje: v běžné jméno vlastníka certifikátu v organizace v organizační jednotka v lokalita nebo město v stát nebo oblast DCM (Digital Certificate Manager) 3
10 v země nebo region Pokud pomocí produktu DCM vydáváte soukromé certifikáty, můžete prostřednictvím rozšíření certifikátu uvádět pro certifikát další DN informace, včetně: v adresy IP verze 4 v úplného názvu domény v adresy elektronické pošty Související pojmy: Rozšíření certifikátu na stránce 2 Rozšíření certifikátu jsou informační pole, která poskytují dodatečné informace o certifikátu. Digitální podpisy Digitální podpis na elektronickém dokumentu nebo jiném objektu je vytvořen za použití určité formy šifrování a je ekvivalentem osobního podpisu na psaném dokumentu. Digitální podpis poskytuje důkaz o původu objektu a prostředek ověření integrity objektu. Vlastník digitálního certifikátu podepisuje objekt soukromým klíčem, který je k certifikátu přidružen při operaci generování podpisu. Příjemce objektu při operaci ověření podpisu použije veřejný klíč obsažený v certifikátu k ověření podpisu, který ověřuje jednak integritu podepsaného objektu a jednak odesílatele jako zdroj. Vydavatel certifikátů (CA) podepisuje certifikáty, které vydává. Takový podpis je řetězec binárních dat vytvořený při operaci generování podpisu pomocí soukromého klíče vydavatelů certifikátů. Libovolný uživatel pak může ověřit podpis na certifikátu, použije-li při operaci ověřování podpisu veřejný klíč vydavatele certifikátu. Digitální podpis je elektronický podpis, který vy nebo aplikace pro objekt vytváříte při operaci generování podpisu pomocí soukromého klíče certifikátu. Digitální podpis na objektu poskytuje jedinečnou elektronickou vazbu mezi totožností podepisovatele (vlastníka podepisovacího klíče) a původem objektu. Když přistupujete k objektu, který obsahuje digitální podpis, můžete ověřit podpis na objektu a zjistit tak, zda je zdroj objektu platný (například že aplikace, kterou právě stahujete, pochází z autorizovaného zdroje, jako je např. IBM). Proces verifikace vám rovněž umožní zjistit, zda u objektu nedošlo od okamžiku jeho podepsání k nějakým neautorizovaným změnám. Příklad použití digitálního podpisu Vývojář softwaru vytvořil aplikaci pro operační systém IBM i a chce ji distribuovat prostřednictvím Internetu, což je pro jeho zákazníky pohodlný a efektivní způsob. Uvědomuje si však, že zákazníci mají oprávněné obavy ze stahování programů z Internetu vzhledem k rostoucímu počtu objektů, které se tváří jako normální programy, avšak ve skutečnosti obsahují škodlivé programy, např. viry. Proto se rozhodne, že bude aplikaci digitálně podepisovat, aby si zákazníci mohli ověřit, že zdrojem aplikace je skutečně jeho společnost. K podpisu aplikace použije soukromý klíč digitálního certifikátu, který získal od známého veřejného vydavatele certifikátů. Pak dá aplikaci k dispozici zákazníkům ke stažení. Součástí stahovaného balíku je i kopie digitálního certifikátu, který použil k podepsání objektu. Když zákazník stahuje aplikační balík, může pomocí veřejného klíče certifikátu ověřit podpis na aplikaci. Zákazník takto může identifikovat a ověřit zdroj aplikace, a zároveň si ověří, že obsah objektu s aplikací nebyl od okamžiku podpisu objektu změněn. Související pojmy: Vydavatel certifikátů (CA) na stránce 5 Vydavatel certifikátů (CA) je důvěryhodná centrální administrační entita, která může vydávat digitální certifikáty uživatelům a serverům. Šifrování na stránce 8 Sdílený a veřejný klíč jsou dva různé typy kryptografických funkcí, které digitální certifikáty používají pro poskytnutí zabezpečení. 4 IBM i: DCM (Digital Certificate Manager)
11 Dvojice veřejného a soukromého klíče Každý digitální certifikát obsahuje veřejný klíč. Veřejný klíč a k němu přidružený soukromý klíč, který není součástí certifikátu, dohromady tvoří dvojici klíčů. Byly vytvořeny ve stejný okamžik a jsou matematicky propojeny. Každý certifikát, který vytvoříte, má dvojici klíčů. Dvojice veřejného a soukromého klíče Každý digitální certifikát obsahuje veřejný klíč. Veřejný klíč a k němu přidružený soukromý klíč, který není součástí certifikátu, dohromady tvoří dvojici klíčů. Byly vytvořeny ve stejný okamžik a jsou matematicky propojeny. Každý certifikát, který vytvoříte, má dvojici klíčů. Poznámka: Výjimkou z tohoto pravidla jsou certifikáty pro ověřování podpisů. Obsahují veřejný klíč, nemají však přidružen žádný soukromý klíč. Veřejný klíč je součástí digitálního certifikátu vlastníka a může ho použít kdokoliv. Soukromý klíč je však vlastníkem chráněn a je k dispozici pouze jemu. Tento omezený přístup zaručuje, že komunikace, používající daný klíč, jsou zabezpečené. Vlastník certifikátu používá tyto klíče k tomu, aby využil výhod šifrovacích bezpečnostních funkcí, které klíče nabízejí. Vlastník certifikátu může např. použít soukromý klíč certifikátu k tomu, aby podepsal data odesílaná mezi uživateli a servery, jako jsou objekty zpráv, dokumentů nebo kódu. Příjemce podepsaného objektu pak může použít veřejný klíč obsažený v certifikátu podepisovatele, aby podpis ověřil. Tyto digitální podpisy zajiš ují spolehlivost původu objektu a poskytují prostředek pro ověření integrity objektu. Související pojmy: Digitální podpisy na stránce 4 Digitální podpis na elektronickém dokumentu nebo jiném objektu je vytvořen za použití určité formy šifrování a je ekvivalentem osobního podpisu na psaném dokumentu. Vydavatel certifikátů (CA) Vydavatel certifikátů (CA) je důvěryhodná centrální administrační entita, která může vydávat digitální certifikáty uživatelům a serverům. Algoritmy certifikátů Algoritmy certifikátů jsou šifrovací algoritmy, které popisují matematické postupy vytváření dvojic klíčů a provádění operací s digitálními podpisy. Správce DCM podporuje algoritmy veřejného klíče ECC (Elliptic Curve Cryptographic) a RSA. Ve správci můžete zvolit vygenerování dvojice veřejný-soukromý klíč. Certifikát obsahuje informace k uvedení, který algoritmus se pro klíč použije. Certifikáty, které obsahují veřejný klíč, se někdy označují jako certifikáty RSA. Certifikáty obsahující veřejný klíč ECC se označují jako certifikáty ECDSA (Elliptic Curve Digital Signature Algorithm). Správce DCM obsahuje volbu umožňující vybrat algoritmus veřejného klíče, který se použije při vytváření certifikátu. Poznámka: Algoritmy ECC se netýkají certifikátů v úložišti *SIGNING a uživatelských certifikátů. Vždy jsou to dvojice klíčů RSA. Algoritmus veřejného klíče a algoritmus Message-Digest popisují matematický postup generování a ověřování digitálních podpisů. Certifikát rovněž obsahuje informace, které udávají algoritmus veřejného klíče a algoritmus Message-Digest, jež se použijí při vytváření podpisu tohoto certifikátu. Správce DCM podporuje následující algoritmy Message-Digest, které se používají při generování a ověřování podpisů: SHA1, SHA224, SHA256, SHA384 a SHA512. Jen pro ověřování podpisů správce DCM také podporuje algoritmy digest MD2 a MD5. Správce DCM obsahuje volbu umožňující vybrat algoritmus Message-Digest, který místní CA použije spolu s algoritmem veřejného klíče k podepisování certifikátů. Tato volba se zobrazí, po vytvoření certifikátu místního CA. Vydavatel certifikátů (CA) Vydavatel certifikátů (CA) je důvěryhodná centrální administrační entita, která může vydávat digitální certifikáty uživatelům a serverům. DCM (Digital Certificate Manager) 5
12 Důvěra ve vydavatele certifikátů je základem důvěry v certifikát jako platný doklad. CA pomocí svého soukromého klíče vytváří na certifikátu, který vydává, digitální podpis, aby potvrdil platnost původu certifikátu. Ostatní mohou ověřit autenticitu certifikátů, které CA vydává a podepisuje, pomocí veřejného klíče vydavatele certifikátů. CA může být bu veřejná komerční entita, jako je např. VeriSign, nebo to může být soukromá entita, kterou organizace provozuje pro své interní účely. Některé společnosti poskytují komerční služby vydavatele certifikátů pro uživatele Internetu. Produkt Digital Certificate Manager (DCM) vám umožňuje používat certifikáty od veřejných CA i soukromých CA. Produkt DCM můžete také použít k tomu, abyste provozovali vlastního soukromého lokálního vydavatele certifikátů a mohli pro systémy a uživatele vydávat soukromé certifikáty. Když lokální CA vydá uživatelský certifikát, produkt DCM automaticky přiřadí tento certifikát k uživatelskému profilu na serveru IBM i nebo jiné totožnosti uživatele. To, zda produkt DCM přiřadí certifikát k uživatelskému profilu nebo k jiné totožnosti uživatele závisí na tom, zda jste produkt DCM nakonfigurovali tak, aby používal produkt EIM (Enterprise Identity Mapping). Tím je zajištěno, že se přístupová a autorizační oprávnění certifikátu shodují s oprávněními vlastníka daného uživatelského profilu. Status důvěryhodný zdroj Slovní spojení důvěryhodný zdroj se týká zvláštního pojmenování, jímž je označen certifikát vydavatele certifikátů. Toto určení - důvěryhodný zdroj - umožňuje, aby prohlížeč nebo jiná aplikace autentizovaly a přijímaly certifikáty, které tento vydavatel certifikátů vydá. Když stahujete nějaký certifikát CA do svého prohlížeče, prohlížeč vám umožní, abyste jej označili jako důvěryhodný zdroj. Ostatní aplikace, které podporují použití certifikátů, musí být také nakonfigurovány tak, že nejprve musí důvěřovat danému CA a pak teprve mohou provést ověření certifikátů od tohoto CA a důvěřovat jim. Pomocí produktu DCM lze aktivovat nebo deaktivovat status důvěryhodného zdroje u certifikátů CA. Pokud zaktivujete určitý certifikát CA, můžete uvést, že aplikace mohou certifikát použít k ověření a schvalování certifikátů, které daný CA vydá. Jestliže určitý certifikát CA deaktivujete, nemůžete uvést, že aplikace mohou certifikát použít k ověření a schvalování certifikátů, které daný CA vydá. Strategická data vydavatele certifikátů Když vytváříte lokálního CA pomocí programu DCM, můžete pro lokálního CA zadat data týkající se zásad. Data týkající se zásad lokálního CA popisují oprávnění k podpisu, jež CA vlastní. Data týkající se zásad určují: v Zda může lokální CA vydávat a podepisovat uživatelské certifikáty. v Jak dlouho jsou certifikáty vydané lokálním CA platné. Související pojmy: Digitální podpisy na stránce 4 Digitální podpis na elektronickém dokumentu nebo jiném objektu je vytvořen za použití určité formy šifrování a je ekvivalentem osobního podpisu na psaném dokumentu. Dvojice veřejného a soukromého klíče na stránce 5 Každý digitální certifikát obsahuje veřejný klíč. Veřejný klíč a k němu přidružený soukromý klíč, který není součástí certifikátu, dohromady tvoří dvojici klíčů. Byly vytvořeny ve stejný okamžik a jsou matematicky propojeny. Každý certifikát, který vytvoříte, má dvojici klíčů. Umístění seznamu odvolaných certifikátů (CRL) Seznam odvolaných certifikátů (CRL) je soubor, který obsahuje všechny neplatné a odvolané certifikáty pro určitého vydavatele certifikátů (CA). Vydavatelé certifikátů periodicky aktualizují své CRL a dávají je k dispozici ostatním, aby je mohli publikovat v adresářích LDAP. Někteří CA, např. SSH ve Finsku, publikují CRL sami v adresářích LDAP, ke kterým lze přistupovat přímo. Jestliže CA publikuje svůj vlastní CRL, certifikát tuto skutečnost indikuje tím, že obsahuje distribuční místo CRL ve formě URI (Uniform Resource Identifier). 6 IBM i: DCM (Digital Certificate Manager)
13 Pomocí produktu DCM (Digital Certificate Manager) můžete definovat a spravovat umístění CRL, čímž zajistíte ještě přísnější ověření certifikátů, které používáte nebo které přijímáte od ostatních. Definice umístění CRL popisuje umístění serveru LDAP (Lightweight Directory Access Protocol), na němž je uložen CRL, a informace o přístupu k němu. Při připojení k serveru LDAP musíte poskytnout DN a heslo, abyste se vyvarovali anonymní vazby na server LDAP. Anonymní vazba na server nezajiš uje úroveň zabezpečení potřebnou pro přístup ke kritickým atributům jako je například CRL. V takovém případě může produkt DCM potvrdit odvolaný certifikát, protože není schopen získat správný stav z CRL. Pokud potřebujete anonymní přístup k serveru LDAP, pak musíte použít nástroj Directory Server Web Administration Tool a vybrat úlohu "Správa schématu" za účelem změny třídy zabezpečení (která je nazývána rovněž jako "přístupová třída") u atributů certificaterevocationlist a authorityrevocationlist z hodnoty "kritický" na hodnotu "normální". Aplikace provádějící ověření certifikátů přistupují do místa uložení CRL daného CA, pokud je toto definováno, a ověřují, zda CA určitý certifikát neodvolal. Produkt DCM vám umožňuje definovat a spravovat informace o umístění CRL, které aplikace potřebují při práci s CRL v průběhu ověření certifikátů. Příklady aplikací a procesů, které mohou provádět zpracování CRL při ověření certifikátů jsou: spojení virtuální privátní sítě (VPN), server IKE (Internet Key Exchange), aplikace, které umožňují SSL (Secure Sockets Layer) nebo proces podepisování objektů. Pokud nadefinujete umístění CRL a přidružíte ho k certifikátu CA, bude produkt DCM provádět zpracování CRL jako součást procesu ověřování certifikátů, které tento CA vydává. Související pojmy: Potvrzování certifikátů a aplikací na stránce 70 Pomocí produktu DCM (Digital Certificate Manager) můžete potvrzovat jednotlivé certifikáty nebo aplikace, které je používají. Seznam věcí, které produkt DCM kontroluje, se mírně liší podle toho, zda se potvrzuje certifikát nebo aplikace. Související úlohy: Správa umístění CRL na stránce 71 Pomocí produktu DCM (Digital Certificate Manager) můžete definovat a spravovat informace o umístění seznamu odvolaných certifikátů (CRL) pro určitého vydavatele certifikátů (CA), který se pak používá v rámci procesu potvrzování certifikátu. Paměti certifikátů Pamě certifikátů je speciální soubor databáze klíčů, který produkt DCM (Digital Certificate Manager) používá pro uložení digitálních certifikátů. Pamě certifikátů také obsahuje soukromý klíč certifikátu, pokud se nerozhodnete klíč uložit do produktu IBM Cryptographic Coprocessor. Produkt DCM vám umožňuje vytvořit a spravovat několik typů pamětí certifikátů. Přístup do pamětí certifikátů řídí produkt DCM pomocí hesel a také prostřednictvím řízení přístupu k adresáři integrovaného systému souborů a k souborům, které vytvářejí paměti certifikátů. Paměti certifikátů se dělí na základě toho, jaké typy certifikátů obsahují. Podle typu certifikátu, jenž pamě certifikátů obsahuje, se liší administrátorské úlohy, které lze pro danou pamě certifikátů provádět. Produkt DCM nabízí tyto předdefinované paměti certifikátů, které lze definovat a spravovat: Lokální vydavatel certifikátů (CA) Toto úložiště certifikátů produkt DCM používá k uložení lokálních certifikátů CA a přidružených soukromých klíčů. Lokální certifikát CA v tomto úložišti můžete použít k podepsání nebo vydání dalších vytvořených certifikátů. Když lokální CA vydá certifikát, produkt DCM pro účely ověření uloží kopii certifikátu CA (bez soukromého klíče) do příslušného úložiště certifikátů (např. *SYSTEM). Můžete vytvořit více než jednoho lokálního vydavatele certifikátu (CA). Když vytvoříte certifikát v jednom z ostatních úložiš certifikátů, vyberete, který CA jej podepíše. Může být užitečné vytvořit více CA. Například v případě, že chcete upgradovat na použití certifikátů algoritmu ECDSA, ale i nadále chcete vydávat certifikáty algoritmu RSA pro klienty, kteří ještě algoritmus ECDSA nepodporují. Aplikace používají certifikáty CA k tomu, aby ověřily původ certifikátu, jehož platnost musí potvrdit v rámci procesu SSL/TLS při poskytování oprávnění k prostředkům. DCM (Digital Certificate Manager) 7
14 *SYSTEM Produkt DCM poskytuje toto úložiště certifikátů pro správu certifikátů serveru nebo klienta, které aplikace používají při navazování komunikačních relací SSL/TLS. Aplikace IBM i (a aplikace mnohých dalších vývojářů softwaru) jsou naprogramovány tak, že používají pouze certifikáty v paměti certifikátů *SYSTEM. Když pomocí produktu DCM vytváříte lokálního CA, DCM tuto pamě certifikátů vytvoří v rámci tohoto procesu. Pokud se rozhodnete získávat certifikáty pro své serverové nebo klientské aplikace od veřejného CA, jako je např. VeriSign, musíte tuto pamě certifikátů vytvořit. *OBJECTSIGNING Produkt DCM používá tuto pamě certifikátů při správě certifikátů, které se používají k digitálnímu podepisování objektů. Úlohy v této paměti certifikátů vám umožní vytvářet digitální podpisy na objektech a rovněž podpisy zobrazovat a ověřovat. Když pomocí produktu DCM vytváříte lokálního CA, DCM tuto pamě certifikátů vytvoří v rámci tohoto procesu. Pokud se rozhodnete získávat certifikáty pro podepisování objektů od veřejného CA, jako je např. VeriSign, musíte tuto pamě certifikátů vytvořit. *SIGNATUREVERIFICATION Produkt DCM používá tuto pamě certifikátů při správě certifikátů, které se používají k ověření digitálního podpisu na objektech. Chcete-li ověřit digitální podpis, musí tato pamě certifikátů obsahovat kopii certifikátu, kterým je objekt podepsaný. Pamě certifikátů musí také obsahovat kopii certifikátu CA pro toho CA, který vydal certifikát pro podepisování objektů. Tyto certifikáty získáte bu pomocí exportu certifikátů pro podepisování objektů v aktuálním systému do této paměti, nebo pomocí importu certifikátů, které získáte od podepisovatele objektu. Jiná systémová pamě certifikátů Tato pamě certifikátů představuje alternativní místo uložení serverových a klientských certifikátů, které používáte pro relace SSL/TLS. Jiné systémové paměti certifikátů jsou uživatelsky definované sekundární paměti certifikátů pro certifikáty SSL/TLS. Volba Jiné úložiště certifikátů systému umožňuje spravovat certifikáty pro aplikace, které zapíšete vy nebo jiní, které používají rozhraní API gsk_environment_init k programovému přístupu a použití certifikátu pro zavedení spojení s relací SSL/TLS. Díky tomuto rozhraní API může aplikace používat předvolený certifikát pro určitou pamě certifikátů namísto certifikátu, který konkrétně určíte. Nejčastěji se tato pamě certifikátů používá při migraci certifikátů z dřívějšího vydání produktu DCM nebo tehdy, když je potřeba vytvořit zvláštní podmnožinu certifikátů určených pro použití v SSL/TLS. Poznámka: Jestliže máte ve vašem systému nainstalován produkt IBM Cryptographic Coprocessor, můžete si vybrat jiné volby pro uložení soukromého klíče vašich certifikátů (s výjimkou certifikátů pro podepisování objektů). Můžete se rozhodnout, že soukromý klíč uložíte v koprocesoru samotném, nebo můžete pomocí něj zašifrovat soukromý klíč a ten uložit ve zvláštním souboru klíčů namísto v paměti certifikátů. Produkt DCM řídí přístup k pamětem certifikátů prostřednictvím hesel. Produkt DCM rovněž zajiš uje řízení přístupu k adresáři integrovaného systému souborů a k souborům, které vytvářejí paměti certifikátů. Paměti certifikátů typu Lokální vydavatel certifikátů (CA), *SYSTEM, *OBJECTSIGNING a *SIGNATUREVERIFICATION musí být umístěny ve specifických cestách v rámci integrovaného systému souborů. Jiné systémové paměti certifikátů mohou být umístěny kdekoliv v integrovaném systému souborů. Související pojmy: Typy digitálních certifikátů na stránce 33 Pokud ke správě certifikátů používáte produkt DCM, pak produkt DCM organizuje a ukládá certifikáty a jejich přiřazené soukromé klíče do paměti certifikátů podle typu certifikátu. Šifrování Sdílený a veřejný klíč jsou dva různé typy kryptografických funkcí, které digitální certifikáty používají pro poskytnutí zabezpečení. Kryptografie (šifrování) je věda o zabezpečení dat. Šifrování vám umožňuje ukládat informace nebo komunikovat s jinými stranami tak, že přitom zabraňuje nezúčastněným stranám, aby uloženým informacím nebo komunikaci 8 IBM i: DCM (Digital Certificate Manager)
15 porozuměly. Šifrování převádí srozumitelný text do nesrozumitelných dat (šifrovaný text). Dešifrování vytváří z nečitelných dat opět srozumitelný text. Oba procesy zahrnují matematickou formuli či algoritmus a tajnou sekvenci dat (klíč). Existují dva typy šifrování: v V šifrování se sdíleným nebo tajným klíčem (symetrické) je jeden klíč sdíleným tajemstvím mezi dvěma komunikujícími stranami. Šifrování a dešifrování používá stejný klíč. v V šifrování s veřejným klíčem (asymetrické šifrování) jsou klíče generovány ve dvojicích, přičemž každý z nich je šifrovacím opakem druhého. Jeden klíč se používá při podepisování a druhý při ověřování. Pokud v případě algoritmu RSA jeden klíč slouží k šifrování, lze data dešifrovat jen pomocí druhého klíče. Jedna strana má dvojici klíčů, která se skládá z veřejného a soukromého klíče. Veřejný klíč se distribuuje volně, obvykle jako součást digitálního certifikátu, zatímco soukromý klíč si jeho vlastník udržuje v tajnosti. Tyto dva klíče jsou matematicky příbuzné, ale je prakticky nemožné odvodit soukromý klíč od veřejného klíče. Objekt, např. zpráva, který je zašifrován pomocí něčího veřejného klíče algoritmu RSA, lze dešifrovat pouze pomocí přiřazeného soukromého klíče algoritmu RSA. Alternativně může server nebo uživatel pomocí soukromého klíče podepsat objekt a příjemce pak použije odpovídající veřejný klíč k ověření digitálního podpisu, čímž ověří zdroj a integritu objektu. Související pojmy: Digitální podpisy na stránce 4 Digitální podpis na elektronickém dokumentu nebo jiném objektu je vytvořen za použití určité formy šifrování a je ekvivalentem osobního podpisu na psaném dokumentu. IBM Cryptographic Coprocessors for IBM i Produkt Cryptographic Coprocessor poskytuje ověřené šifrovací služby, které zajiš ují soukromí a integritu pro vznikající aplikace e-businessu. Použití produktu IBM Cryptographic Coprocessor pro platformu IBM i umožní vašemu systému používat vysoce zabezpečené šifrování. Jestliže máte ve svém systému nainstalovaný a logicky zapnutý šifrovací koprocesor, můžete jej používat pro bezpečnější ukládání soukromých klíčů vašich certifikátů. Poznámka: Šifrovací koprocesor nelze použít ke generování certifikátů ECDSA. Produkt Cryptographic Coprocessor můžete využít k uložení soukromého klíče certifikátu pro server, certifikátu pro klienta nebo certifikátu lokálního vydavatele certifikátu. Šifrovací koprocesor však nelze použít pro uložení soukromého klíče uživatelského certifikátu, nebo tento klíč musí být uložen v systému uživatele. V současné době také nelze pomocí koprocesoru uložit soukromý klíč certifikátu pro podepisování objektů. Soukromý klíč certifikátu můžete bu přímo uložit do šifrovacího koprocesoru, nebo můžete využít hlavní klíč šifrovacího koprocesoru k zašifrování klíče, a ten pak uložit ve speciálním souboru klíčů. Tyto volby uložení klíče pomocí koprocesoru lze vybrat v rámci procesu vytváření nebo obnovy certifikátu. Jestliže pomocí koprocesoru ukládáte soukromý klíč certifikátu, můžete také změnit přiřazení koprocesorového zařízení pro tento klíč. Chcete-li používat šifrovací koprocesor k uložení soukromých klíčů, musíte zajistit, aby byl koprocesor předtím, než začnete pracovat s produktem Digital Certificate Manager (DCM), logicky zapnutý. Jinak by totiž produkt DCM v rámci procesu vytváření nebo obnovy certifikátu vůbec možnost volby místa uložení klíčů neposkytl. Související pojmy: Uložení klíčů certifikátů do produktu IBM Cryptographic Coprocessor na stránce 72 Pokud máte v systému nainstalován produkt IBM Cryptographic Coprocessor, můžete tento koprocesor použít k zajištění bezpečnějšího uložení soukromých klíčů certifikátů. Do koprocesoru lze uložit soukromý klíč serverového certifikátu, klientského certifikátu nebo certifikátu lokálního vydavatele certifikátů (CA). Definice aplikace Produkt Digital Certificate Manager (DCM) vám umožňuje spravovat definice aplikací, které budou pracovat s konfiguracemi SSL/TLS a podepisováním objektů. DCM (Digital Certificate Manager) 9
16 Existují dva typy definic aplikací, které lze v produktu DCM spravovat: v Definice aplikací typu klient nebo server, které používají komunikační relace SSL (Secure Socket Layer)/TLS (Transport Layer Security). v Definice aplikací pro podepisování objektů, které podepisují objekty k zajištění jejich integrity. Chcete-li v produktu DCM pracovat s definicemi aplikací pro SSL/TLS a jejich certifikáty, musí být aplikace nejdříve v produktu DCM zaregistrována jako definice aplikace tak, aby měla jedinečné ID aplikace. Vývojáři aplikací provádějí registraci aplikací využívajících SSL/TLS pomocí rozhraní API (QSYRGAP, QsyRegisterAppForCertUse), takže ID aplikace se v produktu DCM vytvoří automaticky. Většina aplikací IBM i využívajících SSL/TLS je registrována s produktem DCM, takže k nim můžete pomocí produktu DCM snadno přiřadit certifikát a aplikace pak mohou ustanovit spojení s relací SSL/TLS. Pro aplikace, které naprogramujete nebo zakoupíte, můžete definovat definici aplikace a vytvořit pro ni ID aplikace v rámci samotného produktu DCM. Chcete-li definici aplikace pro SSL/TLS vytvořit pro klientskou nebo serverovou aplikaci, musíte pracovat v paměti certifikátů *SYSTEM. Klientské nebo serverové aplikaci můžete přiřadit až čtyři certifikáty. Přiřadíte-li více než jeden certifikát, určí systém, který z nich má použít, během vytváření relace SSL/TLS. Zvolený certifikát vychází z informací protokolu vyjednaných s uzlem typu peer. Další informace o tom, jak systém zpracovává více certifikátů přiřazených k aplikaci, najdete v tématu Výběr více certifikátů. Aplikace mají několik nastavení, která může systém použít při ustanovení relace SSL/TLS, jako např. protokoly, volby specifikace šifrovací sady, kritický režim rozšířeného opětovného vyjednávání, SNI (Serve Name Indication) a podpisový algoritmus. Další informace o těchto nastaveních najdete v tématu Definice aplikací DCM. Chcete-li pomocí nějakého certifikátu podepisovat objekty, musíte nejprve nadefinovat aplikaci, kterou bude certifikát používat. Na rozdíl od definice aplikace v rámci SSL/TLS nepopisuje aplikace pro podepisování objektů žádnou skutečnou aplikaci. Definice aplikace, kterou vytvoříte, může namísto toho popisovat typ nebo skupinu objektů, které hodláte podepisovat. Při vytváření definice aplikace pro podepisování objektů musíte pracovat v paměti certifikátů *OBJECTSIGNING. Pomocí dalšího nastavení aplikace Definovat seznam důvěryhodných CA lze určit, zda aplikace odkazuje na určitý seznam důvěryhodných CA, nebo zda důvěřuje všem CA se stavem Povoleno v úložišti certifikátů *SYSTEM. Je-li toto nastavení nastaveno na hodnotu Ano, umožňuje aplikaci úžeji definovat certifikáty vydavatelů certifikátů (CA), kterým důvěřuje, ze seznamu povolených certifikátů vydavatelů certifikátů v úložišti certifikátů *SYSTEM. Pokud zvolíte tuto hodnotu, aplikace bude důvěřovat všem certifikátům vydavatelů certifikátů, dokud pro tuto aplikaci nedefinujete seznam důvěryhodných vydavatelů certifikátů. Jinak řečeno, prázdný seznam důvěryhodných vydavatelů certifikátů se chová stejně, jako když v tomto nastavení vyberete hodnotu Ne. Pokud pro toto nastavení nastavíte hodnotu Ne, důvěřuje aplikace všem certifikátům vydavatelů certifikátů povoleným pro úložiště certifikátů *SYSTEM. Související pojmy: Správa aplikací v produktu DCM na stránce 66 Produkt DCM vám umožňuje vytvářet definice aplikací a spravovat přiřazení certifikátů aplikacím. Můžete také definovat seznamy důvěryhodných CA, které aplikace používají jako základ pro schválení certifikátu při ověření klienta. Související úlohy: Vytvoření definice aplikace na stránce 66 Existují dva typy definic aplikací, se kterými lze v produktu DCM pracovat: definice aplikací pro serverové nebo klientské aplikace, které používají SSL, a definice aplikací, které používáte při podepisování objektů. Ověření platnosti Produkt DCM poskytuje úlohy, prostřednictvím kterých lze potvrdit platnost certifikátu nebo aplikace a ověřit tak různé vlastnosti, které musí mít. 10 IBM i: DCM (Digital Certificate Manager)
17 Ověření platnosti certifikátu Když potvrzujete certifikát, produkt DCM (Digital Certificate Manager) ověřuje řadu položek týkajících se certifikátu, aby zajistil autenticitu a platnost certifikátu. Potvrzováním certifikátu se zajistí, že aplikace, které používají certifikát k zabezpečené komunikaci nebo k podepisování objektů, pravděpodobně nenarazí při použití certifikátů na nějaké problémy. Jako součást procesu potvrzení produkt DCM kontroluje, zda vybranému certifikátu nevypršela platnost. Produkt DCM také kontroluje, zda certifikát není uveden v seznamu odvolaných certifikátů (CRL) jako odvolaný, pokud pro CA, který certifikát vydal, existuje umístění CRL. Pokud nakonfigurujete mapování protokolu LDAP pro použití CRL, produkt DCM kontroluje CRL při ověřování platnosti certifikátu, aby se ujistil, že certifikát není evidovaný v CRL. Aby však proces ověření platnosti důkladně prověřil CRL, server adresářů (LDAP), nakonfigurovaný pro mapování LDAP, musí obsahovat odpovídající CRL. V opačném případě nebude certifikát správně ověřen. Musíte poskytnout DN a heslo, abyste se vyvarovali ověření certifikátu s odvolaným stavem. Také v případě, že při konfiguraci mapování LDAP neuvedete DN a heslo, budete anonymně spojeni se serverem LDAP. Anonymní připojení k serveru LDAP neposkytuje úroveň oprávnění potřebnou pro přístup ke kritickým atributům a CRL je kritickým atributem. V takovém případě může produkt DCM potvrdit odvolaný certifikát, protože není schopen získat správný stav z CRL. Pokud potřebujete anonymní přístup k serveru LDAP, pak musíte použít nástroj Directory Server Web Administration Tool a vybrat úlohu "Správa schématu" za účelem změny třídy zabezpečení (která je nazývána rovněž jako "přístupová třída") u atributů certificaterevocationlist a authorityrevocationlist z hodnoty "kritický" na hodnotu "normální". Produkt DCM také kontroluje, zda certifikát CA pro vydávajícího CA je v aktuální paměti certifikátů a zda je certifikát CA označen jako důvěryhodný. Jestliže má certifikát soukromý klíč (např. serverový certifikát, klientský certifikát nebo certifikát pro podepisování objektů), pak produkt DCM také prověřuje dvojici veřejného a soukromého klíče, aby zajistil, že si dvojice veřejného a soukromého klíče odpovídá. Jinými slovy, produkt DCM zašifruje data pomocí veřejného klíče a zajistí, aby je bylo možné dešifrovat pomocí soukromého klíče. Ověření platnosti aplikace Když potvrzujete určitou aplikaci, produkt DCM ověřuje, že pro tuto aplikaci existuje přiřazení certifikátu, a zjiš uje, zda je přiřazený certifikát platný. Produkt DCM dále zjiš uje, zda v případě, že je aplikace konfigurována pro použití seznamu důvěryhodných CA, obsahuje tento seznam alespoň jeden certifikát CA. Produkt DCM pak ověřuje, zda certifikáty CA v seznamu důvěryhodných CA pro danou aplikaci jsou platné. Pokud definice aplikace uvádí, že se má provádět zpracování seznamu odvolaných certifikátů (CRL), a je definováno umístění CRL pro daného CA, pak produkt DCM v rámci ověřovacího procesu kontroluje i CRL. Ověření platnosti aplikace vás pomůže upozornit na některé možné problémy, které aplikace může mít při provádění funkcí vyžadujících certifikát. Tyto problémy mohou u aplikace způsobit, že se nebude moci úspěšně účastnit relace SSL (Secure Sockets Layer) nebo nebude moci úspěšně podepisovat objekty. Související pojmy: Potvrzování certifikátů a aplikací na stránce 70 Pomocí produktu DCM (Digital Certificate Manager) můžete potvrzovat jednotlivé certifikáty nebo aplikace, které je používají. Seznam věcí, které produkt DCM kontroluje, se mírně liší podle toho, zda se potvrzuje certifikát nebo aplikace. Scénáře: DCM Tyto scénáře popisují typická schémata implementace certifikátů, která vám mohou pomoci při plánování vaší vlastní implementace certifikátů jako součásti celkové strategie zabezpečení serveru IBM i. U každého scénáře jsou rovněž uvedeny všechny potřebné konfigurační úlohy, které musíte provést, aby bylo možno scénář použít tak, jak je popsáno. DCM (Digital Certificate Manager) 11
18 Produkt DCM vám umožňuje použít certifikáty za účelem zdokonalení vaší strategie zabezpečení řadou různých způsobů. To, jakou variantu použití certifikátů zvolíte, bude záviset jak na vašich obchodních cílech, tak na potřebách v oblasti zabezpečení. Použití digitálních certifikátů vám napomůže posílit zabezpečení vašeho systému v mnoha směrech. Digitální certifikáty vám umožní použít SSL (Secure Sockets Layer) pro zabezpečený přístup na webové stránky a k dalším internetovým službám. Digitální certifikáty můžete použít pro konfiguraci připojení VPN (Virtual Private Network). Klíč k certifikátu můžete také použít k digitálnímu podepisování objektů nebo k ověření digitálních podpisů a zajištění autenticity objektů. Tyto digitální podpisy zajiš ují spolehlivost původu daného objektu a chrání integritu objektu. Zvýšit zabezpečení systému můžete také tím, že digitální certifikáty použijete při ověření a autorizaci relací mezi serverem a uživateli (namísto uživatelských jmen a hesel). Produkt DCM můžete podle toho, jak jej nakonfigurujete, použít dále pro přiřazení uživatelského certifikátu k jeho uživatelskému profilu na serveru IBM i nebo k identifikátoru EIM. Certifikát má pak stejná oprávnění a povolení jako přiřazený uživatelský profil. Z uvedeného je zřejmé, že systém, jakým budete certifikáty používat, může být složitý a bude záviset na řadě faktorů. Scénáře použití certifikátů popsané v této části, vycházejí z několika nejběžnějších bezpečnostních důvodů použití digitálních certifikátů pro zabezpečenou komunikaci v rámci typického podnikového prostředí. V každém scénáři jsou rovněž popsány všechny nezbytné systémové a softwarové předpoklady a všechny konfigurační úlohy, které musíte provést při implementaci daného scénáře. Související informace: Scénáře podepisování objektů Scénář: Použití certifikátů pro externí ověření V tomto scénáři je popsáno, kdy a jak použít certifikáty jako prostředek ověření, chcete-li chránit a omezovat přístup veřejných uživatelů k veřejným nebo extranetovým prostředkům a aplikacím. Situace Představte si, že pracujete v pojiš ovací společnosti MyCo., Inc a máte na starosti údržbu různých aplikací v rámci intranetu a extranetu vaší společnosti. Jednou z aplikací, za které jste zodpovědní, je aplikace pro výpočet pojistných sazeb, kterou používají nezávislí pojiš ovací agenti vaší společnosti při vytváření cenových nabídek pro klienty. Protože informace, které tato aplikace poskytuje, jsou poněkud citlivé, chcete zajistit, aby aplikaci mohli používat pouze registrovaní agenti. Chcete také uživatelům časem poskytnout bezpečnější metodu uživatelského ověření k aplikaci, než je vaše současná metoda využívající uživatelská jména a hesla. Obáváte se, že by neautorizovaní uživatelé mohli tuto informaci zachytit při jejím přenosu přes nedůvěryhodnou sí. Také se obáváte, že někteří pojiš ovací agenti by tuto informaci mohli sdělit jiným osobám, které autorizaci nemají. Když si zjistíte, jaké jsou v této oblasti možnosti, rozhodnete se, že vašim potřebám bude nejlépe vyhovovat použití digitálních certifikátů, které ochrání citlivé informace zadané do aplikace a načtené z aplikace. Použití certifikátů umožňuje použít SSL/TLS pro ochranu dat při jejich přenosu. Plánujete, že v konečné fázi budou všichni agenti používat pro přístup k aplikaci certifikát, ale víte, že než tohoto cíle dosáhnete, bude váš podnik i externí agenti potřebovat jistý čas. Kromě použití certifikátů pro ověření klientů máte v úmyslu stále používat současná uživatelská jména a hesla, protože SSL/TLS poskytuje citlivým datům při přenosu dostatečnou ochranu. Na základě typu aplikace a jejích uživatelů a na základě vašeho budoucího cíle ověření všech uživatelů pomocí certifikátů se rozhodnete při konfiguraci SSL/TLS u vaší aplikace použít veřejný certifikát od některého dobře známého vydavatele certifikátů. Výhody scénáře Tento scénář má následující výhody: v Použitím digitálních certifikátů pro konfiguraci SSL/TLS přístupu k aplikaci sloužící k výpočtu pojistných sazeb zajistíte, že informace přenášené mezi serverem a klientem budou chráněné a soukromé. 12 IBM i: DCM (Digital Certificate Manager)
19 v Použitím digitálních certifikátů pro ověření klientů, v co největší míře to bude možné, poskytnete autorizovaným uživatelům bezpečnější metodu identifikace. Dokonce i tehdy, kdy použití digitálních certifikátů nebude možné, ověření na základě uživatelského jména a hesla bude díky relaci SSL/TLS chráněna a zachována soukromá, takže výměna těchto citlivých dat bude bezpečnější. v Použití veřejných digitálních certifikátů k ověření uživatelů pro přístup k vašim aplikacím a datům způsobem, který popisuje tento scénář, bude praktickou volbou za těchto nebo podobných podmínek: Vaše data a aplikace vyžadují různou míru zabezpečení. Vaši důvěryhodní uživatelé se často střídají. Poskytujete veřejný přístup k aplikacím a datům, jako jsou např. webové stránky na Internetu nebo extranetové aplikace. Nechcete provozovat vlastního vydavatele certifikátů z administračních důvodů, jako je například velký počet externích uživatelů, kteří přistupují k vašim aplikacím a prostředkům. v Použijete-li ke konfiguraci SSL/TLS u aplikace pro výpočet pojistných sazeb veřejný certifikát, snížíte rozsah konfigurace, kterou budou muset uživatelé provádět při přístupu k dané aplikaci zabezpečeným způsobem. Klientský software většinou obsahuje certifikáty CA pro většinu známých vydavatelů certifikátu. Úkoly V tomto scénáři chce společnost MyCo, Inc. pomocí digitálních certifikátů zajistit ochranu informací, které jejich aplikace pro výpočet pojistných sazeb poskytuje autorizovaným veřejným uživatelům. Společnost chce také bezpečnější metodu ověření těch uživatelů, kteří mají k aplikaci oprávněný přístup. Cíle tohoto scénáře jsou následující: v Veřejná aplikace pro výpočet pojistných sazeb musí používat SSL/TLS, aby byla zajištěna ochrana a soukromost dat, které aplikace uživatelům poskytuje a které od nich získává. v Konfigurace SSL/TLS musí být provedena pomocí veřejného certifikátu od známého veřejného internetového vydavatele certifikátů. v Autorizovaní uživatelé musí zadat platné uživatelské jméno a heslo, aby mohli přistupovat k aplikaci v režimu SSL/TLS. V konečné fázi musí být autorizovaní uživatelé schopni používat jednu ze dvou metod zabezpečené ověření, aby jim byl poskytnut přístup k aplikaci. Externí agenti musí předložit bu veřejný digitální certifikát od známého vydavatele certifikátů, nebo platné uživatelské jméno a heslo, pokud není k dispozici certifikát. DCM (Digital Certificate Manager) 13
20 Podrobnosti Na obrázku je znázorněno schéma konfigurace sítě podle uvedeného scénáře: Z obrázku vyplývají tyto informace o situaci popisované ve scénáři: Podnikový veřejný server System A v System A je hostitelský systém podnikové aplikace pro výpočet pojistných sazeb. v System A spustí podporovanou verzi produktu IBM i. v Na serveru System A je nainstalovaný a nakonfigurovaný produkt DCM (Digital Certificate Manager) a produkt IBM HTTP Server for i. v Na serveru System A běží aplikace pro výpočet pojistných sazeb, která je nakonfigurovaná následovně: Vyžaduje režim SSL/TLS. Pro svou ověření za účelem inicializace relace SSL/TLS používá veřejný certifikát od známého vydavatele certifikátů. Vyžaduje ověření uživatelů pomocí uživatelského jména a hesla. v Když se klienti B a C přihlašují k aplikaci pro výpočet pojistných sazeb, server System A předkládá svůj certifikát, aby zahájil relaci SSL/TLS. v Když se spustí relace SSL/TLS, server System A předtím, než povolí přístup k aplikaci pro výpočet pojistných sazeb, požaduje, aby klienti B a C předložili platné uživatelské jméno a heslo. Klientské systémy pojiš ovacích agentů klient B a klient C v Klienti B a C jsou nezávislí pojiš ovací agenti, kteří mají přístup k aplikaci pro výpočet pojistných sazeb. v Klienti B a C mají ve svém klientském softwaru nainstalovanou kopii certifikátu známého CA, který vydal certifikát aplikace. v Klienti B a C přistupují k aplikaci pro výpočet pojistných sazeb na serveru System A, který následně předkládá svůj certifikát jejich klientskému softwaru, aby autentizoval svoji identitu a inicializoval relaci SSL/TLS. v Klientský software na klientech B a C je nakonfigurován tak, aby byl schopen akceptovat certifikát ze serveru System A za účelem inicializace relace SSL/TLS. v Když se spustí relace SSL/TLS, musí klienti B a C zadat platné uživatelské jméno a heslo, a pak teprve server System A povolí přístup k aplikaci. 14 IBM i: DCM (Digital Certificate Manager)
21 Nezbytné podmínky a předpoklady Nezbytné podmínky a předpoklady pro realizaci uvedeného scénáře jsou tyto: v Aplikace pro výpočet pojistných sazeb na serveru System A je generická aplikace, která může být nakonfigurovaná pro použití SSL/TLS. Většina aplikací, včetně mnohých aplikací serveru IBM i, podporuje SSL/TLS. Postup při konfiguraci SSL/TLS se však u různých aplikací velmi liší. V tomto scénáři proto neuvádíme konkrétní pokyny, jak aplikaci pro výpočet pojistných sazeb nakonfigurovat pro použití SSL/TLS. Scénář poskytuje pokyny pro konfiguraci a správu certifikátů, které jsou nezbytné k tomu, aby aplikace mohla SSL/TLS používat. v Aplikace pro výpočet pojistných sazeb může zajiš ovat vyžadování certifikátů pro ověření klienta. Tento scénář poskytuje instrukce k tomu, jak pomocí produktu DCM nakonfigurovat ověřování certifikátů pro aplikace, které tuto podporu poskytují. Protože postupy při konfiguraci ověření klientů se u různých aplikací velmi liší, neposkytuje tento scénář konkrétní návod, jak konfigurovat ověření klientů formou certifikátů u této konkrétní aplikaci pro výpočet pojistných sazeb. v Server System A splňuje Požadavky pro nastavení produktu DCM na stránce 31 pro nainstalování a použití produktu DCM. v Na serveru System A doposud nikdo nekonfiguroval a nepoužíval produkt DCM. v Ten, kdo bude pracovat s produktem DCM při provedení úloh popsaných v tomto scénáři, musí mít ve svém uživatelském profilu zvláštní oprávnění *SECADM a *ALLOBJ. v Na serveru System A není nainstalován produkt IBM Cryptographic Coprocessor. Úlohy nastavení Související úlohy: Spuštění DCM na stránce 42 Předtím, než můžete používat funkce produktu DCM (Digital Certificate Manager), musíte tento produkt ve svém systému spustit. Vyplnění plánovacích formulářů Následující plánovací formulář zobrazuje informace, které je třeba shromáždit, a rozhodnutí, která je třeba učinit, abyste připravili implementaci digitálního certifikátu tak, jak to popisuje tento scénář. Chcete-li zajistit úspěšnou implementaci, je třeba, abyste před provedením všech konfiguračních úloh, byli schopni odpovědět na všechny položky otázek týkajících se nezbytných podmínek Ano. Tabulka 1. Plánovací formulář nezbytných podmínek při implementaci certifikátu Formulář nezbytných podmínek Je systém podporované verze IBM i? Máte v systému nainstalovaný produkt DCM (Digital Certificate Manager)? Je v systému nainstalován produkt IBM HTTP Server for i a je spuštěna administrační instance serveru? Je v systému nakonfigurován protokol TCP, abyste mohli pro přístup k produktu DCM používat webový prohlížeč a instanci administračního rozhraní HTTP serveru? Máte zvláštní oprávnění *SECADM a *ALLOBJ? Odpovědi Ano Ano Ano Ano Ano Abyste mohli dokončit implementaci, potřebujete shromáždit následující informace o implementaci digitálních certifikátů a následně provést potřebné úlohy konfigurace. Tabulka 2. Plánovací formulář konfigurace pro implementaci certifikátu Plánovací formulář pro server System A Budete provozovat vlastního lokálního CA nebo budete získávat certifikáty pro vaše aplikace od veřejného CA? Odpovědi Získávat certifikáty od veřejného CA DCM (Digital Certificate Manager) 15
22 Tabulka 2. Plánovací formulář konfigurace pro implementaci certifikátu (pokračování) Plánovací formulář pro server System A Hostuje Systém A aplikace, které chcete povolit pro SSL/TLS? Které informace o rozlišovacím jméně budete používat pro požadavky na podpis certifikátů (CSR), k jejichž vytváření používáte produkt DCM? v Velikost klíče: určuje sílu šifrovacích klíčů pro certifikát. v Algoritmus klíče: Vyberte algoritmus klíče pro generování veřejného a soukromého klíče pro certifikát. v Označení certifikátu: identifikuje certifikát prostřednictvím jedinečného řetězce znaků. v Obecné jméno: identifikuje vlastníka certifikátu, jako například osobu, entitu nebo aplikaci; součást DN (rozlišovacího jména) subjektu certifikátu. v Organizační jednotka: identifikuje organizační sekci nebo oblast pro aplikaci, která bude certifikát používat. v Jméno organizace: identifikuje vaši společnost nebo divizní sekci pro aplikaci, která bude tento certifikát využívat. v Lokalita nebo město: identifikuje vaše město nebo označení lokality vaší organizace. v Stát nebo oblast: identifikuje stát nebo oblast, ve které budete tento certifikát používat. v Země nebo region: identifikuje dvěma písmeny zemi nebo region, ve kterém budete certifikát používat. Jaké je ID aplikace DCM pro aplikaci, kterou chcete konfigurovat pro použití SSL/TLS? Budete konfigurovat aplikaci podporující SSL/TLS, aby používala pro ověření klientů certifikáty? Pokud ano, které CA chcete přidat do seznamu důvěryhodných CA aplikace? Odpovědi Ano Velikost klíče: 2048Algoritmus klíče: RSA nebo ECDSAOznačení certifikátu: Myco_public_certObecný název: myco_rate_server@myco.comorganizační jednotka: Rate deptnázev organizace: mycolokalita nebo město: Any_cityStát nebo oblast: AnyZemě nebo region: ZZ mcyo_agent_rate_app Ne Vytvoření požadavku na serverový nebo klientský certifikát 1. Spus te produkt DCM. Vyhledejte si informace v části Spuštění DCM. 2. V navigační liště produktu DCM vyberte volbu Vytvoření nové paměti certifikátů, čímž spustíte úlohu s průvodcem a zobrazí se série formulářů. Pomocí těchto formulářů budete provedeni procesem vytvoření paměti certifikátů a certifikátu, které vaše aplikace budou používat pro relace SSL/TLS. Poznámka: Jestliže máte dotazy k tomu, jak vyplnit určitý formulář v této vedené úloze, vyberte tlačítko otazník (?). Je umístěno v horní části stránky a slouží jako přístup k nápovědě online. 3. Vyberte *SYSTEM jako pamě certifikátů, kterou chcete vytvořit, a klepněte na tlačítko Pokračovat. 4. Vyberte Ano, abyste v rámci vytvoření paměti certifikátů *SYSTEM vytvořili i certifikát, a klepněte na tlačítko Pokračovat. 5. Vyberte VeriSign nebo jiného internetového vydavatele certifikátů (CA) jako toho, kdo bude podepisovat nové certifikáty, a klepněte na tlačítko Pokračovat, čímž se vám zobrazí formulář na vložení identifikačních informací pro nový certifikát. 6. Vyplňte formulář a klepněte na tlačítko Pokračovat. Zobrazí se potvrzující stránka. Tato potvrzující stránka zobrazuje údaje žádosti o certifikát, které musíte poskytnout veřejnému vydavateli certifikátů (CA), jenž bude certifikát vydávat. Data tohoto tzv. požadavku na podepisovací certifikát (Certificate Signing Request, CSR) zahrnují veřejný klíč, rozlišovací jméno a další informace, které jste uvedli pro nový certifikát. 7. Pečlivě zkopírujte a vložte data CSR do formuláře žádosti o certifikát nebo do zvláštního souboru, který veřejný CA požaduje při žádostech o certifikát. Musíte použít veškerá data CSR, včetně řádek Begin a End New Certificate Request. 16 IBM i: DCM (Digital Certificate Manager)
23 Poznámka: Jakmile tuto stránku opustíte, budou data ztracena a nebude možné je obnovit. 8. Než budete moci pokračovat, musíte počkat, až vám CA vrátí podepsaný dokončený certifikát. Když vám vydavatel certifikátů vrátí podepsaný dokončený certifikát, budete moci nakonfigurovat danou aplikaci pro SSL/TLS, provést import certifikátu do paměti certifikátů *SYSTEM a přiřadit jej k vaší aplikaci, aby jej používala při SSL/TLS. Konfigurace aplikací pro použití SSL Když obdržíte podepsaný certifikát od veřejného vydavatele certifikátů (CA), můžete pokračovat v procesu nastavení SSL komunikace u vaší veřejné aplikace. Aplikaci musíte nakonfigurovat pro použití SSL předtím, než začnete pracovat s podepsaným certifikátem. Některé aplikace, např. IBM HTTP Server for i, v rámci procesu konfigurace aplikace pro SSL vygenerují jedinečné ID aplikace a zaregistrují ho v produktu DCM. ID aplikace musíte znát předtím, než můžete pomocí produktu DCM přiřadit podepsaný certifikát k aplikaci a dokončit tak proces konfigurace SSL. Způsob konfigurace aplikace pro použití SSL se může měnit v závislosti na typu aplikace. V tomto scénáři nepředpokládáme nějakou konkrétní aplikaci pro výpočet pojistných sazeb, protože společnost MyCo., Inc. by mohla zvolit při poskytování těchto informací svým pojiš ovacím agentům řadu způsobů. Při konfigurování SSL u aplikace postupujte podle pokynů uvedených v dokumentaci k dané aplikaci. Po dokončení konfigurace SSL vaší aplikace můžete pro aplikaci konfigurovat podepsaný veřejný certifikát, aby mohl inicioval relace SSL. Související informace: Bezpečnost aplikací s využitím SSL Importování a přiřazení podepsaného veřejného certifikátu Jestliže jste nakonfigurovali aplikaci pro použití SSL/TLS, můžete nyní pomocí produktu DCM provést import certifikátu a přiřadit jej k dané aplikaci. Dále je uveden postup importu certifikátu a jeho přiřazení k aplikaci, jimiž dokončíte proces konfigurace SSL/TLS: 1. Spus te produkt DCM. Vyhledejte si informace v části Spuštění DCM. 2. V navigační liště klepněte na tlačítko Výběr paměti certifikátů a jako pamě certifikátů, kterou chcete otevřít, vyberte *SYSTEM. 3. Když se zobrazí stránka Pamě certifikátů a heslo, zadejte heslo, které jste pro danou pamě certifikátů uvedli, když jste ji vytvářeli, a klepněte na tlačítko Pokračovat. 4. Čekejte na obnovu navigačního rámce. 5. Pokud kořenový certifikát CA, který je přidružen k podepsanému certifikátu, není v úložišti certifikátů, vyberte volbu Spravovat úložiště certifikátů a vyberte volbu Naplnit certifikáty CA pro přidání kořenového certifikátu CA, který je přidružen k podepsanému certifikátu. 6. Vyberte volbu Spravovat certifikáty k zobrazení seznamu úloh. 7. Ze seznamu úloh vyberte volbu Import certifikátů, čímž zahájíte proces importu podepsaného certifikátu do paměti certifikátů *SYSTEM. Poznámka: Jestliže máte dotazy k tomu, jak vyplnit určitý formulář v této vedené úloze, vyberte tlačítko otazník (?). Je umístěno v horní části stránky a slouží jako přístup k nápovědě online. 8. Dále vyberte volbu Přiřazení certifikátu ze seznamu úloh Správa certifikátů. Zobrazí se seznam certifikátů pro aktuální pamě certifikátů. 9. Vyberte ze seznamu váš certifikát a klepněte na položku Přiřazení k aplikacím. Zobrazí se seznam definic aplikací pro aktuální pamě certifikátů. 10. Vyberte ze seznamu vaši aplikaci a klepněte na tlačítko Pokračovat. Zobrazí se stránka bu se zprávou potvrzující zvolené přiřazení, nebo s chybovou zprávou v případě nějakého problému. Pokud jste provedli výše uvedené úlohy, můžete spustit aplikaci v režimu SSL/TLS a zajistit tak ochranu soukromosti dat, které aplikace poskytuje. DCM (Digital Certificate Manager) 17
24 Spuštění aplikací v režimu SSL Jestliže jste provedli import a přiřazení certifikátu k dané aplikaci, bude možná nutno aplikaci ukončit a restartovat ji v režimu SSL. V některých případech je to nezbytné, protože aplikace nemusí být schopna za provozu identifikovat, že existuje přiřazení certifikátu. V dokumentaci k aplikaci zjistíte, zda je nutno aplikaci restartovat, případně další konkrétní informace o spuštění aplikace v režimu SSL. Pokud chcete používat certifikáty pro ověřování klientů a pokud chcete, aby aplikace úžeji definovala certifikáty CA ze seznamu povolených certifikátů CA v úložišti *SYSTEM, kterým důvěřuje, můžete nyní definovat seznam důvěryhodných CA a z úložiště *SYSTEM vybrat CA, kterým má aplikace důvěřovat. (Volitelné): Definování seznamu důvěryhodných CA pro aplikaci Aplikace, které podporují použití certifikátů při ověření klientů během relace SSL/TLS, musí určovat, zda přijmout určitý certifikát jako platný průkaz totožnosti. Jedním z kritérií, které aplikace používá k ověření certifikátu, je to, zda aplikace důvěřuje vydavateli certifikátů (CA), který certifikát vydal. Situace, kterou popisuje tento scénář, nevyžaduje, aby aplikace pro výpočet pojistných sazeb používala při ověření klientů certifikáty, ale aby byla tato aplikace schopna přijímat certifikáty za účelem ověření, pokud jsou tyto dostupné. Mnoho aplikací poskytuje podporu pro ověření klientů na základě certifikátů. Způsob konfigurace této podpory se však u jednotlivých aplikací velmi liší. Tuto volitelnou úlohu zde uvádíme pro lepší pochopení způsobu, jak lze pomocí produktu DCM vytvořit seznam důvěryhodných CA, který pak bude základem pro konfiguraci ověření klientů na základě certifikátů u vašich aplikací. Předtím, než můžete definovat seznam důvěryhodných CA pro určitou aplikaci, musí být splněno několik podmínek: v Aplikace musí podporovat použití certifikátů při ověření klientů. v V definici této aplikace v produktu DCM musí být specifikováno, že aplikace používá seznam důvěryhodných CA. Jestliže definice aplikace udává, že aplikace pomocí seznamu důvěryhodných CA omezuje seznam certifikátů CA, kterým důvěřuje, musíte tento seznam definovat před tím, než bude aplikace moci úspěšně provádět ověření klientů na základě certifikátů. Tím zajistíte, že aplikace bude potvrzovat pouze certifikáty těch CA, které v seznamu uvedete jako důvěryhodné. Pokud uživatelé nebo klientská aplikace předloží certifikát od kořenového nebo přechodného CA, který není uveden jako důvěryhodný v seznamu důvěryhodných CA, aplikace certifikát nepřijme za základ platné ověření. Chcete-li pomocí produktu DCM definovat pro aplikaci seznam důvěryhodných CA, postupujte následovně: 1. Spus te produkt DCM. Vyhledejte si informace v části Spuštění DCM. 2. V navigační liště klepněte na tlačítko Výběr paměti certifikátů a jako pamě certifikátů, kterou chcete otevřít, vyberte *SYSTEM. 3. Když se zobrazí stránka Pamě certifikátů a heslo, zadejte heslo, které jste pro danou pamě certifikátů uvedli, když jste ji vytvářeli, a klepněte na tlačítko Pokračovat. 4. Když se obnoví navigační lišta, vyberte volbu Správa certifikátů. Zobrazí se seznam úloh. 5. Ze seznamu úloh vyberte Nastavit stav CA. Zobrazí se seznam certifikátů CA. Poznámka: Jestliže máte dotazy k tomu, jak vyplnit určitý formulář v této vedené úloze, vyberte tlačítko otazník (?). Je umístěno v horní části stránky a slouží jako přístup k nápovědě online. 6. Vyberte ze seznamu jeden nebo více certifikátů CA, kterým aplikace bude důvěřovat, a klepněte na tlačítko Povolit. Zobrazí se seznam aplikací, které používají seznam důvěryhodných CA. 7. Vyberte ze seznamu aplikaci, pro kterou chcete do seznamu důvěryhodných CA doplnit vybraného CA, a klepněte na tlačítko OK. V horní části stránky se zobrazí zpráva, která informuje, že aplikace, kterou jste vybrali, bude důvěřovat danému CA a certifikátům, které CA vydá. Nyní můžete nakonfigurovat aplikaci tak, aby při ověření klientů požadovala certifikáty. Postupujte přitom podle pokynů, které uvádí dokumentace k dané aplikaci. 18 IBM i: DCM (Digital Certificate Manager)
25 Scénář: Použití certifikátů pro interní ověření V tomto scénáři se naučíte, jak použít certifikáty jako prostředek ověření, chcete-li chránit prostředky a aplikace na interních serverech a omezit v tomto smyslu přístupy interních uživatelů. Situace Jste správcem sítě ve společnosti (MyCo, Inc.), jejíž personální oddělení řeší problémy právních otázek a soukromosti osobních záznamů. Zaměstnanci podniku požadovali, aby měli online přístup k informacím o svých platech, dávkách na zdravotní pojištění apod. Společnost reagovala na tento požadavek tak, že vytvořila webové stránky, kde jsou tyto informace zaměstnancům k dispozici. Jste zodpovědný za správu těchto interních webových stránek, které jsou provozovány na serveru IBM HTTP Server for i (provozovaném na základě technologie Apache). Protože se zaměstnanci nacházejí na dvou různých pracovištích a někteří zaměstnanci často cestují, musíte zajistit, aby se zachovala soukromost informací při jejich přenosu po Internetu. Také tradičně používáte proces ověření uživatelů prostřednictvím uživatelského jména a hesla, abyste omezili přístup k datům společnosti. Vzhledem k citlivosti a soukromosti těchto informací si však uvědomujete, že omezení přístupu k informacím na základě hesla nemusí být dostačující. Přece jen hesla mohou lidé někomu říci, mohou je zapomenout, heslo někdo dokonce může ukrást. Když si zjistíte, jaké jsou v této oblasti možnosti, rozhodnete se, že vašim potřebám bude nejlépe vyhovovat použití digitálních certifikátů. Certifikáty vám umožní používat SSL/TLS pro ochranu dat při jejich přenosu. Navíc můžete používat certifikáty namísto hesel, čímž docílíte vyšší bezpečnosti ověření uživatelů a budete moci omezit personální informace, ke kterým bude mít daný uživatel přístup. Proto se rozhodnete vytvořit soukromého lokálního CA, vydávat certifikáty všem zaměstnancům a přiřazovat certifikáty zaměstnanců k jejich uživatelským profilům na serveru IBM i. Tento typ implementace soukromých certifikátů vám umožní účinněji řídit přístup k citlivým datům a také zajistit soukromost dat pomocí SSL/TLS. Tím, že budete certifikáty vydávat sami, konečně také zvyšujete pravděpodobnost, že vaše data zůstanou bezpečná a že budou přístupná pouze určitým jedincům. Výhody scénáře Tento scénář má následující výhody: v Použitím digitálních certifikátů pro konfiguraci SSL/TLS přístupu na váš webový server s personálními informacemi zajistíte, že informace přenášené mezi serverem a klientem budou chráněné a soukromé. v Použitím digitálních certifikátů při ověření klientů poskytnete autorizovaným uživatelům bezpečnější metodu identifikace. v Použití soukromých digitálních certifikátů za účelem ověření uživatelů pro přístup k vašim aplikacím a datům bude praktickou volbou za těchto nebo podobných podmínek: Požadujete vysokou míru zabezpečení, zejména co se týče ověření uživatelů. Důvěřujete osobám, kterým budete certifikáty vydávat. Vaši uživatelé již mají uživatelské profily na serveru IBM i za účelem řízení jejich přístupu k aplikacím a datům. Chcete provozovat vlastního vydavatele certifikátů (CA). v Použijete-li k ověření klientů soukromé certifikáty, budete moci snadněji přiřazovat certifikát k autorizovanému uživatelskému profilu na serveru IBM i. Přiřazení certifikátu k uživatelskému profilu umožňuje, aby HTTP server během ověření určil uživatelský profil vlastníka certifikátu. HTTP server pak může na tento profil přejít a pracovat pod tímto uživatelským profilem nebo pro daného uživatele provádět operace na základě informací v uživatelském profilu. Úkoly V tomto scénáři chce společnost MyCo, Inc. pomocí digitálních certifikátů zajistit ochranu personálních informací, které jejich interní webové stránky poskytují podnikovým zaměstnancům. Společnost chce také bezpečnější metodu ověření těch uživatelů, kteří mají k těmto webovým stránkám oprávněný přístup. DCM (Digital Certificate Manager) 19
26 Cíle tohoto scénáře jsou následující: v Interní podnikové webové stránky s personálními informacemi musí používat SSL/TLS, aby se zajistila ochrana a soukromost dat poskytovaných uživatelům. v Konfigurace SSL/TLS musí být provedena pomocí soukromých certifikátů od interního lokálního vydavatele certifikátů (CA). v Autorizovaní uživatelé, kteří chtějí přistupovat na webové stránky v režimu SSL/TLS, musí zadat platný certifikát. Podrobnosti Na obrázku je znázorněno schéma konfigurace sítě podle uvedeného scénáře: Z obrázku vyplývají tyto informace o situaci popisované ve scénáři: Podnikový veřejný server System A v System A je hostitelský systém podnikové aplikace pro výpočet pojistných sazeb. v System A provozuje operační systém IBM i verzi 5 vydání 4 (V5R4) nebo novější. v Na serveru System A je nainstalovaný a nakonfigurovaný produkt DCM (Digital Certificate Manager) a produkt IBM HTTP Server for i. v Na serveru System A běží aplikace pro výpočet pojistných sazeb, která je nakonfigurovaná následovně: Vyžaduje režim SSL/TLS. Pro svou ověření za účelem inicializace relace SSL/TLS používá veřejný certifikát od známého vydavatele certifikátů. Vyžaduje ověření uživatelů pomocí uživatelského jména a hesla. v Když se klienti B a C přihlašují k aplikaci pro výpočet pojistných sazeb, server System A předkládá svůj certifikát, aby zahájil relaci SSL/TLS. v Když se spustí relace SSL/TLS, server System A předtím, než povolí přístup k aplikaci pro výpočet pojistných sazeb, požaduje, aby klienti B a C předložili platné uživatelské jméno a heslo. Klientské systémy pojiš ovacích agentů klient B a klient C v Klienti B a C jsou nezávislí pojiš ovací agenti, kteří mají přístup k aplikaci pro výpočet pojistných sazeb. 20 IBM i: DCM (Digital Certificate Manager)
Zabezpečení Digital Certificate Manager
System i Zabezpečení Digital Certificate Manager Verze 6 vydání 1 System i Zabezpečení Digital Certificate Manager Verze 6 vydání 1 Poznámka Před použitím těchto informací a před použitím produktu, který
Zabezpečení Digital Certificate Manager
Systémy IBM - iseries Zabezpečení Digital Certificate Manager Verze 5, vydání 4 Systémy IBM - iseries Zabezpečení Digital Certificate Manager Verze 5, vydání 4 Poznámka Před použitím těchto informací
Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2
Úroveň I - Přehled Úroveň II - Principy Kapitola 1 Kapitola 2 1. Základní pojmy a souvislosti 27 1.1 Zpráva vs. dokument 27 1.2 Písemná, listinná a elektronická podoba dokumentu 27 1.3 Podpis, elektronický
Podepisování objektů a ověřování podpisu
Systémy IBM - iseries Podepisování objektů a ověřování podpisu Verze 5, vydání 4 Systémy IBM - iseries Podepisování objektů a ověřování podpisu Verze 5, vydání 4 Poznámka Dříve než použijete tyto informace
SSL Secure Sockets Layer
SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou
Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce
Základní princip Elektronický podpis Odesílatel podepíše otevřený text vznikne digitálně podepsaný text Příjemce ověří zda podpis patří odesílateli uvěří v pravost podpisu ověří zda podpis a text k sobě
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence
Vystavení certifikátu PostSignum v operačním systému MAC OSx
Vystavení certifikátu PostSignum v operačním systému MAC OSx Návod popisuje kroky od vystavení certifikátu až po odeslání a podepsání dat v obchodním systému CS OTE v prostředí operačního systému Apple
Zabezpečení Secure Sockets Layer (SSL)
Systémy IBM - iseries Zabezpečení Secure Sockets Layer (SSL) Verze 5, vydání 4 Systémy IBM - iseries Zabezpečení Secure Sockets Layer (SSL) Verze 5, vydání 4 Poznámka Před použitím těchto informací a
Uživatelská dokumentace
Uživatelská dokumentace k projektu Czech POINT Provozní řád Žádost o výpis nebo opis z Rejstříku trestů podle zákona č. 124/2008 Sb. Vytvořeno dne: 11.4.2007 Aktualizováno: 25.5.2010 Verze: 4.3 2009 MVČR
Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME
Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME Je dostupnou možností, jak lze zaslat lékařskou dokumentaci elektronicky. Co je třeba k odeslání šifrovaného
Uživatelská dokumentace
Uživatelská dokumentace (provozní řád) Žádost o výpis z rejstříku trestů právnických osob Vytvořeno dne: 13.4.2012 Aktualizováno: 2.5.2012 Verze: 1.0 2012 MVČR Obsah 1. Přihlášení do centrály Czech POINT...
Dokumentace. k projektu Czech POINT Provozní řád. Vydání ověřeného výpisu z Obchodního rejstříku
Dokumentace k projektu Czech POINT Provozní řád Vydání ověřeného výpisu z Obchodního rejstříku Vytvořeno dne: 11.4.2007 Aktualizováno: 19.2.2009 Verze: 4.0 2009 MVČR Obsah 1. Přihlášení do Centrály Czech
Uživatelská dokumentace
Uživatelská dokumentace k projektu Czech POINT Provozní řád Vydání ověřeného výpisu z Obchodního rejstříku Vytvořeno dne: 11.4.2007 Aktualizováno: 25.5.2010 Verze: 4.3 2009 MVČR Obsah 1. Přihlášení do
Testovací protokol. webový generátor PostSignum. sada PIIX3; 1 GB RAM; harddisk 20 GB IDE OS: Windows Vista Service Pack 2 SW: Internet Explorer 9
Příloha č. 4 1 Informace o testování estovaný generátor: 2 estovací prostředí estovací stroj č. 1: estovací stroj č. 2: estovací stroj č. 3: Certifikáty vydány autoritou: estovací protokol webový generátor
I.CA SecureStore Uživatelská příručka
I.CA SecureStore Uživatelská příručka Verze 4.1 a vyšší První certifikační autorita, a.s. Verze 4.17 1 Obsah 1. Úvod... 3 2. Přístupové údaje ke kartě... 3 2.1. Inicializace karty... 3 3. Základní obrazovka...
Registr práv a povinností
Registr práv a povinností Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP v4.0
Akreditovaná certifikační autorita eidentity
Akreditovaná certifikační autorita eidentity ACAeID 35 Zpráva pro uživatele Verze: 1.2 Odpovídá: Ing. Jiří Hejl Datum: 21. 12. 2012 Utajení: Veřejný dokument eidentity a.s. Vinohradská 184,130 00 Praha
ING Public Key Infrastructure ING PKI Postup při vydávaní certifikátů. Verze 5.2 květen 2012
ING Public Key Infrastructure ING PKI Postup při vydávaní certifikátů Verze 5.2 květen 2012 Tiráž Zpracovatel Další kopie ING PKI Policy Approval Authority (PAA) Další kopie tohoto dokumentu je možno získat
Dokumentace. k projektu Czech POINT. Popis použití komerčního a kvalifikovaného certifikátu
Dokumentace k projektu Czech POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 11.4.2007 Aktualizováno: 19.2.2009 Verze: 3.3 2009 MVČR Obsah 1. Vysvětleme si pár pojmů...3 1.1.
Příručka nastavení funkcí snímání
Příručka nastavení funkcí snímání WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_CS 2004. Všechna práva vyhrazena. Uplatňovaná ochrana autorských práv se vztahuje na všechny formy a záležitosti
Správa zařízení Scan Station Pro 550 a Servisní nástroje zařízení Scan Station
Správa zařízení Scan Station Pro 550 a Servisní nástroje zařízení Scan Station Konfigurační příručka A-61732_cs 7J4367 Správa zařízení Kodak Scan Station Pro 550 Obsah Rozdíly... 1 Instalace... 2 Vytváření
Enterprise Identity Mapping
Systémy IBM - iseries Enterprise Identity Mapping Verze 5, vydání 4 Systémy IBM - iseries Enterprise Identity Mapping Verze 5, vydání 4 Poznámka Před použitím těchto informací a produktu, který podporují,
České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů. Digitální důvěra. Jiří Smítka
České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů Digitální důvěra Jiří Smítka jiri.smitka@fit.cvut.cz 14.2.2011 1/17 Náplň přednášek Rychlé opakování pojmů
KVALIFIKOVANÉ CERTIFIKÁTY
Ondřej Ševeček PM Windows Server GOPAS a.s. MCM: Directory Services MVP: Enterprise Security ondrej@sevecek.com www.sevecek.com KVALIFIKOVANÉ CERTIFIKÁTY Slovníček Česky veřejný / soukromý klíč otisk podepsat
SMĚRNICE. Certifikační politika k certifikátu šifrování dat pro pracovníka PČS nebo externího uživatele PKI-PČS
uživatele PKI-PČS. SMĚRNICE Věc: Číselná řada: 6/2006 dat pro pracovníka PČS nebo externího uživatele PKI-PČS Ruší se interní předpis č.: Odborný garant: Ing. Antonín Pacák Datum vydání: 1. 2. 2006 Datum
ERserver. iseries. SSL (Secure Sockets Layer)
ERserver iseries SSL (Secure Sockets Layer) ERserver iseries SSL (Secure Sockets Layer) Copyright International Business Machines Corporation 2000, 2002. Všechna práva vyhrazena. Obsah Část 1. SSL (Secure
Úvod - Podniková informační bezpečnost PS1-2
VŠFS; Aplikovaná informatika - 2006/2007 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Úvod - Podniková informační bezpečnost PS1-2 VŠFS; Aplikovaná informatika - 2006/2007 2 Literatura Kovacich G.L.:
PŘÍRUČKA SÍŤOVÝCH APLIKACÍ
PŘÍRUČKA SÍŤOVÝCH APLIKACÍ Uložení protokolu tisku na síť Verze 0 CZE Definice poznámek V celé Příručce uživatele používáme následující ikony: Poznámky uvádějí, jak reagovat na situaci, která může nastat,
ERP-001, verze 2_10, platnost od
ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech
[1] ICAReNewZEP v1.2 Uživatelská příručka
[1] ICAReNewZEP v1.2 Uživatelská příručka 06.10.2011 [2] Obsah 1 - ÚVOD... 3 2 - POUŽITÉ ZKRATKY... 3 3 POŽADAVKY... 4 3.1 POŽADAVKY PRO SPRÁVNÝ CHOD APLIKACE... 4 3.2 POŽADAVKY NA OBNOVOVANÝ CERTIFIKÁT...
Uživatelská dokumentace
Uživatelská dokumentace k projektu Czech POINT Provozní řád Výpis z Insolvenčního rejstříku Vytvořeno dne: 26.3.2009 Aktualizováno: 18.9.2009 Verze: 1.1 2009 MVČR Obsah 1. Přihlášení do Centrály Czech
Konfigurace pracovní stanice pro ISOP-Centrum verze 1.21.32
Informační systém ISOP 7-13 Vypracováno pro CzechInvest Konfigurace pracovní stanice pro ISOP-Centrum verze 1.21.32 vypracovala společnost ASD Software, s.r.o. Dokument ze dne 20.2.2015, verze 1.00 Konfigurace
Identifikátor materiálu: ICT-2-04
Identifikátor materiálu: ICT-2-04 Předmět Téma sady Informační a komunikační technologie Téma materiálu Zabezpečení informací Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí kryptografii.
Návod k instalaci S O L U T I O N S
Návod k instalaci SOLUTIONS Návod k instalaci Hasičská 53 700 30 Ostrava-Hrabůvka www.techis.eu www.elvac.eu +420 597 407 507 Obchod: +420 597 407 511 obchod@techis.eu Podpora: +420 597 407 507 support@techis.eu
Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu
Czech Point Co je Czech Point? Podací Ověřovací Informační Národní Terminál, tedy Czech POINT je projektem, který by měl zredukovat přílišnou byrokracii ve vztahu občan veřejná správa. Czech POINT bude
Certifikáty a jejich použití
Certifikáty a jejich použití Verze 1.0 Vydání certifikátu pro AIS Aby mohl AIS volat egon služby ISZR, musí mít povolen přístup k vnějšímu rozhraní ISZR. Přístup povoluje SZR na žádost OVM, který je správcem
SecureStore I.CA. Uživatelská příručka. Verze 2.16 a vyšší
Uživatelská příručka Verze 2.16 a vyšší Obsah SecureStore I.CA 1. ÚVOD... 3 2. PŘÍSTUPOVÉ ÚDAJE KE KARTĚ... 3 2.1 Inicializace karty... 3 3. ZÁKLADNÍ OBRAZOVKA... 3 4. ZOBRAZENÍ INFORMACÍ O PÁRU KLÍČŮ...
Dokumentace aplikace Chemon
Dokumentace aplikace Chemon Vydání 2.0 Technologie 2000 18.09.2015 Obsah 1 Správa uživatelů programu Chemon 1 1.1 Popis systému uživatelů....................................... 1 1.2 Identifikace uživatelů.........................................
Nastavení lokálního úložiště certifikátů
Nastavení lokálního úložiště certifikátů Aby bylo možné používat lokální úložiště, je nezbytné vytvořit zálohu privátní části elektronického podpisu, tj. soubor s koncovou *.pfx, nebo *.p12. Soubor je
Certifikační autorita EET. Veřejný souhrn certifikační politiky
Certifikační autorita EET Veřejný souhrn certifikační politiky Verze 1.0, 1.9.2016 Vymezení obsahu dokumentu Tento dokument obsahuje informace o zásadách a postupech činnosti Certifikační autority EET,
Uživatelská dokumentace
Uživatelská dokumentace k projektu Czech POINT Provozní řád Vydání ověřeného výstupu ze Seznamu kvalifikovaných dodavatelů Vytvořeno dne: 7.12.2008 Aktualizováno: 25.5.2010 Verze: 2.4 2009 MVČR Obsah 1.
Národní elektronický nástroj. Import profilu zadavatele do NEN
Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce
Vystavení osobního komerčního certifikátu PostSignum v operačním systému MAC OSx
Vystavení osobního komerčního certifikátu PostSignum v operačním systému MAC OSx Tento návod popisuje všechny kroky od vystavení certifikátu až po odeslání a podepsání dat v obchodním systému CS OTE v
Digitální podepisování pomocí asymetrické kryptografie
Digitální podepisování pomocí asymetrické kryptografie 11. dubna 2011 Trocha historie Asymetrické metody Historie Historie Vlastnosti Asymetrické šifrování 1976 Whitfield Diffie a Martin Hellman první
Athena Uživatelská dokumentace v
Athena Uživatelská dokumentace v. 2.0.0 OBSAH Obsah... 2 Historie dokumentu... 3 Popis systému... 4 Založení uživatele... 5 Přihlášení uživatele... 7 První přihlášení... 8 Založení profilu zadavatele/dodavatele...
Manuál k elektronickému podávání přihlášek a žádostí u ÚPV
Manuál k elektronickému podávání přihlášek a žádostí u ÚPV Úvod Elektronické podávání nabízí uživatelům kvalitní a bezpečnou formu komunikace s Úřadem při současné úspoře finančních nákladů a času. Je
Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele
Provozní dokumentace Seznam orgánů veřejné moci Příručka pro běžného uživatele Vytvořeno dne: 7. 7. 2011 Aktualizováno: 11. 2. 2015 Verze: 2.2 2015 MVČR Obsah Příručka pro běžného uživatele 1 Úvod...3
I.CA SecureStore Uživatelská příručka
I.CA SecureStore Uživatelská příručka Verze 4.1 a vyšší První certifikační autorita, a.s. Verze 4.17 1 Obsah 1. Úvod... 3 2. Přístupové údaje ke kartě... 3 2.1. Inicializace karty... 3 3. Základní obrazovka...
Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele
Provozní dokumentace Seznam orgánů veřejné moci Příručka pro běžného uživatele Vytvořeno dne: 7. 7. 2011 Aktualizováno: 7. 6. 2017 Verze: 2.4 2017 MVČR Obsah Příručka pro běžného uživatele 1 Úvod...3 1.1
OKsmart a správa karet v systému OKbase
OKsmart a správa karet v systému OKbase Od personalizace a sledování životního cyklu karet až k bezkontaktní autentizaci a elektronickému podpisu Spojujeme software, technologie a služby Martin Primas
Certifikáty a jejich použití
Certifikáty a jejich použití Verze 1.12 Vydávání certifikátů pro AIS pro produkční prostředí ISZR se řídí Certifikační politikou SZR pro certifikáty vydávané pro AIS uveřejněnou na webu SZR. Tento dokument
Použití čipových karet v IT úřadu
Použití čipových karet v IT úřadu Software pro personalizaci, správu a použití čipových karet Ing. Ivo Rosol, CSc. Ing. Pavel Rous 9. 10. 6. 2011 1 Použití bezkontaktních čipových karet Přístupové systémy
1. DATOVÉ SCHRÁNKY OBECNÝ PŘÍSTUP K DATOVÉ SCHRÁNCE DATOVÉ ZPRÁVY... 3
ESO9 international a.s. Zpracoval: Skyva Petr U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 15.1.20187 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Skyva Petr www.eso9.cz Dne: 15.1.20187 Obsah 1.
Pro uživatele nástroje RICOH Smart Device Connector: Konfigurace zařízení
Pro uživatele nástroje RICOH Smart Device Connector: Konfigurace zařízení OBSAH 1. Pro všechny uživatele Úvod... 3 Jak číst tuto příručku... 3 Ochranné známky...4 Co je to RICOH Smart Device Connector?...
Uživatelská dokumentace
Uživatelská dokumentace k projektu CZECH POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 20.5.2008 Aktualizováno: 23.5.2008 Verze: 1.3 Obsah Uživatelská dokumentace...1 Obsah...2
Národní elektronický nástroj. Principy práce s certifikáty v NEN
Národní elektronický nástroj Principy práce s certifikáty v NEN 9.2.2017 Obsah 1 Úvod... 3 2 Podporované certifikáty... 4 3 Práce s privátními klíči importovanými v úložišti certifikátů nebo na čipové
Postup získání certifikátu pro uživatele WEB aplikací určených pro Sběry dat pro IS VaV
Postup získání certifikátu pro uživatele WEB aplikací určených pro Sběry dat pro IS VaV verze 1.2 Praha 18.12.2002 Obsah WEB aplikace určené pro sběry dat do CEP, CEZ a RIV plně podporují práci s certifikáty.
Předpoklady správného fungování formulářů
Předpoklady správného fungování formulářů Uživatelská příručka Aktualizováno: 19. 2. 2018 Obsah 1 Úvod... 3 2 Systémové požadavky... 3 3 Práce s přílohami... 3 4 MS Internet Explorer... 3 4.1 Instalace
Certifikační autorita PostSignum
Certifikační autorita PostSignum Generování klíčů pomocí programu PostSignum Tool Plus verze 2.0.1 Uživatelská dokumentace Červenec 2011 Strana 1 (celkem 21) 1 Obsah 1 Obsah...2 2 Úvod...3 2.1 Informace
TACHOTel manuál 2015 AURIS CZ
TACHOTel manuál 2 TACHOTel Obsah Foreword I Úvod 0 3 1 Popis systému... 3 2 Systémové... požadavky 4 3 Přihlášení... do aplikace 5 II Nastavení aplikace 6 1 Instalace... a konfigurace služby ATR 6 2 Vytvoření...
CS OTE. Dokumentace pro externí uživatele
CS OTE OTE-COM Launcher Manager aplikace vnitrodenního trhu s plynem 1/19 Obsah Použité zkratky... 2 1 Úvod... 3 2 Nastavení systému uživatele... 3 2.1 Konfigurace stanice... 3 2.2 Distribuce aplikace
Testovací protokol. 1 Informace o testování. 2 Testovací prostředí. 3 Vlastnosti generátoru klíčů. Příloha č. 13
estovací protokol Příloha č. 13 1 Informace o testování estovaný generátor: CertReq 6.1.7600.16385 1 CertReq 6.0.6002.18005 2 1 Verze generátoru ve Windows 7 Service Pack 1 2 Verze generátoru ve Windows
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován
Technická specifikace
Informační systém pro vysoké a vyšší odborné školy Technická specifikace Obecný popis systému Technická specifikace Obecný popis systému Computer Aided Technologies, s.r.o. Tato příručka je součástí dokumentace
Šifrování databáze. Popis šifrovací utility
Šifrování databáze Popis šifrovací utility Verze dokumentu: 1.04 Platnost od: 02.05.2018 Obsah 1. Úvod 3 2. Aktivace šifrování 3 3. Deaktivace šifrování - dešifrování databáze 6 4. Změna šifrovacího klíče
Přechod na SHA-2. informace pro uživatele. Ministerstvo vnitra ČR Odbor rozvoje projektů a služeb služeb egovernment 7. 5. 2010
Přechod na SHA-2 informace pro uživatele Ministerstvo vnitra ČR Odbor rozvoje projektů a služeb služeb egovernment 7. 5. 2010 1 Informační systém datových schránek - Přechod na SHA-2, informace pro uživatele
Registrace a aktivace uživatelského profilu k přístupu do systému erecept pro pacienta
Registrace a aktivace uživatelského profilu k přístupu do systému erecept pro pacienta 1. Obecné 1.1. Základní informace o aplikacích pro pacienta Pro pacienty je zpřístupněná webová a mobilní aplikace.
Autor. Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech
Adresářová služba X.500 a LDAP Autor Martin Lasoň Abstrakt Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech vedla ke vzniku specializovaných databází adresářů.
Podzim 2008. Boot možnosti
Sedí dva velmi smutní informatici v serverové místnosti. Přijde k nim třetí a ptá se: "A cože jste tak smutní?" "No, včera jsme se trošku ožrali a měnili jsme hesla... Podzim 2008 PV175 SPRÁVA MS WINDOWS
- PC musí být připojené v lokální síti - je bezpodmínečně nutné, aby aplikace Outlook nebyla aktivní)
(CETIN) INSTALACE nové verze aplikace Entrust (ESP Entrust Security Provider) (určeno k šifrování souborů a podepisování souborů a zabezpečení e-mailu (šifrování, podpis), aplikace umožňuje současné použití
Nastavení lokálního úložiště certifikátů v OSx
Nastavení lokálního úložiště certifikátů v OSx Aby bylo možné používat lokální úložiště, je nezbytné vytvořit zálohu privátní části elektronického podpisu, tj. soubor s koncovou *.pfx, nebo *.p12. Soubor
I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s
Technické řešení služby I.CA RemoteSeal Ing. Filip Michl První certifikační autorita, a.s. 5. 4. 2018 Agenda Úvod ARX CoSign vs. DocuSign Signature Appliance Architektura Zřízení služby Aktivace služby
Nintex Workflow 2007 je nutné instalovat na Microsoft Windows Server 2003 nebo 2008.
Systémové požadavky Operační systém Nintex Workflow 2007 je nutné instalovat na Microsoft Windows Server 2003 nebo 2008. Prohlížeč Microsoft Internet Explorer 6.x, doporučujeme ale Microsoft Internet Explorer
Ověřené výstupy z ISKN. elektronická značka. Jiří Formánek
Ověřené výstupy z ISKN elektronická značka Jiří Formánek 27.6.2006 Ověřující osoba Podle zákona č. 81/2006 Sb., kterým se mění zákon č. 365/2000 Sb., o informačních systémech veřejné správy vzniká institut
Uživatelská dokumentace
Uživatelská dokumentace k projektu Czech POINT Provozní řád Výpis z Insolvenčního rejstříku Vytvořeno dne: 26.3.2009 Aktualizováno: 25.5.2010 Verze: 1.2 2009 MVČR Obsah 1. Přihlášení do Centrály Czech
Vzdálená správa v cloudu až pro 250 počítačů
Vzdálená správa v cloudu až pro 250 počítačů S pomocí ESET Cloud Administratoru můžete řídit zabezpečení vaší podnikové sítě bez nutnosti nákupu, instalace nebo údržby dalšího hardwaru. Řešení je poskytováno
Obnova certifikátů Gemini 5.0
Obnova certifikátů Gemini 5.0 Obsah Zjištění verze programu Gemini... 3 Obnova podpisového a transportního certifikátu pro verzi Gemini 5.0.51.6... 3 Generován klíče do souboru... 4 Generování klíče do
Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP.
Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Jádro TCP/IP TCP/IP Jádro Pseudo terminal driver Uživatel u terminálu TCP spojení
PTV MAP&GUIDE INTERNET V2 USNADNĚNÝ PŘECHOD
PTV MAP&GUIDE INTERNET V2 USNADNĚNÝ PŘECHOD Obsah Obsah 1 PTV Map&Guide internet V2 Co je nového?... 3 1.1 Změna licenčních modelů... 3 1.1.1 Kmenoví zákazníci 3 1.1.2 Noví zákazníci 4 1.2 Nástroj pro
Česká pošta, s.p. Certifikační autorita PostSignum
Česká pošta, s.p. Certifikační autorita PostSignum 6. 12. 2012 Ing. Miroslav Trávníček Služby certifikační autority Kvalifikované certifikáty komunikace s úřady státní správy Komerční certifikáty bezpečný
Výplatní pásky. Obsah. 1. Přihlášení do aplikace. Uživatelská dokumentace (poslední aktualizace )
Výplatní pásky Uživatelská dokumentace (poslední aktualizace 26.8.2013) Obsah Výplatní pásky... 1 1. Přihlášení do aplikace... 1 2. Zobrazit detail osoby... 2 3. Výplatní pásky... 3 4. Nastavení hesla
496/2004 Sb. VYHLÁŠKA Ministerstva informatiky ze dne 29. července 2004 o elektronických podatelnách
496/2004 Sb. VYHLÁŠKA Ministerstva informatiky ze dne 29. července 2004 o elektronických podatelnách Ministerstvo informatiky stanoví podle 20 odst. 4 zákona č. 227/2000 Sb., o elektronickém podpisu a
Šifrování e-mailů pro business partnery
Šifrování e-mailů pro business partnery (Příručka pro business partnery) Verze 1.1 Datum 31. 1. 2013 Autor e-mail Tým PKI pki@cez.cz Stránka 1 z 13 Obsah 1. Účel dokumentu... 3 Požadavky na business partnery...
Registr práv a povinností
Registr práv a povinností Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP list č.1/20 OBSAH 1 Úvod... 3 2 Doporučené nastavení prohlížeče... 4 2.1 Problém s certifikátem...
Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz
Asymetrická kryptografie a elektronický podpis Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Asymetrická, symetrická a hybridní kryptografie Matematické problémy, na kterých
1.1. Základní informace o aplikacích pro pacienta
Registrace a aktivace uživatelského profilu k přístupu do aplikace systému erecept pro pacienta, přihlášení do aplikace systému erecept pro pacienta na základě registrovaného profilu v NIA nebo elektronického
2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.
2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových
Vzdálené připojení do sítě ČEZ VPN Cisco AnyConnect
Vzdálené připojení do sítě ČEZ VPN Cisco AnyConnect Návod pro práci při vzdáleném připojení do sítě ČEZ a. s., pomocí sítě Internet pro zaměstnance skupiny ČEZ, a. s. Verze 1.03 Verze Stručný popis změn
Robert Hernady, Regional Solution Architect, Microsoft
Robert Hernady, Regional Solution Architect, Microsoft Agenda prezentace Seznámení s problematikou Principy elektronického podpisu Certifikáty Co je třeba změnit pro využití algoritmů SHA-2 Shrnutí nutných
Manuál PVU zadavatel Platnost pro elektronický nástroj X-EN verze 4 a novější
Manuál PVU zadavatel Platnost pro elektronický nástroj X-EN verze 4 a novější 1 Vytvoření profilu zadavatele... 2 1.1 Doplnění identifikátoru profilu zadavatele ve VVZ... 2 2 Správa profilu... 3 2.1 Vytvoření
Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007
Kryptografie, elektronický podpis Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptologie Kryptologie věda o šifrování, dělí se: Kryptografie nauka o metodách utajování smyslu zpráv převodem do podoby,
APS Administrator.OP
APS Administrator.OP Rozšiřující webový modul pro APS Administrator Přehled přítomnosti osob v oblastech a místnostech Instalační a uživatelská příručka 2004 2013,TECH FASS s.r.o., Věštínská 1611/19, Praha,
Obsah SLEDOVÁNÍ PRÁCE... 4
Co je nového Obsah SLEDOVÁNÍ PRÁCE...... 4 Konfigurace souboru... 5 Globální konfigurace... 6 Soubory... 6 Projekty... 6 Uživatelské rozhraní... 7 Synchronizace... 7 Typ serveru... 8 Test připojení...
Nová áplikáce etesty Př í přává PC ž ádátele
Nová áplikáce etesty Př í přává PC ž ádátele Verze 0.6 Datum aktualizace 20. 12. 2014 Obsah 1 Příprava PC žadatele... 2 1.1 Splnění technických požadavků... 2 1.2 Prostředí PC pro žadatele... 2 1.3 Příprava
Vytvoření certifikační autority v programu XCA
Příloha č. 1 Vytvoření certifikační autority v programu XCA 1 Cíl dokumentu Cílem tohoto dokumentu je popsat postup pro vytvoření certifikační autority v programu XCA (http://xca.sourceforge.net) a následné
Uživatelská příručka
B2B CENTRUM a.s. 3.2011 Obsah Začínáme... 3 Přihlášení a zapomenuté heslo... 3 Vytvoření uživatele... 3 Editace osobních údajů... 5 Vkládání souborů... 6 Elektronický podpis... 8 Stavební deník... 11 Identifikační