Использование безопасности WSIT в веб-сервисе с самозаверяющими сертификатами (Glassfish) - PullRequest
2 голосов
/ 20 октября 2011

Я использовал это руководство для создания сертификатов для Metro: http://www.jroller.com/gmazza/entry/using_openssl_to_create_certificates

Так что теперь у меня есть servicestore.jks и clientstore.jks.

Когда я проверяю хранилища ключей, я вижу, что PrivateKeyEntry в servicestore.jks - это myservicekey, а trustCertEntry - это myclientkey. Наоборот в клиентском магазине.jks.

Я использую их в клиентском xml и сервисе wsit xml. Я следовал официальному учебнику WSIT, чтобы сделать это в Netbeans. Все разворачивается нормально.

Итак, при тестировании вызова метода из клиента я получаю следующее исключение:

[# | 2011-10-19T08: 59: 38,465 + 0200 | ИНФО | glassfish3.1.1 | com.sun.metro.policy | _ThreadID = 81; _ThreadName = HTTP-нить бассейн-8080 (1); | WSP5018: Загруженная конфигурация WSIT из файла: Файл:. /opt/glassfish3/glassfish/domains/domain1/applications/testwebapp/WEB-INF/classes/META-INF/wsit-client.xml | #]

[# | 2011-10-19T08: 59: 41,167 + 0200 | ТЯЖЕЛАЯ | glassfish3.1.1 | javax.enterprise.resource.xml.webservices.security | _ThreadID = 84; _ThreadName = HTTP-токарно-пул-8080 ( 4); | WSS1533: Проверка самоподписанного сертификата не удалась. | #]

[# | 2011-10-19T08: 59: 41,171 + 0200 | ТЯЖЕЛАЯ | glassfish3.1.1 | com.sun.xml.wss.provider.wsit | _ThreadID = 84; _ThreadName = HTTP-токарно-пул-8080 ( 4); | WSITPVD0035: Ошибка при проверке безопасности во входящем сообщении. com.sun.xml.wss.XWSSecurityException: проверка собственной подписи сертификат не прошел в com.sun.xml.wss.impl.misc.WSITProviderSecurityEnvironment.validateCertificate (WSITProviderSecurityEnvironment.java:937) в com.sun.xml.ws.security.opt.impl.incoming.X509BinarySecurityToken.validate (X509BinarySecurityToken.java:185) в com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader (SecurityRecipient.java:396) в com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders (SecurityRecipient.java:275) в com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage (SecurityRecipient.java:225) в com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage (WSITServerAuthContext.java:586) .............

Когда я пытался использовать неверный пароль в клиентском xml, я получал другое исключение, а когда я использовал неправильное имя файла, я получал исключение не найденный файл. Таким образом, он находит клиентское хранилище как минимум.

Поэтому я подумал, что может быть что-то не так с хранилищем ключей службы (я думаю, что он может использовать стекловую рыбку по умолчанию, а не мою) и нашел некоторые опции в domain.xml. Поэтому я изменил это:

-Dcom.sun.enterprise.security.httpsOutboundKeyAlias ​​= myservicekey -Djavax.net.ssl.keyStore = $ {com.sun.aas.instanceRoot} /config/servicestore.jks -Djavax.net.ssl.keyStorePassword = sspas -Djavax.net.ssl.trustStore = $ {com.sun.aas.instanceRoot} /config/servicestore.jks -Djavax.net.ssl.trustStorePassword = sspass -DSERVER_KEY_ALIAS = myservicekey -DCLIENT_KEY_ALIAS = myclientkey

но когда я перезагружаю сервер, я получаю это исключение и не могу войти в консоль администратора:

............. Вызвано: java.io.IOException: подделка хранилища ключей с или пароль был неверным at sun.security.provider.JavaKeyStore.engineLoad (JavaKeyStore.java:772) в sun.security.provider.JavaKeyStore $ JKS.engineLoad (JavaKeyStore.java:55) в java.security.KeyStore.load (KeyStore.java:1214) в com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadKS (SecuritySupportImpl.java:254) в com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores (SecuritySupportImpl.java:208) ... еще 63 Причина: java.security.UnrecoverableKeyException: проверка пароля не удалась at sun.security.provider.JavaKeyStore.engineLoad (JavaKeyStore.java:770) ... еще 67

Затем я прочитал следующее в учебном пособии WSIT: Чтобы использовать безопасность WSIT на Glassfish, вам нужно будет импортировать доверенные хранилища в хранилище ключей GlassFish и указать эти сертификаты из IDE NetBeans.

Так что я могуне используете мои собственные хранилища ключей?Я что-то пропустил при смене домена .xml?Или я ошибся, прежде чем все параметры JVM?

1 Ответ

1 голос
/ 20 октября 2011

Из сообщения об ошибке «Проверка самоподписанного сертификата не удалась» я бы пришел к выводу, что сервер не доверяет сертификату клиента, который подписывает / шифрует мыльное сообщение.

Вы должны проверить, какое хранилище доверенных сертификатов используется Glassfish и содержит ли оно сертификат клиента. Я не знаю много о стеклянной рыбе, но здесь , кажется, некоторые направления. Используется ли servicestore.jks в качестве хранилища доверенных сертификатов и действительно содержит точный сертификат клиента. Можно легко сгенерировать файл clienttore.jks и забыть воссоздать хранилище доверенных сертификатов.

Если склад доверенных сертификатов содержит ожидаемый сертификат и фактически используется glassfish, вам также следует проверить, какой сертификат отправлен клиентом. Посмотрите в заголовок и посмотрите на BinarySecurityToken. В зависимости от вашего выбора WSIT, он содержит сертификат, используемый в сообщении.

...