JAVA: javax.net.ssl.SSLHandshakeException: Remote host closed connection during

java_error

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


balki

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.

Sten

Tohle typicky znamená, že klient se pokusil použít SSL, ale server není nastaven, aby SSL očekával

soyo

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.

ttt

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

Sten

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…

PCnity

  • *****
  • 706
    • Zobrazit profil
    • E-mail
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.