Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: java_error 11. 05. 2017, 21:54:57
-
Ahoj,
prosím o radu s následujícím problémem:
V lokální síti jsou 2 linux stanice, na každé stanici běží Virtualbox. Je virtualizován Win7, je použita kopie Win7 do virtualboxu na druhé stanici, tj.: "identická instalace win". V každé VM-win stanici je potom nainstalován komerční program - Java aplikace, na stroji-1 jako server+klient, na stroji-2 jako klient. Ve VM je nastaveno přesměrování portů aby klient na stroji-2 mohl komunikovat se strojem-1.
Při připojování klienta (stroj-2) na server (stroj-1) získávám následující error:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshaking
Prosí o radu nebo nasměrování, do jakých logů se podívat, čím by mohl být problém způsoben atd.
Díky
-
Server nepodporuje ten isty sifrovaci protokol ako klient. Stava sa to najma, ked su nejake starsie, menej bezpecne, tak sa proste vyradia. Treba nastavit patricne parametre pri spustani klienta.
Chybu odporucam zadat do googlu, na tuto otazku sa pytalo vela ludi a dostali aj dobre odpovede.
-
Tohle typicky znamená, že klient se pokusil použít SSL, ale server není nastaven, aby SSL očekával
-
Zdar.
Este by mohlo byt nefunkcne presmerovanie portov pre request zo siete. Aku chybu dostane client, ked server nema nastavene presmerovanie? Urcite serverrova cast bezi a pocuva? Co hovori netstat na serveri? Ma server nieco v logoch, ked clienta odpaja
?
-
Server neběží nad známým (resp. nevystaven známou autoritou) SSL certifikátem (možná dokonce selfsigned) a s takovým se odmítá klientská aplikace spojit.
Řešení: nahrát certifikát do cacerts na straně klienta a sice do jre\lib\security\cacerts, ledaže by bylo řečeno že jinam pomocí systémové proměnné javax.net.ssl.trustStore (pak se nahraje tam kam míří proměnná). Viz spouštěcí skript klientského app. serveru, nebo aplikace.
-
Řešení: nahrát certifikát do cacerts na straně klienta a sice do jre\lib\security\cacerts, ledaže by bylo řečeno že jinam pomocí systémové proměnné javax.net.ssl.trustStore
To není moc dobrý nápad, protože pak tomu certifikátu/autoritě budou důvěřovat všechny javovské aplikace. A po aktualizaci JRE to musíte měnit znova.
V lepším případě umožňuje aplikace nakonfigurovat certifikát pro ten konkrétní typ komunikace. V horším případě to neumí a je potřeba určit truststore pro celou aplikaci – což se udělá právě pomocí té systémové proměnné javax.net.ssl.trustStore.
-
Doporučuju se kouknout, co konkrétně je špatně než to věštit. Spusť klienta s jedním z parametrů:
-Djavax.net.debug=ssl:handshake
-Djavax.net.debug=ssl
-Djavax.net.debug=all
-
Zdar.
Este by mohlo byt nefunkcne presmerovanie portov pre request zo siete. Aku chybu dostane client, ked server nema nastavene presmerovanie? Urcite serverrova cast bezi a pocuva? Co hovori netstat na serveri? Ma server nieco v logoch, ked clienta odpaja
?
Pokud server nenaslouchá, spadlo by to už na TLS handshaku a nedostalo se to k SSL handshaku
Server neběží nad známým (resp. nevystaven známou autoritou) SSL certifikátem (možná dokonce selfsigned) a s takovým se odmítá klientská aplikace spojit.
Řešení: nahrát certifikát do cacerts na straně klienta a sice do jre\lib\security\cacerts, ledaže by bylo řečeno že jinam pomocí systémové proměnné javax.net.ssl.trustStore (pak se nahraje tam kam míří proměnná). Viz spouštěcí skript klientského app. serveru, nebo aplikace.
Tohle by vyhodilo java.security.cert.CertPathValidatorException a spojení by zavřel klient, ne server
-
Pokud server nenaslouchá, spadlo by to už na TLS handshaku a nedostalo se to k SSL handshaku
Chvilku mi to trvalo, než jsem rozluštil, že to první měl být TCP handshake…
-
Este by moholk byt vyzadovany client certiicate.
Ja by som z vysoka kaslal na Javu, pre debugovanie zober obycajny openssl sclient (alebo wget ak je za tym http). Az bez problemov nadviazes spojenie cez s_client, potom ries dalsi step cez tu aplikaciu.