SSL Websocket с использованием StompClient - исключение SSL-сертификата
У меня есть простой Java StompClient, подключающийся к событиям Java websocket. Работает, когда сервер настроен как ws. Невозможно подключиться, если сервер настроен как wss. Фрагмент кода ниже ...
KeyStore truststore = KeyStore.getInstance("JKS");
truststore.load(this.getClass().getResourceAsStream("/truststore.jks"), "<hidden_pwd_for_thispost>".toCharArray());
KeyStore keystore = KeyStore.getInstance("JKS");;
keystore.load(this.getClass().getResourceAsStream("/keystore.jks"), "<hidden_pwd_for_thispost>".toCharArray());
SSLContext sslContext = new
SSLContextBuilder().loadTrustMaterial(truststore, acceptingTrustStrategy);
.loadKeyMaterial(keystore, "<hidden_pwd_forthisPost>".toCharArray()).build();
TrustStrategy acceptingTrustStrategy = (X509Certificate[] chain, String authType) -> true;
StandardWebSocketClient client = new StandardWebSocketClient();
client.getUserProperties().clear();
client.getUserProperties().put("org.apache.tomcat.websocket.SSL_CONTEXT", sslContext);
WebSocketStompClient stompClient = new WebSocketStompClient(client);
ListenableFuture<StompSession> sessionFuture = stompClient.connect(url, handler);
session = sessionFuture.get();
Исключение
Caused by: java.security.cert.CertificateException: No name matching <myhost> found
at sun.security.util.HostnameChecker.matchDNS(Unknown Source)
at sun.security.util.HostnameChecker.match(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(Unknown Source)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source)
Обратите внимание, что я создал хранилище ключей и самоподписанное хранилище доверия локально. Anf и keyStore, и trustStore имеют CN в качестве моего имени хоста. Проверено выше, запустив keytool -list
Могут ли некоторые предложить. Ваша помощь очень ценится.
Приносим извинения, если на этот вопрос уже дан ответ, я искал пока безрезультатно. Отсюда публикация.
Спасибо,
Ответы 1
Соответствует ли альтернативное имя субъекта в вашем сертификате имени хоста сервера?
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:<**HOST name which matches the server host name**>
Вы можете проверить это, выполнив следующие шаги:
• openssl s_client -connect <serverhostname>:<port on which you connect>
• Copy the string from -----BEGIN CERTIFICATE----- till -----END CERTIFICATE-----
• Paste the string into a .pem file, for example:- “test.pem”
• Run command: openssl x509 -in test.pem -noout -text
Если SAN не имеет имени хоста, тогда появляется DN: См. Это: - CertificateException: имя, совпадающее с ssl.someUrl.de, не найдено
ОБНОВИТЬ:
Если вы пытаетесь добиться взаимной аутентификации, это означает, что и сервер, и клиент должны иметь свой собственный сертификат. На основе кода _stompClient.connect (url, обработчик); мне кажется, что сервер Websocket, вызываемый StompClient, действует здесь как сервер, а ваш вызывающий код является клиентом. Исходя из этого понимания, вы должны правильно настроить свои сертификаты. Я думаю, вам нужно предоставить более подробную информацию по вопросу, чтобы прояснить, как вы все настроили. SSL - сложная тема, даже небольшая ошибка в конфигурации может привести к ошибке. (Это видно из того факта, что WS работает, но не WSS).
ОБНОВИТЬ:
Основываясь на вашем обновленном комментарии, это означает, что сертификата клиента нет на картинке, поэтому клиентом не будет взаимной аутентификации, а будет использоваться только сертификат сервера, и он проверит, доверяет ли он сертификату сервера, что означает ЦС, который подписывает сервер сертификат должен присутствовать в хранилище доверенных сертификатов клиента. Если ваш сервер доступен как веб-сервер, вы можете попробовать открыть его через браузер и проверить, показывает ли он действительный сертификат, если вы используете https для доступа к любому ресурсу / пользовательскому интерфейсу. Это должно, по крайней мере, помочь выяснить, правильно ли настроен сертификат или нет.
Хорошо, как вы проверили правильность CN в вашем хранилище ключей? Кроме того, вы упомянули, что создали хранилище доверия с собственной подписью, что кажется неверным. Надеюсь, вы имели в виду самоподписанный сертификат. Можно обратиться к этому и убедиться, что вы правильно выполнили шаги: - community.pivotal.io/s/article/… или для получения более подробной информации: - docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html
Помните, что в хранилище доверенных сертификатов должны храниться сертификаты доверенных центров сертификации, а в хранилище ключей должен храниться ваш фактический сертификат сервера и закрытый ключ. Также важно отметить, какой тип SSL вы пытаетесь достичь и что действует как сервер и клиент? Вы пытаетесь добиться взаимной проверки подлинности SSL или только проверки подлинности сервера?
Да, я имел в виду самоподписанный сертификат. Я использовал blogs.oracle.com/blogbypuneeth/… для его создания. keytool -list на .jks показывает CN = {hostname_that_am_connecting}, вот как я проверил.
Я пытаюсь добиться взаимной SSL-аутентификации
Если вы пытаетесь добиться взаимной аутентификации, это означает, что и сервер, и клиент должны иметь свой собственный сертификат. На основе кода _stompClient.connect (url, обработчик); мне кажется, что StompClient здесь действует как сервер, а ваш вызывающий код - это клиент. Исходя из этого понимания, вы должны правильно настроить свои сертификаты. Я думаю, вам нужно предоставить более подробную информацию по вопросу, чтобы прояснить, как вы все настроили. SSL - сложная тема, даже небольшая ошибка в конфигурации может привести к ошибке. (Это видно из того факта, что WS работает, но не WSS).
Привет, я пытаюсь подписаться на темы с веб-доступом, используя StompClient. После кода подключения выглядит как session.subscribe (тема, обработчик); Таким образом, при индивидуальном обновлении темы websocket обрабатывается отдельная бизнес-логика. Согласен по части WSS!
Теперь. Мы собираемся использовать сертификат, который имеет тот же CN, что и сервер. Сопоставление CN с фактическим ip в / etx / host. Спасибо! для всех разъяснений.
Это означает, что сертификата клиента нет на изображении, поэтому клиентом не будет использоваться взаимная проверка подлинности, а будет использоваться только сертификат сервера, и он проверит, доверяет ли он сертификату сервера, что означает, что ЦС, подписывающий сертификат сервера, должен присутствовать в магазин доверия клиента. Если ваш сервер доступен как веб-сервер, вы можете попробовать открыть его через браузер и проверить, показывает ли он действительный сертификат, если вы используете https для доступа к любому ресурсу / пользовательскому интерфейсу. Это должно, по крайней мере, помочь выяснить, правильно ли настроен сертификат или нет.
Я так и сделал. Сертификат загружен из браузера только для того, чтобы понять, что команда, раскрывающая эту тему веб-сокета на стороне сервера, предоставляет «тестовые» сертификаты. Итак, используя это сейчас и добавив записи в / etc / host. Опять таки! спасибо за помощь ... очень признателен.
Что именно вы подразумеваете под свидетельством об испытании? У него неправильная конфигурация?
Сертификат, созданный командой для подключения ко всем тестовым средам. Вместо того, чтобы генерировать его на нашем конце, отправили :)
Да пока. Но я верю, что он вернется позже, когда мы попытаемся подключить более одного сервера для обновлений. Сказав, что также необходимо, чтобы сертификат сервера отличался для каждого сервера. Спасибо!!!
Рад слышать! Я обновил ответ подробностями. Если ответ вам помог, вы можете проголосовать за него или закрыть вопрос, приняв ответ. stackoverflow.com/help/someone-answers. Удачи!
Выполнено. Спасибо за помощь.
Привет, спасибо за ответ. Сделал все указанные шаги. Я не вижу подходящего тега. Расширения X509v3: X509v3 Альтернативное имя субъекта: есть ли другой способ, кроме взлома / etc / host, для сопоставления с IP-адресом CN = {host_name_in_server_certificate}? Я пишу, что это клиент, мы потенциально можем подключиться к серверу (-ам). Спасибо!