====== Certifikáty pro Jetty a Shibboleth IdP ====== Při provozování poskytovatele identity (Identity Provider, IdP) se setkáme s použitím certifikátů. //Certifikáty// jsou důležité pro //zajištění šifrování// (zamezení odposlechu) //a/nebo autenticity// (odhalení neoprávněné manipulace) //obsahu// posílaného po internetu. Přestože se obecně mluví pouze o "certifikátech", technicky se vždy jedná o pár //veřejný klíč// + //soukromý klíč//. Zároveň je třeba zdůraznit, že při provozu IdP se používá několik "certifikátů" (párů veřejných/soukromých klíčů) a jsou na ně různé požadavky. ===== Jetty ===== [[cs:tech:idp:jetty|Jetty]], v němž běží Shibboleth IdP, je javovský (servletový) kontejner a HTTP server. **Certifikát pro Jetty by tedy měl být od důvěryhodné certifikační autority (např. [[https://pki.cesnet.cz/cs/ch-server.html|TCS]])**, protože s tímto certifikátem přijde do kontaktu webový prohlížeč uživatele. Nebude-li tento certifikát od důvěryhodné certifikační autority (CA), prohlížeč uživateli zobrazí varování, že stránka není důvěryhodná/zabezpečená a je možné odposlouchávat komunikaci mezi uživatelem a serverem. Certifikát pro Jetty bude mít v závislosti na vydavateli platnost 1 až 3 roky, na delší období se takové certifikáty nevydávají. Měl by zároveň využívat podpis SHA256 namísto starého SHA1, což je v dnešní době již standardní záležitost. **Při blížící se expiraci tohoto certifikátu a jeho výměně nemusíte kontaktovat operátora federace eduID.cz.** Výměna tohoto certifikátu je naprosto bezproblémová a vyžaduje pouze (mimo vydání nového certifikátu a jeho nakonfigurování) restart Jetty, což způsobí výpadek IdP v řádu desítek sekund. **Změnou certifikátu pro Jetty nijak neohrozíte funkčnost přihlašování ke službám ve federaci eduID.cz anebo v interfederaci eduGAIN.** ===== Shibboleth IdP ===== Shibboleth IdP verze 2 používal dva páry veřejných a soukromých klíčů, [[cs:tech:idp:shibboleth|Shibboleth IdP verze 3]] standardně používá páry tři. Ve verzi 2 i v aktuální verzi 3 se tyto certifikáty generují automaticky během instalace. Jedná se o self-sign certifikáty, čili jsou to certifikáty, které jsou generovány na serveru, kde je provozován Shibboleth IdP, a nejsou tedy od žádné důvěryhodné CA. Výhodou je však jejich //doba platnosti//, která //je standardně 20 let//, a samozřejmě i fakt, že není třeba na jejich vydání čekat. **Tyto certifikáty proto doporučujeme nikdy neměnit za certifikáty důvěryhodné, které mají platnost maximálně 2 roky.** //Tento typ certifikátů je součástí metadat, takže může potenciálně způsobit nedostupnost přihlašování na službách.// Každá služba (Service Provider, SP) ve federaci musí totiž znát veřejný klíč k privátnímu klíči, kterým dokáže rozšifrovat komunikaci pocházející od IdP. Změníte-li tedy svévolně tyto certifikáty aniž byste provedli aktualizaci metadat, uživatelé z vašeho IdP se nebudou moci přihlásit k žádné službě. Zároveň je třeba při jejich aktualizaci nejprve nové certifikáty přidat k těm stávajícím a až dojde k distribuci aktualizovaných metadat na služby (nejpozději do 24 hodin), je možné provést výměnu na IdP. Dokud nebudou služby znát nové certifikáty, není možné je využívat. **V případě výměny těchto certifikátů je třeba nás kontaktovat.** Pokud migrujete z IdP verze 2 na verzi 3, doporučujeme nově vygenerované certifikáty přidat ke stávajícím metadatům. V případě budoucích aktualizací je samozřejmě vhodné, abyste používali stávající certifikáty a nemuseli žádat o změnu metadat. Pokud nějaký z těchto certifikátů, které se nacházejí v metadatech, expiruje, nenastane problém jako u expirace certifikátu pro webový server -- prohlížeč uživatele s tímto certifikátem nepřijde do styku a tedy nezobrazí varování, že certifikátu vypršela platnost. Nicméně to neznamená, že vám v metadatech dovolíme mít expirovaný certifikát a nebudeme vás žádat o jeho výměnu. ==== Proč self-sign certifikát ==== Protože je možné vydat ho na dostatečně dlouhou dobu a vyhnout se tak nutnosti výměny metadat z důvodu jeho vyexpirování. V tomto případě je důraz kladen na to, že jmenovaný [[cs:join-admin-contact|administrativní kontakt]] musí poslat metadata digitálně podepsaným e-mailem, takže máme jistotu, že se nám nikdo nepovolaný nesnaží podstrčit falešná metadata.