Migracja aplikacji do najnowszej Javy a przestarzały cipher suite - integracja z IMB mq

Zmigrowalem serwis do Javy 15 i widzę, że nie wspiera ona już przestarzałego cipher suite. Mam certyfikat i on o ile mi wiadomo posiada zapisany w sobie cipher suite. I teraz próbowałem zmienić cipher suite na wspierany przez najnowsza Javę i przez IBM mq, ale dostaje błąd: unsupported cipher suite. I tak się zastanawiam czy mając tylko certyfikat jestem w stanie coś z tym zrobić.

Tak, jesteś w stanie coś z tym zrobić, ale to wymaga trochę grzebania w ustawieniach security w JRE/JDK: https://java.com/en/configure_crypto.html

Problem jest taki, że dużo lepiej byłoby jednak wygenerować nowy certyfikat i umieścić go na serwerze i kliencie.

wartek01 napisał(a):

Problem jest taki, że dużo lepiej byłoby jednak wygenerować nowy certyfikat i umieścić go na serwerze i kliencie.

Może coś mi umknęło, ale jak nowy certyfikat miałby problem rozwiązać?

Wydaje mi się, że to serwer (IBM MQ w tym przypadku) i klient (aplikacja w Javie 15) ustalają w jaki sposób będą wymieniać sekret. W procesie handshake negocjowane są m.in. szyfry, z wykorzystaniem których, sekret jest wymieniany. Jeśli serwer mówi (wspieram A,B,C), zaś klient (wspieram X,Y,Z), to wymiana certa raczej nie pomoże, bo zbiory {A,B,C} i {X,Y,Z} nie będą miały części wspólnej.

Jedyna opcją wydaje mi się włączenie "starych szyfrów" na kliencie. Będzie działać, ale będzie mniej bezpiecznie? :-)

@yarel: tutaj masz dwie kwestie: protokół komunikacji klient-serwer oraz algorytm szyfrowania klucza zawarty w sygnaturze. Opis wskazuje na to drugie, tj. certyfikat został podpisany algorytmem, który został (z różnych powodów) odrzucony. Oczywiście to nie wyklucza też sytuacji, o której ty piszesz - tj. podmienisz certyfikat, a serwer zacznie się wywalać bo nie będzie wiedział o co chodzi.

Jeśli chodzi o uruchomienie "starych szyfrów" to zadziała. Będzie mniej bezpiecznie - głównie dlatego, że klient zacznie akceptować takie algorytmy co jest podatne np. na podsłuchiwanie.

W sumie to błąd, który dostaje jest dla mnie niezrozumiały, bo z poprzednią wersją Javy używany był cipher suite: SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, który jest wspierany przez IBM mq (tutaj lista), a jego ekwiwalentem wg. tej tabeli jest: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. I jak używam tego drugiego to dostaje błąd:

Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2400' ('MQRC_UNSUPPORTED_CIPHER_SUITE').
	at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203)
	... 35 common frames omitted

Co do tej tabeli to jednak widzę, że on nie jest przestarzały tylko inaczej się nazywa w Javie i inaczej w IBM mq. Nie mam też dostępu do ustawień serwera.

@zgrzyt: przypomina mi się ten błąd i Google to potwierdza: https://www.ibm.com/support/pages/why-tls-connection-mq-failing-compcode-2-mqccfailed-reason-2400-mqrcunsupportedciphersuite-exception

Spróbuj dorzucić ten VM argument na kliencie:

-Dcom.ibm.mq.cfg.useIBMCipherMappings=false

@zgrzyt: a co w certyfikacie masz za algorytm?

Można sprawdzić np. tak (zakładając, że certa masz wyeksportowanego do pliku: twoj_cert.pem)
openssl x509 -in twoj_cert.pem -text 2>&1 | grep 'Signature Algorithm'

Inna opcja to na kliencie włączyć SSL debug (parametry JVM: -Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack) i przejść przez masę logów.

@zgrzyt: czyli jest OK. Ten SunCertPathBuilderException dostajesz, ponieważ po upgradzie JDK/JRE nikt nie dorzucił certyfikatu do truststore'a (zbioru certyfikatów, którym Java ufa). Powinieneś dorzucić certyfikat: https://ananich.pro/2020/06/how-to-bypass-javax-net-ssl-sslhandshakeexception/

Ewentualnie podaj pełny stacktrace, wtedy zobaczymy jaki HostnameVerifier się burzy i czy da się go wyłączyć.