Dotaz: Tomcat a nedůvěryhodný selfsigned certifikát

[Petr]

Ahoj, nevítem jak přidám selfsigned certifikát tomcatu vygenerovaný takhle $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA do důvěryhodných? Dík.

Odpovědi

[Petr]

tady je chyba: Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

[Jendа]

To asi nebude úplně chyba s nedůvěryhodným certifikátem. Zkusil bych se tam připojit řádkovým openssl co to vypíše.

[Petr]

Poradíš mi prosim tě jak?

[Jendа]

openssl s_client -connect adresa:port

taky by mohlo pomoct nmap -p 443 --script ssl-enum-ciphers adresa

[Filip Jirsák]

Kam ho chcete přidat do důvěryhodných certifikátů? Do systémového úložiště Javy? Nebo do systémového úložiště Windows, odkud ho berou Chrome, IE a Edge? Nebo do Firefoxu? Nebo do systémového úložiště,odkud ho berou některé programy v Linuxu?

[Pavel]

Do důvěryhodného úložiště Javy, ale to zřejmě můj problém s handshakem nevyřeší.. nevím. Tomcat i Apache mi běží na jednom serveru. Jde mi o to, aby mi vše jelo na https pro vyhnutí se problémům s proxynama.

[Filip Jirsák]

Asi by bylo lepší, kdybyste popsal problém, který vlastně řešíte. Pokud máte Apache jako reverzní proxy server a za ním Tomcat, z hlediska webových prohlížečů je podstatné, jaký certifikát má Apache – a tam bych dal důvěryhodný od Let's Encrypt, pokud je to aspoň trochu možné. Když pak Tomcat a Apache běží na jednom serveru, není důvod komunikaci mezi Apache a Tomcatem šifrovat, takže na Tomcatu žádný certifikát nepotřebujete.

[Petr]

Je to tak, jak říkáte. Mám na serveru Apache s reverzní proxy s Let's Encrypt certifikátem. Spojení je bez problému přes https. Na Tomcatu mi běží Guacd, který streamuje RDP, a tady nastane problém. Ujme se toho proxy a antivir a obsah začne pro kontrolu kešovat. Trvá to do té doby, dokud se spojení neukončí. Přestože mi vše běží na jednom serveru, mělo by pomoct šifrování i mezi Guacd a Tomcatem (https://guacamole.incubator.apache.org/doc/gug/troubleshooting.html) - Even if you aren't aware of any proxy, there may be one in place. Corporate firewalls very often incorporate proxies. Antivirus software may buffer incoming data until the connection is closed and the data is scanned for viruses. Virtualization software may detect HTTP data and buffer the connection just like a proxy. If all else fails, try HTTPS - it's the only secure way to do this anyway.. Stejně tak mi zabralo i přehození vnitřního streamovacího video serveru na https.

[lertimir]

Myslím si, že problémy je třeba řešit a ne vytvářet. Instrukce z troubleshooting je určena pro řešení situace, kdy mezistanice datového proudu, jako proxy a antivirus, nemáte ve své moci a jejich funkcionalita se musí nějak obejit. Šifrování vytvoří end-to-end komunikační kanál, který funkcionalitu proxy a anitviru vyřazuje, protože k vlastním datům se nedostanou. A je třeba kanál v tomto případě nastavit, tak aby cílový přijemce chápal odesilatele jako legitimního. To je poměrně hloupe v situaci, kdy člověk má plnou moc nad veškerými mezistupni a šifrováním by chtěl jen obcházet svoji neschopnost správně nakonfigurovat proxy, tak aby do této konkrétní komunikace nezasahovala.

[Petr]

Bohužel se k sobě na tomcat aplikaci nedostanu přes proxy, kterou ve své moci nemám.

[lertimir]

no měl jsem pocit že máte server s proxynou a Letencrypt certifikátem a ta to nasměruje někam kde je tomcat. Podle vyjádření je vše na jednom serveru. Tak proč takové komplikované věci, kterým navíc nerozumíte. V každém případě když se k proxyně připojujete musíte uvest doménové jméno (IP adresu) a když bude klient kontrolovat certifikát, tento musí být pro uvedenou adresu validní. Klienta nezajímá, kam to reverzproxy nebo load balancer pošle. nekam se zeptal a k té lokaci chce validní certifikát. informace o přehození vnitřního streamovacího serveru na https je nulová, protože vůbec není jasné, kdo se koho ptá a jak se informace ověřuje.

[Filip Jirsák]

Ujme se toho proxy

Jak se toho ujme proxy? Jestli se bude Apache připojovat k Tomcatu přímo nebo přes proxy je věcí konfigurace Apache – nesměrujte jeho požadavky na proxy ale přímo na Tomcat.

Na Tomcatu mi běží Guacd

mezi Guacd a Tomcatem

Tomuhle nerozumím. Guacd je aplikace v Javě, která běží na Tomcatu (WAR)? Neboje to nějaká samostatná aplikace, se kterou Tomcat komunikuje zase HTTP protokolem (nebo jiným protokolem nad TCP/IP)? Pokud spolu komunikují přes TCP/IP a je to zase na stejném zařízení, nedává žádný smysl ten přenos šifrovat. A i kdybyste to šifrovat chtěl, musíte mít v Guacd certifikát s privátním klíčem, a v Tomcatu nakonfigurovat klienta připojujícího se k Guacd, aby důvěřoval danému certifikátu. To musíte zjistit, jak se ten klient konfiguruje, vůbec nemusí brát v úvahu systémové úložiště certifikátů v Javě nebo její systémové proměnní.

Bohužel se k sobě na tomcat aplikaci nedostanu přes proxy, kterou ve své moci nemám.

Vždyť jste psal, že Apache i Tomcat běží na stejném počítači. To tam je nakonfigurovaný nějaký firewall i na spojení z localhostu na localhost?

[Netolish]

Naimportuješ ho jako důvěryhodný do keystore

keytool -importcert -trustcacerts -file cert.pem -keystore cacerts -alias tomcat

a pak ten keystore "podstrčíš" místo systémového

-Djavax.net.ssl.trustStore=cacerts

[Pavel]

Já ale nemám samotný certifikát.. vygeneroval jsem úložiště s certifikatem.. viz ten příkaz, co jsem použil.

[Pavel Stárek]

A podle dokumentace si to zkoušel?