I am working on a tutorial for REST web services at www.udemy.com (REST Java Web Services). The example in the tutorial said that in order to have SSL, we must have a folder called “trust_store” in my eclipse “client” project that should contain a “key store” file (we had a “client” project to call the service, and “service” project that contained the REST web service – 2 projects in the same eclipse workspace, one the client, the other the service). To keep things simple, they said to copy “keystore.jks” from the glassfish app server (glassfishdomainsdomain1configkeystore.jks) we are using and put it into this “trust_store” folder that they had me make in the client project. That seems to make sense: the self-signed certs in the server’s key_store would correspond to the certs in the client trust_store. Now, doing this, I was getting the error that the original post mentions. I have googled this and read that the error is due to the “keystore.jks” file on the client not containing a trusted/signed certificate, that the certificate it finds is self-signed.
To keep things clear, let me say that as I understand it, the “keystore.jks” contains self-signed certs, and the “cacerts.jks” file contains CA certs (signed by the CA). The “keystore.jks” is the “keystore” and the “cacerts.jks” is the “trust store”. As “Bruno”, a commenter, says above, “keystore.jks” is local, and “cacerts.jks” is for remote clients.
So, I said to myself, hey, glassfish also has the “cacerts.jks” file, which is glassfish’s trust_store file. cacerts.jsk is supposed to contain CA certificates. And apparently I need my trust_store folder to contain a key store file that has at least one CA certificate. So, I tried putting the “cacerts.jks” file in the “trust_store” folder I had made, on my client project, and changing the VM properties to point to “cacerts.jks” instead of “keystore.jks”. That got rid of the error. I guess all it needed was a CA cert to work.
This may not be ideal for production, or even for development beyond just getting something to work. For instance you could probably use “keytool” command to add CA certs to the “keystore.jks” file in the client. But anyway hopefully this at least narrows down the possible scenarios that could be going on here to cause the error.
ALSO: my approach seemed to be useful for the client (server cert added to client trust_store), it looks like the comments above to resolve the original post are useful for the server (client cert added to server trust_store). Cheers.
Eclipse project setup:
- MyClientProject
- src
- test
- JRE System Library
- …
- trust_store
—cacerts.jks
—keystore.jks
Snippet from MyClientProject.java file:
static {
// Setup the trustStore location and password
System.setProperty("javax.net.ssl.trustStore","trust_store/cacerts.jks");
// comment out below line
System.setProperty("javax.net.ssl.trustStore","trust_store/keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
//System.setProperty("javax.net.debug", "all");
// for localhost testing only
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(new javax.net.ssl.HostnameVerifier() {
public boolean verify(String hostname, javax.net.ssl.SSLSession sslSession) {
return hostname.equals("localhost");
}
});
}
Устранение неполадок, связанных с сертификатом
В файле журнала Google Cloud Directory Sync (GCDS) вы можете встретить следующие ошибки, связанные с сертификатом:
- sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- ldap_simple_bind_s() failed: Strong Authentication Required
Чтобы устранить их, выполните указанные ниже инструкции.
Как устранить ошибки, связанные с сертификатами
Развернуть раздел | Свернуть все и перейти к началу
Шаг 1. Обновите файлы VMOPTIONS
Примечание. Если вы используете Linux, пропустите этот шаг и перейдите к шагу 2.
- Закройте Диспетчер конфигураций.
- В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.
Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync.
- Добавьте в файлы следующие строки:
-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Dcom.sun.jndi.ldap.connect.pool.protocol=plain ssl
-Dcom.sun.jndi.ldap.connect.pool.authentication=none simple - Перезапустите Диспетчер конфигураций и перейдите на страницу LDAP Configuration (Конфигурация LDAP).
- Для настройки Connection type (Тип подключения) укажите LDAP+SSL.
- Для настройки Port (Порт) укажите 636 (если ранее использовали порт 389) или 3269 (если ранее использовали порт 3268).
- Нажмите Test connection (Проверить подключение).
- Если ошибка не исчезла, выполните указанные ниже действия.
- На компьютере, на котором запущен инструмент GCDS, убедитесь, что сертификат является доверенным в Windows.
- Если возникает ошибка, связанная с проверкой отзыва сертификата, ознакомьтесь с инструкциями из раздела Как GCDS проверяет списки отзыва сертификатов.
- Если ошибка продолжает появляться, перейдите к шагу 2. Если у вас возникают другие ошибки, например связанные с сетью, ознакомьтесь с инструкциями в статье Устранение неполадок в GCDS.
Шаг 2. Импортируйте сертификат сервера
С помощью этих инструкций вы также можете импортировать сертификаты с серверов LDAP или самозаверяющие сертификаты с прокси-серверов HTTP.
- Войдите в контроллер домена.
- Откройте окно командной строки (cmd.exe) или терминала.
- Введите команду certutil -store My DomainController dccert.cer.
- Скопируйте файл dccert.cer на сервер, где установлено приложение GCDS.
- Выполните вход на сервер, где установлено приложение GCDS.
- Откройте окно командной строки (cmd.exe) или терминала.
На компьютере Windows убедитесь, что вы запустили окно командной строки как администратор.
- Чтобы перейти в каталог, где установлена среда выполнения Java (JRE) приложения GCDS, следуйте указанным ниже инструкциям.
- Для Microsoft Windows: введите команду cd “c:Program FilesGoogle Cloud Directory Syncjre”.
- Если 32-разрядная версия GCDS установлена в 64-разрядной системе Windows, используйте команду cd “c:Program Files (x86)Google Cloud Directory Syncjre”.
- Для Linux: введите команду cd ~/GoogleCloudDirSync/jre.
- Чтобы импортировать сертификат контроллера домена, введите одну из следующих команд:
- binkeytool -keystore libsecuritycacerts -storepass changeit -import -file c:dccert.cer -alias mydc (для Windows);
- bin/keytool -keystore lib/security/cacerts -storepass changeit -import -file ~/dccert.cer -alias mydc (для Linux).
Примечание. Если вам нужно импортировать несколько сертификатов, повторите эти шаги, используя другой псевдоним вместо mydc.
- Чтобы сделать сертификат доверенным, введите Yes (Да).
- Закройте Диспетчер конфигураций.
- В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.
Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux).
- В каждом файле удалите следующие строки:
-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOTПримечание. После этого GCDS будет использовать сертификат, хранящийся в каталоге lib/security/cacerts, а не в системном хранилище Windows.
- Откройте Диспетчер конфигураций, перейдите на страницу LDAP Configuration (Конфигурация LDAP) и нажмите Test Connections (Протестировать соединения), чтобы проверить подключение к серверу LDAP.
- Если ошибки продолжают появляться, вместо сертификата контроллера домена импортируйте тот, что подписан центром сертификации вашей организации. Для этого выполните описанные выше действия с нужным сертификатом.
Как GCDS проверяет списки отзыва сертификатов
При подключении к API Google (через HTTPS) и серверу LDAP по протоколу SSL приложение GCDS проверяет сертификаты SSL. Для этого оно получает списки отзыва сертификатов из центров сертификации по протоколу HTTP. Иногда подключение установить не удается, потому что прокси-сервер или брандмауэр блокирует HTTP-запрос.
Проверьте, может ли сервер GCDS открыть следующие URL через HTTP (порт 80):
- http://crl.pki.goog
- http://crls.pki.goog
Сведения о текущих списках отзыва сертификатов приведены в разделе Проверка CRL. Если для LDAP через SSL вы используете собственные сертификаты, вам могут потребоваться дополнительные URL.
Если получить доступ к спискам отзыва сертификатов не удается, попробуйте отключить их проверку.
- В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.
Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux).
- Добавьте в файлы следующие строки:
- -Dcom.sun.net.ssl.checkRevocation=false
- -Dcom.sun.security.enableCRLDP=false
Медленная синхронизация после перехода на LDAP+SSL
Попробуйте выполнить следующие действия:
- Закройте Диспетчер конфигураций.
- В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions, используя текстовый редактор.
Примечание. Как правило, каталог установки расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux). - Добавьте в файлы следующие строки:
-Dcom.sun.jndi.ldap.connect.pool.protocol=plain ssl
-Dcom.sun.jndi.ldap.connect.pool.authentication=none simple - Сохраните файлы и снова запустите синхронизацию.
Проверьте, корректно ли выполняется аутентификация после обновления Microsoft ADV190023
Если вы используете Microsoft Active Directory с включенным связыванием каналов и подписыванием LDAP, вам необходимо принять меры, чтобы аутентификация GCDS выполнялась с использованием LDAP через SSL. В противном случае GCDS не будет подключаться к Active Directory и выполнить синхронизацию не удастся. Следуйте приведенным ниже инструкциям, даже если ранее запускали синхронизацию с помощью аутентификации через стандартный LDAP. Дополнительная информация об обновлении ADV190023 приведена в документации Microsoft.
Если вы уже используете сервер LDAP через SSL, дальнейших действий с вашей стороны не требуется.
Развернуть раздел | Свернуть все и перейти к началу
Шаг 1. Включите TLS в Active Directory
Шаг 2. Убедитесь, что сертификат является доверенным
Центр сертификации, подписывающий сертификат вашего контроллера домена, должен быть одобрен GCDS. Многие известные интернет-центры сертификации, такие как Verisign, Comodo и Let’s Encrypt, являются доверенными. Если вы используете их, пропустите этот шаг.
Если ваш центр сертификации не является доверенным или вы используете корневой центр сертификации, следуйте инструкциям в разделе Как устранить ошибки, связанные с сертификатами.
Шаг 3. Настройте Диспетчер конфигураций
- Откройте Диспетчер конфигураций и перейдите на страницу LDAP Configuration (Конфигурация LDAP).
- Для настройки Connection type (Тип подключения) укажите LDAP+SSL.
- Для настройки порта укажите 636 (если ранее использовали порт 389) или 3269 (если ранее использовали порт 3268).
- Нажмите Test connection (Проверить подключение).
Google, Google Workspace, а также другие связанные знаки и логотипы являются товарными знаками компании Google LLC. Все другие названия компаний и продуктов являются товарными знаками соответствующих компаний.
Эта информация оказалась полезной?
Как можно улучшить эту статью?
The article presents the steps to import required certificates and enable Java application to connect to Azure SQL DB/Managed Instance. If required certificates are missing on client machine when connecting via AAD authentication, a similar error will be prompted in the application logs:
“SQLServerException: Failed to authenticate the user in Active Directory (Authentication=ActiveDirectoryPassword).
Caused by: ExecutionException: mssql_shaded.com.microsoft.aad.adal4j.AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. “
This is an issue in Java Certificate Store. As a quick workaround, if you enable TrustServerCertificate=True in the connection string, the connection from JDBC succeeds. When TrustServerCertificate
is set to true
, the transport layer will use SSL to encrypt the channel and bypass walking the certificate chain to validate trust. If TrustServerCertificate
is set to true
and encryption is turned on, the encryption level specified on the server will be used even if Encrypt
is set to false
. The connection will fail otherwise. However, for security considerations, it is not recommended to bypass the certificate validation. Hence, to address the issue, follow the steps below to change the connection string and import the required certificates.
- Change the connection string to point to the Java certificate path
String connectionUrl = “jdbc:sqlserver://localhost:1433;” +
“databaseName=AdventureWorks;integratedSecurity=true;” +
“encrypt=true; trustServerCertificate=false;” +
“trustStore= C:Program FilesJavajdk-14.0.2libcacert;trustStorePassword=changeit”; - Import all the certificates mentioned in this document.
Note: To import above certificates into the keystore cacerts, please use below command and please note you must mention truststore and truststore password in the connection string to successfully connect.
Steps to import missing certificates in Java Certificate Store
Download all the certs from here, store them in a location on client host and then use keytool utility to import these certificates into the truststore. Please follow the below steps:
- Save all the certificates from the above MS doc.
- Keytool utility is in the bin folder of your default Java location (C:Program FilesJavajdk-14.0.2bin). You need to use command prompt to navigate to that location.
- Then you can use the keytool command to import the certificate previously saved.
- When prompted for password insert the key in the password as “changeit”
Example of commands:
keytool -importcert -trustcacerts -alias TLS1 -file “C:UsersDocumentsMicrosoft RSA TLS CA 01.crt” -keystore “C:Program FilesJavajdk-14.0.2libsecuritycacerts”
keytool -importcert -trustcacerts -alias TLS2 -file “C:UsersDocumentsMicrosoft RSA TLS CA 02.crt” -keystore “C:Program FilesJavajdk-14.0.2libsecuritycacerts”
Certificate was added to keystore.
Когда люди говорят “API тесты“, они обычно имеют в виду API, предоставляемый поверх протоколов HTTP либо HTTPs. Так сложилось, что упомянутые протоколы в подавляющем большинстве случаев используются при реализации архитектуры REST, а также, для реализации веб-сервисов, работающих по протоколу SOAP. В то время как простой HTTP обычно не вызывает никаких проблем, его ssl-расширение требует более сложного подхода и привлечения таких артефактов как “ключи” и “сертификаты”. Некорректная конфигурация соединения в таких случаях часто приводит к падениям тестов в результате невозможности проверить валидность сертификата, возвращаемого тестовым сервером. В этой статье мы взглянем на такую проблему и узнаем как её решать.
Возможно вы видели сообщение об ошибке вида “PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target”. Если да, значит вы нашли нужную статью.
В нашем примере мы создадим вызов ендпоинта “https://webelement.click”, используя базовый инструментарий, входящий в поставку Java SDK (пакет java.net.*
). Этот вызов скорее всего не будет успешным по причине невозможности валидации предоставляемого сервером сертификата. После этого мы сконфигурируем наш кастомный trust store (чуть позже я объясню что это такое) и научим наш код его использовать. Также мы рассмотрим подход при котором созданный нами trust store станет частью нашего тестового проекта, что сделает тесты более независимыми от среды исполнения.
Итак, вот модель наших API-тестов, которые пытаются осуществить вызов ендпоинта с использованием Secure Socket Layer (также известным под именем Transport Layer Security) протокола.
package click.webelement.https; import java.io.IOException; import java.net.HttpURLConnection; import java.net.URL; public class ApiWithSSL { public static void main(String[] args) { try { HttpURLConnection connection = (HttpURLConnection) new URL("https://webelement.click").openConnection(); int responseCode = connection.getResponseCode(); if(responseCode != 200){ System.out.println("Test failed with actual status code: " + responseCode); }else{ System.out.println("Test passed"); } } catch (IOException e) { System.out.println("Test failed with exception: " + e.getMessage()); } } }
Предполагается, что тест выше упадёт. Давайте теперь заглянем в проблему чуть глубже.
Вообще, конечно, может случиться и так, что тест из примера пройдет успешно. Это произойдет в том случае, если ваша среда корректно настроена и хранилище доверенных сертификатов, используемое по умолчанию содержит сертификаты агентства, выпускающего сертификаты LetsEncrypt. C другой стороны, если бы у вас не было бы проблем, вы бы вряд ли искали решение, правда?
Чаще всего рассматриваемая проблема возникает, когда вы имеете дело с сертификатами, выпущенными локальными корпоративными сертификационными центрами.
В любом случае, я рекомендую дочитать эту статью до конца для того чтобы получить более ясное понимание того, почему вы можете столкнуться с проблемой валидации сертификата. Я также рекомендую изменить URL используемого ендпоинта на ваш вариант с которым вы испытываете проблемы.
Что вообще означает фраза “PKIX path building failed”?
Когда ваш код пытается обратиться к https-эндпоинту, удаленный сервер посылает вашему клиенту свой публичный ключ и сертификат, подтверждающий его (сервера) “личность”. Клиенту, в свою очередь, необходимо решить может ли он доверять такому сертификату. Каждый сертификат подписан цифровой подписью издателя (третьей стороной), что означает, что проверить такую подпись возможно только с помощью публичного ключа издателя.
Но можем ли мы доверять издателю этого сертификата (третьей стороне процесса)? Публичный ключ издателя также сопровождается своим сертификатом, который может быть проверен идентичным путем. Такая цепочка имеет название certificate chain.
В чем состоит основная идея, лежащая в основе протокола https? Этот протокол использует т.н. криптографию открытого ключа (так же известную как “асимметричная” криптография) для того чтобы согласовать с сервером “симметричный” ключ (а фактически – пароль, при помощи которого будут кодироваться и декодироваться сообщения). Таким образом, на первом этапе взаимодействия, клиенту требуется публичный ключ сервера, чтобы при помощи него зашифровать сообщения фазы упомянутого согласования.
Для того чтобы клиент мог быть уверенным в том, что он действительно общается с сервером, с которым он думает, что общается, публичный ключ обычно сопровождается сертификатом. Сертификат – это такой документ, который содержит имя субъекта, а также публичный ключ, ассоциированный с именем субъекта. На основании всей информация сертификата, вычисляется хэш-строка, которая затем подписывается (шифруется) при помощи секретного ключа сертификационного агентства (CA), выдавшего данный сертификат. Единственным способом проверить валидность такого сертификата является вычисление хэш-строки сертификата и сравнение результата с расшифрованным “подписанным” хэшем. Успешно расшифровать подписанный хэш можно только при помощи публичного ключа агенства, который в свою очередь, также сопровождается своим сертификатом.
Любая реализация протоколов HTTPs/SSL подразумевает наличие некоего хранилища сертификатов, которые считаются “доверенными” (в англоязычной среде такое хранилище называется trust store). Таким сертификатам мы доверяем по умолчанию. Вообще говоря, таких хранилищ может быть несколько, и каждое может быть использовано для своих целей. Основное правило, которое необходимо соблюсти для успешной коммуникации вашего кода и HTTPs-сервиса – это наличие хотя бы одного сертификата из цепочки в доверенном хранилище. В Java (в том случае если вы не меняли дефолтное состояние вещей), доверенное хранилище находится в файле %JRE_HOME%/lib/security/cacerts
. Для большинства Java дистрибутивов, такой trust store уже содержит сертификаты/ключи всех общеизвестных сертификационных агентств, так что у вас не должно будет возникнуть проблем при соединении с большинством публичных сервисов в Интернете. Однако, для интранет-сервисов дела обстоят не так безоблачно.
Сообщение “PKIX path building failed” означает, что ssl-библиотека Java в процессе валидации цепочки сертификатов, пришедшей с сервера не смогла обнаружить такой сертификат, который бы находился в используемом trust store.
Подготавливаем траст стор для того чтобы наш код доверял бы сертификату от тестового сервера
Мы собираемся применить комплексный подход к решению нашей задачи. Сперва нам необходимо подготовить доверенное хранилище, которое бы содержало сертификат, возвращаемый нашим тестовым сервером. Ниже перечислены шаги, которые необходимо выполнить:
-
Получить файл сертификата, содержащий сертификат вашего сервиса. Это может быть сделано одним из двух способов. 1) спросить ваших разработчиков или девопсов, ответственных за имплементацию и деплоймент сервиса. 2) Открыть https ендпоинт в вашем веб-браузере, кликнуть на иконку “замочек” рядом с адресной строкой, следовать указаниям открывшегося диалога, который в итоге приведет вас к ссылке на экспортирование сертификата в виде файла. Нам подойдут сертификаты в форматах .pem или .cer.
-
Создать какой-нибудь каталог, куда положить полученный файл. Открыть командную строку и перейти в созданный каталог. Важно убедиться в том, что ваша переменная окружения
PATH
содержит каталог%JRE_HOME%/bin
(это необходимо для того, чтобы иметь возможность запускать утилиту keytool из любого места вашей файловой системы). -
Находясь в созданном каталоге, импортируйте файл сертификата в хранилище (которое пока еще не создано) используя следующую команду.
keytool -importcert -file your-cert-file.pem -keystore mytruststore -storetype PKCS12
Установите какой-нибудь пароль. Этот пароль будет использоваться при обращении вашего кода к созданному хранилищу. Также ответьте “Yes” на вопрос действительно ли вы хотите доверять импортируемому сертификату.
После того как импорт завершится вы должны будете увидеть новый файл
mytruststore
в каталоге с сертификатом. Этот файл – и есть ваше новое доверенное хранилище сертификатов, которое теперь содержит сертификат, возвращаемый вашим тестовым сервисом.
Как использовать новый trust store в моем Java-тесте?
После того, как мы создали новый траст стор, нам необходимо как-то сообщить нашему тестовому коду, что теперь ему следует работать с новым хранилищем. Это можно сделать либо установив значения для соответствующих системных свойств через параметры командной строки при вызове ваших тестов из консоли (это, например, удобно делать при интеграции ваших тестов с инструментами Continuous Integration) или установить эти значения прямо в исполняемом коде. Мы будем использовать второй способ. Свойства, значения для которых нам надо будет установить, такие: javax.net.ssl.trustStore
and javax.net.ssl.trustStorePassword
.
Предположим, что мы создали хранилище доверенных сертификатов в файле mytruststore
, который находится в каталоге /home/me/ssl
и пароль, установленный для нашего хранилища – mystorepass
. Тогда неработающий пример из начала статьи можно было бы переписать таким образом:
package click.webelement.https; import java.io.IOException; import java.net.HttpURLConnection; import java.net.URL; public class ApiWithSSL { static { System.setProperty("javax.net.ssl.trustStore", "/home/me/ssl/mytruststore"); System.setProperty("javax.net.ssl.trustStorePassword", "mystorepass"); } public static void main(String[] args) { try { HttpURLConnection connection = (HttpURLConnection) new URL("https://webelement.click").openConnection(); int responseCode = connection.getResponseCode(); if(responseCode != 200){ System.out.println("Test failed with actual status code: " + responseCode); }else{ System.out.println("Test passed"); } } catch (IOException e) { System.out.println("Test failed with exception: " + e.getMessage()); } } }
Где мы просто добавляем блок статической инициализации в котором устанавливаем необходимые значения для наших свойств.
Такая настройка не обязательно должна находится в блоке статической инициализации. Она может быть добавлена в любое место, исполняемое до вызова https ендпоинта.
В моей следующей статье, вы узнаете как сделать доверенное хранилище сертификатов частью тестового проекта, таким образом, что оно будет распространяться вместе с тестовым кодом и использоваться в неизменном виде где бы ваши тесты не запускались. Такой подход потребует некоего стандарта подхода к формированию структуры тестовго проекта. В частности, использование таких фреймворков как Maven и JUnit.
Если после прочтения у вас всё ещё остались вопросы, присылайте их мне используя эту форму обратной связи. Я постараюсь ответить вам напрямую, а также скорректировать статью, опираясь на ваши отзывы.
Давайте рассмотрим решение следующей ошибки:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Данная ошибка может быть следствием отсутсвия SSL сертификата в хранилище джавы. Добавить его туда можно следующим образом:
1) Открываем в браузере нужный нам ресур
2) Экспортируем сертифика. На примере Google Chrome:
- Открываем консоль разработчика (F12)
- Переходим на вкладку Security -> View certificate -> Detais -> Export
- Сохраняем предлагаемый файл на диск
- Используя утилиту keytool импортируем сертификат в хранилище. Внимание, дефолтный пароль от keystore: changeit
keytool -import -alias your_alias -file ~/_.google.com.ru -keystore $JAVA_HOME/jre/lib/security/cacerts
- Перезапускаем наше приложение.
Необходимо помнить, что при обновлении джавы будет создан новый keystore и процедуру необходимо будет повторить.