[obejście problemu istnieje] JOSM zaniemógł przy warstwach Geoportalu

Wygląda że Geoportal od wczoraj ma nowy certyfikat SSL. Efektem ubocznym (zapewne tego) jest to, że dziś przy próbie załadowaniu ich ortofotomapy zamiast kafelków JOSM wyświetla gustowny błąd “unable to find valid certification path to requested target”.
Myślałem że może jakich cache trzeba opróżnić, ale na czystym koncie jest to samo. Nie wiecie, czy da się to jakoś przewalczyć we własnym zakresie, czy trzeba zgłosić dalej?

Rozwiązanie

Problem nie leży po stronie JOSM, a certyfikatu Geoportalu. Można go prosto obejść uruchamiając JOSM z parametrem -Dcom.sun.security.enableAIAcaIssuers=true

Uruchamianie programu powinno wyglądać w sposób podobny do:
java -jar -Dcom.sun.security.enableAIAcaIssuers=true josm-latest.jar

Technikalia

Do certyfikatu SSL wysyłanego przez serwer Geooportalu nie są dołączone wszystkie certyfikaty nadrzędne (Issuer). Java nie wspiera dociągania brakujących certyfikatów.
Brakujący certyfikat to:

The Commercial SSL (or its MultiDomain/Wildcard options)

Certum Domain Validation CA SHA2
Serial No:26ddd22b46c9c44d5a694d39807e72ad
Valid from:‎2014-09-11 12:00:00 GMT
Expiry date:2027-06-09 10:46:39 GMT

Root certificates – Certum

Rozwiązaniem problemu może być włączenie w Javie opcji pobierania brakujących certyfikatów (zalecane) albo dodanie tego certyfikatu do bazy zaufanych w systemie operacyjnym / Javie.

Linux:

W pliku /usr/bin/josm, w linijce 88 dodać linijkę
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.security.enableAIAcaIssuers=true"

87: JAVA_OPTS="$JAVA_OPTS --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED"
88: JAVA_OPTS="$JAVA_OPTS -Dcom.sun.security.enableAIAcaIssuers=true"
89: elif [[ "${JAVA_VERSION}" -ge 9 ]]; then

Windows:

W pliku JOSM.cfg (w katalogu C:\Users\<użytkownik>\AppData\Local\JOSM\app)
należy dodać linijkę:
java-options=-Dcom.sun.security.enableAIAcaIssuers=true

Android

(Every Door, Vespucci)
W systemie operacyjnym przez aplikację Ustawienia można dodać certyfikat w formacie .der do zaufanych. Do pobrania ze strony Root certificates – Certum

The Commercial SSL (or its MultiDomain/Wildcard options)

Certum Domain Validation CA SHA2
Serial No:26ddd22b46c9c44d5a694d39807e72ad
Valid from:‎2014-09-11 12:00:00 GMT
Expiry date:2027-06-09 10:46:39 GMT

Uwaga:
Ten post jest w trybie Wiki. Każdy może edytować jego zawartość żeby go ulepszyć.

1 Like

https://www.ssllabs.com/ssltest/analyze.html?d=mapy.geoportal.gov.pl

Rzeczywiście zaktualizowali. Aktualnym root CA jest Certum. Z tego co zrozumiałem, środowisko Java ma swój zestaw zaufanych certyfikatów w tzw. “Java Trust Store”. Certum jest domyślnie w nim zawarty, jednakże jeśli posiadasz jakąś starszą wersję Java, możliwe jest że certyfikaty od tamtego czasu się zmieniły. Ja widzę 2 rozwiązania tego problemu. 1. Zaktualizować wersję Javy. 2. Ręcznie dodać nowy root CA do Java Trust Store. Proponowałbym 1 opcję ponieważ jest prostsza i stabilniejsza.

1 Like

i bezpieczniejsza, ręczne grzebanie przy tym może się źle skończyć jak się nie znasz i zaufasz złej osobie (w tym komuś kto korzysta z cudzego konta lub się inaczej podszywa)

Będzie z tym kłopot. Domyślna java z windowsowego instalatora JOSM (17.0.6) nie daje rady. Na codziennym komputerze mam openJDK19 i z tego co widzę, nic nowszego w repozytoriach nie znajdę.

No nic, dzięki za rady, poczekam chwilę na aktualizacje, jak nic się nie zadzieje, będę grzebał.

Jeżeli znajdziesz rozwiązanie, to daj znać, bo mam ten sam problem.

Ubuntu 22.04 z JOSM 18646 to samo. Wywala jakis komunikat o certyfikacie, ale ciezko cos sie doczytac, bo kolor czcionki ciezko odroznic od podkladu z cache.

Problemy z certyfikatem SSL geoportalu w JOSM-ie to już kiedyś były i wcale oryginalnym źródłem problemu nie była walidacja ścieżki. Prowadziłem chyba nawet w tej sprawie jakąś korespondencję mailową z GUGiK-iem.

2023-03-03 20:09:45.541 WARNING: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Cause: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Cause: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
	at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:580)
	at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:187)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:142)
	at org.openstreetmap.josm.tools.Http1Client.performConnection(Http1Client.java:78)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:148)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:124)
	at org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.loadObjectHttp(JCSCachedTileLoaderJob.java:359)
	at org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.loadObject(JCSCachedTileLoaderJob.java:307)
	at org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.run(JCSCachedTileLoaderJob.java:233)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
	at java.base/sun.security.validator.Validator.validate(Validator.java:264)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
	... 23 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
	at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
	... 28 more

Java (JOSM) kończy handshake TLS odrzucając Server Hello Geoportalu alertem Certificate Unknown (46), czyli (RFC 8446):

Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.

Piszę o tym, bo openssl s_client (czy też np. curl) ma inny problem:

OpenSSL/3.0.8: error:0A000152:SSL routines::unsafe legacy renegotiation disabled

i kończy handshake alertem Handshake Failure (40), czyli:

indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.

Z kolei Firefox i Chromium jakoś sobie radzą.

1 Like

Według podanego wyżej testu SSL Labs Java też sobie radzi, więc wciąż nie jest przekonany… Niestety, nie mogę sobie przypomnieć, na czym problem polegał poprzednim razem, mam wrażenie, że coś poprawiali w swojej konfiguracji wskutek moich starań, ale może zmyślam :smiley:

Przypominam o Help → Report bug w JOSMie :slight_smile:

Tylko że cały czas sugeruję, że to nie jest błąd JOSM-a ani Javy.

Tez tak sadze. Orto Wroclawia nadal dziala bez problemu.

Z tego co sprawdziłem/zrozumiałem certyfikat dostarczany przez serwer Geoportalu nie zawiera wszystkich nadrzędnych certyfikatów. Dokładnie to są 2 “wyższe”, brakuje tego środkowego (przeglądarka potrafi go sobie dociągnąć).

Można go pobrać ze strony Certum. To będzie:

The Commercial SSL (or its MultiDomain/Wildcard options)

Certum Domain Validation CA SHA2
Serial No:26ddd22b46c9c44d5a694d39807e72ad
Valid from:‎2014-09-11 12:00:00 GMT
Expiry date:2027-06-09 10:46:39 GMT

https://www.certum.eu/en/cert_expertise_root_certificates/#id5

Można też skorzystać z przeglądarki - i Firefox i Chrome mają taką funkcję.

Po dodaniu klucza ręcznie do keystore powinno być ok - sprawdzałem to curlem:

$ curl https://mapy.geoportal.gov.pl

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

A z certyfikatem działa bez błędów.

$ curl --cacert /tmp/dvcasha2.pem https://mapy.geoportal.gov.pl

Teraz jeszcze niech ktoś mi powie jak dodać certyfikat z pliku do zaufanych w Javie, bo sam nie umiem.
To chyba nie jest błąd w Josm, tylko “lack of support” w jakiejś libce.

1 Like

Potwierdzam, dodanie do zaufanych certa Certum Domain Validation CA SHA2 rozwiązuje problem.

Na Ubuntu Java wykorzystuje systemowy truststore. Na Windowsie… bodaj gdzieś w instalacji Javy jest truststore, na którym można operować narzędziem keytool.

1 Like

Z użyciem keytool zrobiłem to tak:

  1. Dodać certyfikat do keytool:
    $ keytool -import -alias geoportalCertum -keystore /tmp/keystore -file /tmp/dvcasha2.der
  2. Odpalać JOSM z podlinkowanym tym keystore (w tym przykładzie ustawiłem hasło “123456”):
    $ java -Djavax.net.ssl.trustStore=/tmp/keystore -Djavax.net.ssl.trustStorePassword=123456 -jar ...

ale nie działa wtedy żaden inny certyfikat oprócz tego - może komuś to pomoże dokończyć to rozwiązanie. Jest o tyle lepsze, że nie dodajemy do systemu na stałe dodatkowego certyfikatu.

1 Like

Jeśli chcemy zmieniać, jak JOSM się odpala, to uruchomienie tej funkcjonalności, która na podstawie certyfikatu przedstawionego przez serwer dociąga brakujący certyfikat pośredni (obsługa rozszerzenia Authority Information Access - CA Issuers), powinna zadziałać. Wystarczy dodać -Dcom.sun.security.enableAIAcaIssuers=true do opcji uruchomienia Javy. Niestety, swoje lokalne środowisko doprowadziłem do stanu, w którym nie mogę tego teraz przetestować.

Edit: udało się przetestować, to rozwiązanie też działa.

3 Likes

Wysłałem email do GUGiK w tej sprawie jak by nie zostało to u nich automatycznie wykryte.

1 Like

Bazując na wszystkich informacjach może to kwestia tego że certificate chain nie jest kompletny i wymaga on dodatkowego pobrania? Na ssl labs jest ostrzeżenie o tym na górze też.

A insecure renegotiation to problem który na geoportalu jest od dłuższego czasu i wcześniej działało.

No i inne aplikacje sobie radzą bo mogą go w miarę automatycznie pobrać. Geoportal powinien wysłać całkowity chain a nie tylko częściowy (dla pełnej kompatybilności).

Zgadza się, i opcja enableAIAcaIssuers, którą przywołałem, włącza właśnie to dociąganie pośredniego certyfikatu, co jest w Javie akurat domyślnie wyłączone.

Pisałem w takiej sprawie już kiedyś, albo do GUGiK-u albo do warszawskiej geodezji (nie pamiętam :confused: ), i poprawili, więc dobrze, że @NieWnen dał znać, jest duża szansa, że zadziałają.

Tak, to jest ten problem, który powoduje, że nowsze wersje OpenSSL-a nie chcą się łączyć jak wyżej u @gscscnd, ale przeglądarki ani Java na razie nie krzyczą z tego powodu.