Я использовал это руководство для создания сертификатов для Metro: http://www.jroller.com/gmazza/entry/using_openssl_to_create_certificates
Итак, теперь у меня есть servicestore.jks и clientstore.jks.
Когда я проверяю хранилища ключей, я вижу, что PrivateKeyEntry в servicestore.jks — это myservicekey, а trustCertEntry — это myclientkey. Наоборот в clientstore.jks.
Я использую их в клиентском xml и сервисе wsit xml. Я следовал официальному руководству WSIT, чтобы сделать это в Netbeans. Все нормально разворачивается.
Итак, при тестировании вызова метода от клиента я получаю следующее исключение:
[#|2011-10-19T08:59:38.465+0200|ИНФО|glassfish3.1.1|com.sun.metro.policy|_ThreadID=81;_ThreadName=http-thread-pool-8080(1);|WSP5018: загружено Конфигурация WSIT из файла: file:/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-thread-pool-8080(4); |WSS1533: Ошибка проверки самозаверяющего сертификата.|#]
[#|2011-10-19T08:59:41.171+0200|СЕРЬЕЗНЫЙ|glassfish3.1.1|com.sun.xml.wss.provider.wsit|_ThreadID=84;_ThreadName=http-thread-pool-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, я получил другое исключение, а когда я использовал неправильное имя файла, я получил исключение «Файл не найден». Так что он находит clientstore по крайней мере.
Поэтому я подумал, что может быть что-то не так с хранилищем ключей службы (я думаю, что оно может использовать хранилище Glassfish по умолчанию, а не мое собственное) и нашел некоторые параметры в 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: хранилище ключей было изменено или введен неверный пароль в 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: Ошибка проверки пароля в sun.security. provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770) ... еще 67
Затем я прочитал следующее в руководстве по WSIT: Чтобы использовать безопасность WSIT в Glassfish, вам придется импортировать доверенные хранилища в хранилище ключей GlassFish и указать эти сертификаты из IDE NetBeans.
Значит, я не могу использовать свои собственные хранилища ключей? Я что-то пропустил при изменении domain.xml? Или я ошибся перед всеми вариантами jvm?
