[jira] Commented: (CXF-2354) WSDLException thrown for NO Subject alternative DNS name matching when the server names do actually match
[ https://issues.apache.org/jira/browse/CXF-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747368#action_12747368 ] Benson Margulies commented on CXF-2354: --- The problem is : 'https://g4w0203.americas.hpqcorp.net/HPISWeb/ISASCustomerWebService/CustomerService.svc?wsdl=wsdl0'.: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching g4w0203.americas.hpqcorp.net found. I strongly recommend downloading to the file system and running wsdl2java from there. If that won't work, we'll need someone with a lot more SSL knowledge than myself. > WSDLException thrown for NO Subject alternative DNS name matching when the > server names do actually match > - > > Key: CXF-2354 > URL: https://issues.apache.org/jira/browse/CXF-2354 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.2.2 > Environment: Ubuntu 8.10 32bit OS, Java 1.6.10, CXF 2.2.2, Ant 1.7.1 >Reporter: Conor Buescher > > I am working on building a java based web services client for an already > deployed .Net based web service built using WCF. I am unable to run > wsdl2java on the remote wsdl and have downloaded all of the associated wsdl > files to my machine and I can then run wsdl2java using the following ant > build.xml file: > > > ="/home/conorb/devTools/apache-cxf-2.2.2"/> > > > > > > > > > > > > > > > > > > > > > > > > > Once that works I can edit the created files to point to the wsdl url, the > external url is here: > https://g4w0209.americas.hpqcorp.net/HPISWeb/ISASCustomerWebService/CustomerService.svc?wsdl > - and then make changes to the client class for testing the service. > Additionally I download the SSL certificate into my java keystore using the > following command: sudo keytool -import -trustcacerts -keystore > /usr/lib/jvm/java-6-sun-1.6.0.10/jre/lib/security/cacerts -storepass changeit > -alias g4w0217 -file /home/conorb/Documents/groovy/g4w0217.cert.pem > When I run ant ICustomerServiceClient on my modified java code I receive the > following error: > con...@conorb-desktop:~/Documents/groovy/ispe-client$ ant > ICustomerServiceClient > Buildfile: build.xml > compile: > ICustomerServiceClient: > [java] Exception in thread "main" javax.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException: Failed to create > service. > [java] at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:149) > [java] at > org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65) > [java] at javax.xml.ws.Service.(Service.java:56) > [java] at org.tempuri.CustomerService.(CustomerService.java:49) > [java] at > com.hp.hpis.customerservice._2009._02.ICustomerService_BasicHttpBindingICustomerService_Client.main(ICustomerService_BasicHttpBindingICustomerService_Client.java:55) > [java] Caused by: > org.apache.cxf.service.factory.ServiceConstructionException: Failed to create > service. > [java] at > org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:93) > [java] at > org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:204) > [java] at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:147) > [java] ... 4 more > [java] Caused by: javax.wsdl.WSDLException: WSDLException (at > /wsdl:definitions/wsdl:import): faultCode=PARSER_ERROR: Problem parsing > 'https://g4w0203.americas.hpqcorp.net/HPISWeb/ISASCustomerWebService/CustomerService.svc?wsdl=wsdl0'.: > javax.net.ssl.SSLHandshakeException: > java.security.cert.CertificateException: No subject alternative DNS name > matching g4w0203.americas.hpqcorp.net found. > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseImport(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown > Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at > org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:210) > [java] at > org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:175) >
[jira] Created: (CXF-2403) Use of client certificates via http conduit configuration broken
Use of client certificates via http conduit configuration broken Key: CXF-2403 URL: https://issues.apache.org/jira/browse/CXF-2403 Project: CXF Issue Type: Bug Components: Configuration Reporter: Wolfgang Nagele To use standard SSL client certificates for authentication the following configuration should work: In this configuration we would have the public certificate of the server we want to connect to in the truststore and the private key and certificate in the keystore. With the current CXF implementation this results in the following exception: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) [na:1.6.0_13] at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) [na:1.6.0_13] at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) [na:1.6.0_13] ... 39 common frames omitted Once we additionally define the following properties it works: * javax.net.ssl.keyStore=keystore * javax.net.ssl.keyStorePassword=password * javax.net.ssl.trustStore=truststore * javax.net.ssl.trustStorePassword=password This however results in very ugly setups where we have to define the same data twice. Also we miss out on CXF's option of defining specific keystores and truststores per webservice. For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2403) Use of client certificates via http conduit configuration broken
[ https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747480#action_12747480 ] Eamonn Dwyer commented on CXF-2403: --- Hi Wolfgang the use of http:conduit / http:tlsClientParameters is quite widespread and has worked for me (at least). Maybe it is something to do with the particular keystore/trustsore you have set up. Can you upload your truststore and keystore so it can be tested? Thanks Eamonn > Use of client certificates via http conduit configuration broken > > > Key: CXF-2403 > URL: https://issues.apache.org/jira/browse/CXF-2403 > Project: CXF > Issue Type: Bug > Components: Configuration >Reporter: Wolfgang Nagele > > To use standard SSL client certificates for authentication the following > configuration should work: > > > > > > > > > > > In this configuration we would have the public certificate of the server we > want to connect to in the truststore and the private key and certificate in > the keystore. > With the current CXF implementation this results in the following exception: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) > [na:1.6.0_13] > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) > [na:1.6.0_13] > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) > [na:1.6.0_13] > ... 39 common frames omitted > Once we additionally define the following properties it works: > * javax.net.ssl.keyStore=keystore > * javax.net.ssl.keyStorePassword=password > * javax.net.ssl.trustStore=truststore > * javax.net.ssl.trustStorePassword=password > This however results in very ugly setups where we have to define the same > data twice. Also we miss out on CXF's option of defining specific keystores > and truststores per webservice. > For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2403) Use of client certificates via http conduit configuration broken
[ https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747483#action_12747483 ] Eamonn Dwyer commented on CXF-2403: --- also could you just check that you have the keystore file in the same directory as your application? Maybe also try setting the full path name for the keystore like.. file="C:\Projects\mycersts\keystore" > Use of client certificates via http conduit configuration broken > > > Key: CXF-2403 > URL: https://issues.apache.org/jira/browse/CXF-2403 > Project: CXF > Issue Type: Bug > Components: Configuration >Reporter: Wolfgang Nagele > > To use standard SSL client certificates for authentication the following > configuration should work: > > > > > > > > > > > In this configuration we would have the public certificate of the server we > want to connect to in the truststore and the private key and certificate in > the keystore. > With the current CXF implementation this results in the following exception: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) > [na:1.6.0_13] > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) > [na:1.6.0_13] > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) > [na:1.6.0_13] > ... 39 common frames omitted > Once we additionally define the following properties it works: > * javax.net.ssl.keyStore=keystore > * javax.net.ssl.keyStorePassword=password > * javax.net.ssl.trustStore=truststore > * javax.net.ssl.trustStorePassword=password > This however results in very ugly setups where we have to define the same > data twice. Also we miss out on CXF's option of defining specific keystores > and truststores per webservice. > For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2403) Use of client certificates via http conduit configuration broken
[ https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolfgang Nagele updated CXF-2403: - Attachment: keystore > Use of client certificates via http conduit configuration broken > > > Key: CXF-2403 > URL: https://issues.apache.org/jira/browse/CXF-2403 > Project: CXF > Issue Type: Bug > Components: Configuration >Reporter: Wolfgang Nagele > Attachments: client.crt, client.key, client.p12, keystore > > > To use standard SSL client certificates for authentication the following > configuration should work: > > > > > > > > > > > In this configuration we would have the public certificate of the server we > want to connect to in the truststore and the private key and certificate in > the keystore. > With the current CXF implementation this results in the following exception: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) > [na:1.6.0_13] > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) > [na:1.6.0_13] > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) > [na:1.6.0_13] > ... 39 common frames omitted > Once we additionally define the following properties it works: > * javax.net.ssl.keyStore=keystore > * javax.net.ssl.keyStorePassword=password > * javax.net.ssl.trustStore=truststore > * javax.net.ssl.trustStorePassword=password > This however results in very ugly setups where we have to define the same > data twice. Also we miss out on CXF's option of defining specific keystores > and truststores per webservice. > For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2403) Use of client certificates via http conduit configuration broken
[ https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolfgang Nagele updated CXF-2403: - Attachment: client.p12 client.key client.crt > Use of client certificates via http conduit configuration broken > > > Key: CXF-2403 > URL: https://issues.apache.org/jira/browse/CXF-2403 > Project: CXF > Issue Type: Bug > Components: Configuration >Reporter: Wolfgang Nagele > Attachments: client.crt, client.key, client.p12, keystore > > > To use standard SSL client certificates for authentication the following > configuration should work: > > > > > > > > > > > In this configuration we would have the public certificate of the server we > want to connect to in the truststore and the private key and certificate in > the keystore. > With the current CXF implementation this results in the following exception: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) > [na:1.6.0_13] > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) > [na:1.6.0_13] > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) > [na:1.6.0_13] > ... 39 common frames omitted > Once we additionally define the following properties it works: > * javax.net.ssl.keyStore=keystore > * javax.net.ssl.keyStorePassword=password > * javax.net.ssl.trustStore=truststore > * javax.net.ssl.trustStorePassword=password > This however results in very ugly setups where we have to define the same > data twice. Also we miss out on CXF's option of defining specific keystores > and truststores per webservice. > For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2403) Use of client certificates via http conduit configuration broken
[ https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747495#action_12747495 ] Wolfgang Nagele commented on CXF-2403: -- I have tried several ways of generating the certificates (using openssl and keytool alone) none of them worked. Also i do not understand how the workaround would make it work if the keystore were the problem? I have also tried full VS relative path configurations both did not work. The keystore is in the same directory as the application, but i also do not understand how that would change this. The way i generate the client certificate (attached an example with password set as 'password'): openssl genrsa -des3 -out client.key 1024 openssl req -new -x509 -key client.key -out client.crt -days 1000 openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt keytool -importkeystore -srckeystore client.p12 -srcstoretype PKCS12 -destkeystore keystore For the truststore i import the server.crt that i already have: keytool -import -v -trustcacerts -file server.crt -keystore truststore > Use of client certificates via http conduit configuration broken > > > Key: CXF-2403 > URL: https://issues.apache.org/jira/browse/CXF-2403 > Project: CXF > Issue Type: Bug > Components: Configuration >Reporter: Wolfgang Nagele > > To use standard SSL client certificates for authentication the following > configuration should work: > > > > > > > > > > > In this configuration we would have the public certificate of the server we > want to connect to in the truststore and the private key and certificate in > the keystore. > With the current CXF implementation this results in the following exception: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174) > [na:1.6.0_13] > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238) > [na:1.6.0_13] > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280) > [na:1.6.0_13] > ... 39 common frames omitted > Once we additionally define the following properties it works: > * javax.net.ssl.keyStore=keystore > * javax.net.ssl.keyStorePassword=password > * javax.net.ssl.trustStore=truststore > * javax.net.ssl.trustStorePassword=password > This however results in very ugly setups where we have to define the same > data twice. Also we miss out on CXF's option of defining specific keystores > and truststores per webservice. > For further information also see: http://www.quendor.org/archiv/428 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2404) remove reference to the node when defining an interceptor
remove reference to the node when defining an interceptor Key: CXF-2404 URL: https://issues.apache.org/jira/browse/CXF-2404 Project: CXF Issue Type: Bug Components: Documentation Reporter: Vladimir Ritz Bossicard Priority: Trivial according to [1], the node must be omitted when defining an Interceptor but the node is still referenced in the documentation [2] [1] http://mail-archives.apache.org/mod_mbox/cxf-users/200906.mbox/%3c61b5d9410906111005v11511b92kae587d0b9dc0...@mail.gmail.com%3e [2] http://cwiki.apache.org/CXF20DOC/interceptors.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2404) remove reference to the node when defining an interceptor
[ https://issues.apache.org/jira/browse/CXF-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2404. -- Resolution: Fixed Fix Version/s: 2.2.4 Assignee: Daniel Kulp > remove reference to the node when defining an interceptor > > > Key: CXF-2404 > URL: https://issues.apache.org/jira/browse/CXF-2404 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Vladimir Ritz Bossicard >Assignee: Daniel Kulp >Priority: Trivial > Fix For: 2.2.4 > > > according to [1], the node must be omitted when defining an > Interceptor but the node is still referenced in the documentation [2] > [1] > http://mail-archives.apache.org/mod_mbox/cxf-users/200906.mbox/%3c61b5d9410906111005v11511b92kae587d0b9dc0...@mail.gmail.com%3e > [2] http://cwiki.apache.org/CXF20DOC/interceptors.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-2046) Response entity is enclosed in "Result" tags for classes implementing ExceptionMapper
[
https://issues.apache.org/jira/browse/CXF-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabo Manuel closed CXF-2046.
Resolution: Invalid
Hi Team,
My apologies. Just now I realized that a registered provider is affecting the
result. The class some.domain.handlers.StringProvider is adding the unwanted
tags.
Again, sorry.
Gabo
> Response entity is enclosed in "Result" tags for classes implementing
> ExceptionMapper
> -
>
> Key: CXF-2046
> URL: https://issues.apache.org/jira/browse/CXF-2046
> Project: CXF
> Issue Type: Bug
> Components: REST
>Affects Versions: 2.2
> Environment: Java 1.5
> Jetty 6.1
>Reporter: Gabo Manuel
> Attachments: rtbe-ws4-retest_jira.zip, rtbe-ws4-retest_jira.zip
>
>
> Environment and objects involved is the same as that in another issue:
> https://issues.apache.org/jira/browse/CXF-2045
> Additional objects involved:
> public class RuntimeExceptionMapper implements
> ExceptionMapper{
> private static Logger logger =
> Logger.getLogger(RuntimeExceptionMapper.class);
> public Response toResponse(RuntimeException fault) {
> StringBuffer sb = new StringBuffer();
> sb.append("Generate some custom message to hide the real problem from
> end user.");
>
> ResponseBuilder rb = Response.status(500);
> rb.type(MediaType.TEXT_PLAIN_TYPE);
> rb.entity(sb.toString());
> logger.fatal(fault);
>
> Response resp = rb.build();
>
> logger.info("entity: " + resp.getEntity().toString());
>
> return resp;
> }
> }
> Logs captured by TCPMon
> HTTP/1.1 500 Internal Server Error
> Content-Type: text/plain
> Content-Length: 69
> Server: Jetty(6.1.11)
> Generate some custom message to hide the real problem from end
> user.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
