Мы написали нашу собственную веб-карту с использованием Grails. Интернет включает функцию изменения пароля пользователя на сервере Active Directory. Проблема, с которой я сталкиваюсь, связана с работой функции смены пароля, когда веб-приложение запускается из среды разработки, по сравнению с тем, что она не работает при запуске как веб-приложение на сервере Tomcat.
Подробности: Насколько я понимаю, если вы собираетесь изменить пароли пользователей через LDAP в AD, вы должны связаться с сервером AD, используя безопасное соединение LDAP.
Вот что я сделал, чтобы это работало: в моей среде разработки, которой является GGTS (с использованием Grails 2.x) ... я видел, какую JVM она использует. Затем мой администратор AD дал мне сертификат, который я импортировал в файл JVM \ lib \ security \ cacerts с помощью keystore.exe. Я фактически импортировал его во все \ lib \ security \ cacerts для всех JRE / JDK на моей машине, на всякий случай. Когда я запускаю веб-приложение из моей GGTS IDE ... я могу затем использовать веб-приложение для изменения пароля пользователя AD, и он отлично работает. Я считаю, что GGTS запускает собственный встроенный веб-сервер, когда вы запускаете веб-приложение из GGTS, и я считаю, что это Tomcat, но я не уверен.
Затем я использую команду Grails war и создаю файл WAR из веб-приложения. Я иду и развертываю его на автономном Tomcat, который также работает на моей машине. Но когда я пытаюсь использовать функцию смены пароля в своем веб-приложении, я получаю такую ошибку:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации для запрошенной цели
Я считаю, что это указывает на какую-то ошибку, когда Tomcat находит сертификат в JVM.
Я подготовил много постов, посвященных этой проблеме, но не могу ее решить. Может ли кто-нибудь поделиться некоторыми мыслями или дополнительными сведениями, которые мне следует искать?
Дополнительные примечания к вещам, которые я пробовал или наблюдал: я пробовал использовать эти параметры для Tomcat: -Djavax.net.ssl.trustStore = C: \ Program Files (x86) \ Java \ jre1.8.0_91 \ lib \ security \ cacerts -Djavax.net.ssl.trustStorePassword = changeit -Djavax.net.debug = ssl
Для управления тем, какое хранилище доверенных сертификатов будет использовать tomcat, а также для записи информации, связанной с SSL, в файл журнала.
Когда я использовал параметр trustStore с моим собственным местоположением, я действительно увидел, что это повлияло на файл журнала ... он изменился на использование указанного мной файла, а не на тот, который он использовал раньше (у обоих были сертификаты все равно импортированы в них) Фрагмент файла журнала: 2016-05-04 09:07:15 Commons Daemon procrun stdout инициализировано trustStore: C: \ Program Files (x86) \ Java \ jre1.8.0_91 \ lib \ security \ cacerts trustStore Тип: jks trustStore поставщик: init truststore
Я бы также увидел, что он, кажется, дважды упоминает сертификат для моего сервера AD .. это имеет значение? добавление в качестве доверенного сертификата: 1-й раз: Тема: CN = .testdomain1.local, DC = testdomain1, DC = local Издатель: CN = .testdomain1.local, DC = testdomain1, DC = local Алгоритм: RSA ; Серийный номер: 0x116305db11e9d28e409e1dce744cf841 Действителен с понедельника 02 мая 20:40:49 UTC по субботу 02 мая 20:50:49 UTC 2026 Второй раз: добавление в качестве доверенного сертификата: Тема: CN = .testdomain1.local, DC = testdomain1 , DC = локальный эмитент: CN = .testdomain1.local, DC = testdomain1, DC = local Алгоритм: RSA; Серийный номер: 0x116305db11e9d28e409e1dce744cf841 Действителен с понедельника, 2 мая, 20:40:49 UTC, 2016 г., до субботы, 2 мая, 20:50:49 UTC 2026 года.
При возникновении ошибки здесь дополнительная информация журнала:
%% Initialized: [Session-2, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] ** TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA *** Цепочка сертификатов
%% Invalidated: [Session-2, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] http-nio-8080-exec-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown http-nio-8080-exec-1, WRITE: TLSv1 Alert, length = 2 http- nio-8080-exec-1, называется closeSocket () http-nio-8080-exec-1, обрабатывает исключение: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX: sun.security. provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации для запрошенного целевого http-nio-8080-exec-1, называется close () http-nio-8080-exec-1, называется closeInternal (true)
