SunCertPathBuilderException: невозможно найти действительный путь сертификации к запрошенной цели в приложении CN1 - PullRequest
0 голосов
/ 24 мая 2018

Пожалуйста, вы можете помочь.У меня есть приложение Codenameone, которое выдает GET-запрос к облачному серверу Tomcat 8 и ожидает ответ JSON.Важно, что это HTTPS-вызов.

Когда я запускаю запрос в Postman, он работает нормально:

https://www.mydomain.co.uk:8443/MyProject/v1/generate_token

Тот же URL-адрес через мой браузер работает и отображается как 'Безопасный », и я могу видеть детали моего сертификата.Я купил сертификат для своей конфигурации SSL / TLS и, кажется, нормально работает в журналах при запуске.

В симуляторе я получаю следующую ошибку в момент чтения ответа от URL-вызова- который, я думаю, должен быть зашифрован:

Exception: javax.net.ssl.SSLHandshakeException - sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
    at com.codename1.impl.javase.JavaSEPort.getResponseCode(JavaSEPort.java:7591)
    at com.codename1.io.ConnectionRequest.performOperation(ConnectionRequest.java:702)
    at com.codename1.io.NetworkManager$NetworkThread.run(NetworkManager.java:282)
    at com.codename1.impl.CodenameOneThread.run(CodenameOneThread.java:176)

Почему приложение должно отличаться от Почтальона, выполняющего вызов (окно Network Monitor подтверждает тот же URL-вызов)?

Ни один излоги обновляются после моего звонка, так что проверять нечего.Я не вносил никаких изменений в свое приложение (которое работало) с момента перехода с http на https.

Вот код CN1, выполняющий вызов:

public String fetchTokenIntoStorage(String userName, String password) {
        ConnectionRequest r = new ConnectionRequest();
        r.setUrl(Constants.URL_HOST_PORT + "/MyProject" + Constants.LIVE_OR_TEST
                + "/v1/generate_token");
        r.addRequestHeader("Content-Type", "application/json");
        r.addRequestHeader("userName", userName);
        r.addRequestHeader("password", password);
        r.setHttpMethod("GET");
        r.setFailSilently(false);
        r.setPost(false);
        // show spinning dialog while connecting
        InfiniteProgress prog = new InfiniteProgress();
        Dialog dlg = prog.showInifiniteBlocking();
        r.setDisposeOnCompletion(dlg);
        NetworkManager.getInstance().setTimeout(10000);
        // NetworkManager.getInstance().addErrorListener(new ActionListener() {
        //
        // @Override
        // public void actionPerformed(ActionEvent evt) {
        // MessageBox.showDialogMessage("Unable to connect to server. Please
        // retry later.");
        // }
        // });
        // NetworkManager.getInstance().updateThreadCount(2);
        NetworkManager.getInstance().addToQueueAndWait(r);

        if (r.getResponseData() != null) {
            JSONParser parser = new JSONParser();
            Map<String, Object> json = null;
            try {
                json = parser.parseJSON(new InputStreamReader(new ByteArrayInputStream(r.getResponseData())));
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            if (json.get("error") != null) {
                return String.valueOf(json.get("error"));
            }
            JwtRecord record = new JwtRecord();
            record.userId = Integer.parseInt(String.valueOf(json.get("userId")));
            record.jsonWebToken = (String) json.get("jwt");
            record.theme = "LIGHT";
            Storage.getInstance().writeObject("MyToken", record);
            return "";
        }
        if (!r.getResponseErrorMessage().equalsIgnoreCase("")) {
            return r.getResponseErrorMessage();
        } else {
            return "Unable to connect to server. Please check connection.";
        }
    }

Переход по кодупохоже, что ошибка только после

NetworkManager.getInstance().addToQueueAndWait(r);

. r.getResponseData () и r.getResponseErrorMessage () имеют значение null.

Большое спасибо

Ответы [ 2 ]

0 голосов
/ 25 мая 2018

Сейчас работает.

  1. (в облаке tomcat) Я удостоверился, что корневой сертификат и промежуточный сертификат были в моем хранилище ключей (по ссылкам, которые я ранее включил).Я включил свой .ca-bundle в хранилище ключей для хорошей меры.

  2. (в облаке tomcat) И я заметил, что я использовал более старую версию конфигурации Apache (урок о том, как полагаться настарые сообщения на форуме).Необходимо, чтобы SSLCACertificateFile указывал на мой файл .ca-bundle, а не на SSCertificateChainFile, в моем apache .conf файле.

  3. Это все еще ошибка на моем симуляторе, но работает на моем iphone, которыйуказывает (как говорит Шай) на различия в JDK, которые я ожидаю, поэтому обновил свой ноутбук до более высокого JDK 1.8.171.Само по себе это не имело значения, но, вероятно, потребовалось.

  4. Покопавшись, я понял, что симуляторы на моем ноутбуке также нуждаются в вышеуказанном.Итак, я запустил приведенные ниже операторы в командной строке от имени администратора, и теперь мой симулятор работает.

    cd% java_home% \ jre \ lib \ security

    path =% java_home \ bin

    keytool -import -alias comodo -keystore cacerts -file C: \ path \ ComodoRoot.cer

    keytool -import -alias comodo_intermediate -keystore cacerts -файл C: \ path \ ComodoInter.cer

    keytool -import -alias купил_cert -keystore cacerts -file C: \ путь \ my_purchased_cert.crt

0 голосов
/ 24 мая 2018

Это происходит, если подписывающий орган не распознается базовым JDK.Предполагая, что вы приобрели свой сертификат из действительного источника, возможно, он использует относительно новый root, что означает, что вам нужно использовать последнюю версию JDK 8.

Например letsencrypt был добавлен только в JDK8 обновление 101.

...