Wypinający się certyfikat kliencki.

Cześć,

wciągnąłem się trochę w Javę. Bawię się w przyszłościowe tematy i tak zainstalowałem JBoss Fuse'a i na nim różne kombinacje usług. Wszystko idzie dobrze, jak są to proste usługi, przyjmij dane, zapisz, odpowiedz.

Problem pojawił się gdy usługa wykorzystuje inną zewnętrzną usługę (wysyłanie sms'a), która wymaga certyfikatu klienckiego. Ogólny overview:

• stworzyłem proxy-sms, gdzie zaimportowałem wsdl'a usługodawcy i otrzymałem możliwość obiektowego wywoływania wysłania sms'ów z innych pakietów/usług własnych;
• stworzyłem service-checkStatus, która wykonuje sprawdzenie i w pewnych sytuacjach wysyła sms'a.

I teraz tak, usługa "service-checkStatus" by wysłać sms'a korzysta z "proxy-sms" plus podpięcie certyfikatu. Zrealizowałem to w ten sposób, że w usłudze "service-checkStatus" dorzucam:

System.setProperty("javax.net.ssl.keyStore", "/jboss/ets/plik-certyfikatu-api.p12");
System.setProperty("javax.net.ssl.keyStorePassword", "asdfasdfasdf");
System.setProperty("javax.net.ssl.keyStoreType", "PKCS12");

i korzystając z BindingProvider'a używając proxy-sms wysyłam sms'a.

Opis problemu. Co jakiś czas, raz tydzień, raz pół tygodnia usługa od sms'ów zwraca mi fault'a z komunikatem, że brakuje certyfikatu klienckiego. Debugując zacząłem logować co się dzieje z systemowymi propertasami. Przy każdym wysłaniu sms'a (tym poprawnym i tym gdzie rzuca mi fault'em) zawartość

System.getProperty("javax.net.ssl.keyStore");
System.getProperty("javax.net.ssl.keyStorePassword");

jest identyczna, wypełniona. Nie mogę dojść do tego co jest odpowiedzialne za to, że co jakiś ruchomy czas wysyłanie sms'ów przestaje działać rzucając błędem typu: brak certyfikatu klienckiego mimo, że parametry są wypełnione.

Co ciekawe po reboot'cie maszyny usługa znów działa przez jakiś czas.

Oprócz logowania parametrów, które sam ustawiasz, to otwieraj ten plik truststore'a i listuj zawartość (co nie oznacza, że masz kluczami pluć do logów)
keystore.

Druga opcja, to co wiesz o tej 'Proxy-sms', może tam zachodzą jakieś redeploymenty, które czyszczą truststore'a i dodają certyfikaty klientów? A może proxy ma load balancing i na jednym węźle certyfikat klienta jest zaimportowany, a na innym nie ?

Bardzo ogólnie to opisałeś i bardzo ogólne komunikaty / stacki błędów ;-)

Dzięki za wpis :)

Co do pakietu "proxy-sms" to sam go buduję z dostarczonego wsdl'a od bramki sms. W pom.xml wykorzystuje plugin: org.apache.cxf -> cxf-codegen-plugin -> generate-jaxb i tak wsdl2java tworzy mi z tego proxy, które wykorzystuje w innych swoich usługach. Mam nadzieję, że jeżeli sam zrobiłem te proxy to te magiczne rzeczy się tam akurat nie zadzieją, ale nie wiem.

TrustStore'a w kodzie Java ogólnie nie ustawiam. Logując parametr "javax.net.ssl.trustStore" otrzymuje null'a.

Dodając trochę szczegółów.

Jak wygląda wysłanie sms:

• jakkolwiek uruchamiana jest moja usługa service-checkStatus
• kiedy spełnione warunki wykorzystuje stworzone przeze mnie proxy-sms
• dodaję parametry, certyfikat i strzelam request do bramki sms z wykorzystaniem proxy-sms
• w odpowiedzi otrzymuję kopertę fault z informacją, że brakuje certyfikatu

Jak wywołuję proxy-sms:

HttpSoapApi50WebService service = new HttpSoapApi50WebService();
HttpSoapApi50WebServiceSoap soap = service.getHttpSoapApi50WebServiceSoap12();

BindingProvider bp = (BindingProvider) soap;
bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointAdress);

soap.sendSmsLong(...)

Może inne usługi czyszczą certyfikat. W sumie coś takiego zaproponowałeś w odniesieniu do proxy-sms. Może inni wgrali jakieś usługi, które w jakiś sposób interferują z moimi. Ciężko mi powiedzieć, nie jestem jeszcze na półmetku nauki.

Truststore, to certyfikaty, którym ufasz, czyli pokrywające całą ścieżkę certyfikacji od CA do certyfikatu?

I dla kogo ten certyfikat klienta jest przeznaczony? Dla proxy-sms (które może przykrywać SOAPem jakiś protokoł typu CIMD2) czy dla tej usługi, która jest za proxy-sms?

Powiedzmy, że w tej chwili z poziomu java nie będę ruszał trustStore, o ile będzie to wymagane. Pamiętam, że coś tam w shell'u coś tam robiłem.

Wracając już do samego certyfikatu. Certyfikat jest przeznaczony do komunikacji z bramką sms czyli jest przeznaczony dla proxy-sms by owe proxy mogło wysyłać sms'y. Jednak moment/miejsce set'owania property typu "javax.net.ssl.keyStore" robię już w danych usługach w których pojawia się potrzeba wysłania sms'a, czyli w omawianym przypadku w service-checkStatus.

Czyli komunikacja wygląda tak: service-checkStatus -- certyfikat kliencki --> proxy-sms -> bramka sms

I teraz jak rozumiem, service-checkStatus "wyciąga" certyfikat kliencki z keyStore i przedstawia się nim do proxy-sms, a to skarży się że nie może znaleźć tego certa.
Oznaczałoby to, że trustStore widziany przerz proxy-sms nie zawiera tego certyfikatu klienckiego.

Dla mnie dziwna sytuacja i podejrzewam:

• wspomniane interakcje z innymi usługami i dzielonym trustStorem
• proxy-sms może być zdeployowane na klastrze, ale tylko na jednym nodzie certyfikat jest dodany do trustStore, a na drugim nie

Chyba, że między proxy-sms a bramką sms, masz też wykorzystanie certyfikatu klienckiego i to co dostajesz w SOAPie ("brak certyfikatu"), to pochodzi od bramki sms, a nie proxy.

Z oględzin wynika, że maszyna na której jest to postawione to prosty 2 procesorowy server z trochę ramu, bez load balancer'a. Jeżeli takie twierdzenie może wykluczyć klastry/nody to będziemy mieli jeden mniej.

Postawiłem trochę więcej debugerów. trustStore jest cały czas null'em, a reszta parametrów jest cały czas wypełniona tymi samymi danymi nawet jak jest błąd. Sprawdzam parametry linijkę wyżej przed użyciem bramki sms.

Modyfikacja komunikacji: service-checkStatus -- setuje certyfikat kliencki w systemowych parametrach java'y --> wykorzystuje proxy-sms -> tutaj jest używany certyfikat -> bramka sms.

Komunikat "brak certyfikatu" pochodzi właśnie od bramki sms. Wewnętrznie między usługami czy też stworzonymi przeze mnie na własne potrzeby proxy, nie ma szyfrowania/certyfikatów. Może JVM w jakimś bardziej tajemniczym miejscu się gubi, zmienia, coś go zmienia. Może sam JBoss Fuse ma w tym udział. Może jakieś inne usługi coś zmieniają, jednak dziwne jest, że wartości: javax.net.ssl.keyStore i javax.net.ssl.keyStorePassword zaraz przed użyciem bramki posiadają wartości te, które potrzebuje :(