You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by siva naresh <sv...@progress.com> on 2010/07/13 17:53:41 UTC
writing SSL webservice client
Hi All,
I have written a java client that invoke http webservice and it works
alright.
The requirements are now to make the communication secured. server part is
being done by a different team and they are planning to complete in the
next 10 days. All I know from the server team is :
1. The server certificate is issued by GlobalSign
2. The communication is simple handshake and not mutual.
3. No authentication is required.
My job is to write a client that can invoke https webservice. For this I
have taken a pubic https webservice :
https://api.postalmethods.com/PostalWS.asmx?WSDL .
To determine what needs to be done..
I generated java classes using wsdl2java on the following public wsdl.
https://api.postalmethods.com/PostalWS.asmx?WSDL .
I ran the client file that is generated and that worked perfectly fine. I
was wondering how.. because I have done nothing extra (dont I have to create
http conduit file where I have to specify trustmanagers, ciphersuites etc ?)
I could see that the above wsdl has certificate issued by Thawte CA.
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1046827.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: writing SSL webservice client
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 14 July 2010 1:29:48 pm David Valeri wrote:
> I looked into it some more and here is what I have for default behavior for
> loading a WSDL over HTTPS:
>
> An <http:conduit> configuration in the context is looked up using the WSDL
> URL minus any URL parameters. So a WSDL located at
> https://localhost:8443/service/myservice?wsdl will end up trying to locate
> a configuration with ID "https://localhost:8443/service/myservice".
>
> Wildcards are enabled during this lookup so the bean name can use wildcards
> to match just like when configuring the conduit for service invocations
> using the ".http-conduit" suffix.
>
> A configuration for WSDL retrieval at the above WSDL URL would look like:
>
> <http:conduit name="https://localhost:8443/service/myservice">
> ...
> </http:conduit>
>
> I don't believe this is documented anywhere so I will make a point of
> getting it into the client HTTP configuration documentation.
>
it is kind of mentioned at:
http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html
in the first section. Possibly not very clear though.
Dan
>
> -----Original Message-----
> From: David Valeri [mailto:dvaleri@apache.org]
> Sent: Wednesday, July 14, 2010 12:25 PM
> To: users@cxf.apache.org
> Subject: RE: writing SSL webservice client
>
> This is actually an interesting question as I am working my way through
> similar scenarios right now. Odds are that it worked with the public Web
> service because Thawte is a big commercial CA and is already included in
> the cacerts file. I think that if you do not provide any trust managers
> on the client side, you get trust from cacerts.
>
> The fact that your second scenario worked is different than my current
> experience when trying to retrieve the WSDL, but not for actual service
> invocation. The configuration you list is fine for production use if you
> do the following, encrypt/obfuscate the password value in a properties
> file and read it in using Jasypt. Jasypt extends Spring's property
> placeholder capability to support encrypted property values in property
> files or you can simply lock the file down such that read access is
> limited using your OS. The approach you have to take just depends on your
> program's security requirements.
>
> Did you also retrieve the WSDL over SSL in your second scenario or did you
> load it from the classpath or file system when you created the client? The
> experience I am seeing is that the WSDL resolution into an InputStream
> never happens until deep inside Xerces at which point we are basically
> opening an InputStream on a URL using the default JVM JSSE configuration.
> There are a couple attempts to resolve the URL using URLResource but they
> of course all fail because of the custom PKI so the InputSource that is
> provided to Xerces only has a SystemId and no InputStream.
>
> Is there a way in CXF to force WSDL resolution to use the client TLS config
> on the Bus? I seem to remember seeing this happen with
> TransportURIResolver, but the current behavior I am seeing causes the
> Configurer to not try configuring the HttpConduit because the bean name is
> null. I have just started to debug this behavior, so any pointers would be
> much appreciated.
>
>
> -----Original Message-----
> From: siva naresh [mailto:svutla@progress.com]
> Sent: Wednesday, July 14, 2010 1:41 AM
> To: users@cxf.apache.org
> Subject: Re: writing SSL webservice client
>
>
> I also tried an example locally, Where I generated certificates using
> keytool
> for the server
> and used the same certificate to invoke the server from the client
> using trustmanager in the following way.
>
> <sec:trustManagers>
> <sec:keyStore type="JKS" password="password"
> file="truststore.jks"/>
>
> it worked fine. But this is not for the production use. What changes do I
> need to make for production use ?
>
> what is the way to put the server's public key in the client JDK's cacerts
> file. Does CXF has anything to make this automatically?
>
> Does CXF verify the authenticity of the server's public key with the CA?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
RE: writing SSL webservice client
Posted by David Valeri <dv...@apache.org>.
I looked into it some more and here is what I have for default behavior for
loading a WSDL over HTTPS:
An <http:conduit> configuration in the context is looked up using the WSDL
URL minus any URL parameters. So a WSDL located at
https://localhost:8443/service/myservice?wsdl will end up trying to locate a
configuration with ID "https://localhost:8443/service/myservice".
Wildcards are enabled during this lookup so the bean name can use wildcards
to match just like when configuring the conduit for service invocations
using the ".http-conduit" suffix.
A configuration for WSDL retrieval at the above WSDL URL would look like:
<http:conduit name="https://localhost:8443/service/myservice">
...
</http:conduit>
I don't believe this is documented anywhere so I will make a point of
getting it into the client HTTP configuration documentation.
-----Original Message-----
From: David Valeri [mailto:dvaleri@apache.org]
Sent: Wednesday, July 14, 2010 12:25 PM
To: users@cxf.apache.org
Subject: RE: writing SSL webservice client
This is actually an interesting question as I am working my way through
similar scenarios right now. Odds are that it worked with the public Web
service because Thawte is a big commercial CA and is already included in the
cacerts file. I think that if you do not provide any trust managers on the
client side, you get trust from cacerts.
The fact that your second scenario worked is different than my current
experience when trying to retrieve the WSDL, but not for actual service
invocation. The configuration you list is fine for production use if you do
the following, encrypt/obfuscate the password value in a properties file and
read it in using Jasypt. Jasypt extends Spring's property placeholder
capability to support encrypted property values in property files or you can
simply lock the file down such that read access is limited using your OS.
The approach you have to take just depends on your program's security
requirements.
Did you also retrieve the WSDL over SSL in your second scenario or did you
load it from the classpath or file system when you created the client? The
experience I am seeing is that the WSDL resolution into an InputStream never
happens until deep inside Xerces at which point we are basically opening an
InputStream on a URL using the default JVM JSSE configuration. There are a
couple attempts to resolve the URL using URLResource but they of course all
fail because of the custom PKI so the InputSource that is provided to Xerces
only has a SystemId and no InputStream.
Is there a way in CXF to force WSDL resolution to use the client TLS config
on the Bus? I seem to remember seeing this happen with
TransportURIResolver, but the current behavior I am seeing causes the
Configurer to not try configuring the HttpConduit because the bean name is
null. I have just started to debug this behavior, so any pointers would be
much appreciated.
-----Original Message-----
From: siva naresh [mailto:svutla@progress.com]
Sent: Wednesday, July 14, 2010 1:41 AM
To: users@cxf.apache.org
Subject: Re: writing SSL webservice client
I also tried an example locally, Where I generated certificates using
keytool
for the server
and used the same certificate to invoke the server from the client
using trustmanager in the following way.
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="truststore.jks"/>
it worked fine. But this is not for the production use. What changes do I
need to make for production use ?
what is the way to put the server's public key in the client JDK's cacerts
file. Does CXF has anything to make this automatically?
Does CXF verify the authenticity of the server's public key with the CA?
--
View this message in context:
http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086
015.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by David Valeri <dv...@apache.org>.
That is correct. It will likely just work. You might want to make yourself
aware of the default settings that you are using to ensure that they meet
your security requirements, if you have any.
-----Original Message-----
From: siva naresh [mailto:svutla@progress.com]
Sent: Thursday, July 15, 2010 1:12 AM
To: users@cxf.apache.org
Subject: RE: writing SSL webservice client
Lets keep it simple..
Lets say my original client ( that invokes http web service) is not modified
at all except changing the webservice address from http to https.
But the server has been modified to support https requests and it has
certificate issued by well known GlobalSign CA.
Can I assume that the client need not be changed accept changing the
protocol from http to https..?
--
View this message in context:
http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1171
276.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by siva naresh <sv...@progress.com>.
Thanks David and Nate
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1223565.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by Nate Woody <na...@cac.cornell.edu>.
Yes, that is correct.
Nate
-----Original Message-----
From: siva naresh [mailto:svutla@progress.com]
Sent: Thursday, July 15, 2010 1:12 AM
To: users@cxf.apache.org
Subject: RE: writing SSL webservice client
Lets keep it simple..
Lets say my original client ( that invokes http web service) is not
modified
at all except changing the webservice address from http to https.
But the server has been modified to support https requests and it has
certificate issued by well known GlobalSign CA.
Can I assume that the client need not be changed accept changing the
protocol from http to https..?
--
View this message in context:
http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p
1171276.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by siva naresh <sv...@progress.com>.
Lets keep it simple..
Lets say my original client ( that invokes http web service) is not modified
at all except changing the webservice address from http to https.
But the server has been modified to support https requests and it has
certificate issued by well known GlobalSign CA.
Can I assume that the client need not be changed accept changing the
protocol from http to https..?
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1171276.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by David Valeri <dv...@apache.org>.
This is actually an interesting question as I am working my way through
similar scenarios right now. Odds are that it worked with the public Web
service because Thawte is a big commercial CA and is already included in the
cacerts file. I think that if you do not provide any trust managers on the
client side, you get trust from cacerts.
The fact that your second scenario worked is different than my current
experience when trying to retrieve the WSDL, but not for actual service
invocation. The configuration you list is fine for production use if you do
the following, encrypt/obfuscate the password value in a properties file and
read it in using Jasypt. Jasypt extends Spring's property placeholder
capability to support encrypted property values in property files or you can
simply lock the file down such that read access is limited using your OS.
The approach you have to take just depends on your program's security
requirements.
Did you also retrieve the WSDL over SSL in your second scenario or did you
load it from the classpath or file system when you created the client? The
experience I am seeing is that the WSDL resolution into an InputStream never
happens until deep inside Xerces at which point we are basically opening an
InputStream on a URL using the default JVM JSSE configuration. There are a
couple attempts to resolve the URL using URLResource but they of course all
fail because of the custom PKI so the InputSource that is provided to Xerces
only has a SystemId and no InputStream.
Is there a way in CXF to force WSDL resolution to use the client TLS config
on the Bus? I seem to remember seeing this happen with
TransportURIResolver, but the current behavior I am seeing causes the
Configurer to not try configuring the HttpConduit because the bean name is
null. I have just started to debug this behavior, so any pointers would be
much appreciated.
-----Original Message-----
From: siva naresh [mailto:svutla@progress.com]
Sent: Wednesday, July 14, 2010 1:41 AM
To: users@cxf.apache.org
Subject: Re: writing SSL webservice client
I also tried an example locally, Where I generated certificates using
keytool
for the server
and used the same certificate to invoke the server from the client
using trustmanager in the following way.
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="truststore.jks"/>
it worked fine. But this is not for the production use. What changes do I
need to make for production use ?
what is the way to put the server's public key in the client JDK's cacerts
file. Does CXF has anything to make this automatically?
Does CXF verify the authenticity of the server's public key with the CA?
--
View this message in context:
http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086
015.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: writing SSL webservice client
Posted by Nate Woody <na...@cac.cornell.edu>.
Generally, we use server keys provided by one of the common CA's that are in cacerts by default. I'm not sure if this is applicable to what you're doing.
You can add keys to any keystore (including cacerts) using the keytool command (common uses: http://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html).
Certificate validation is the responsibility of JSSE libraries.
If you're trying to understand the ssl communication, you can turn on ssl debugging (-Djavax.net.debug=all) which may help elucidate what is actually happening for your code.
Hope that get's you going in the the right direction,
Nate
-----Original Message-----
From: siva naresh [mailto:svutla@progress.com]
Sent: Wed 7/14/2010 1:41 AM
To: users@cxf.apache.org
Subject: Re: writing SSL webservice client
I also tried an example locally, Where I generated certificates using keytool
for the server
and used the same certificate to invoke the server from the client
using trustmanager in the following way.
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="truststore.jks"/>
it worked fine. But this is not for the production use. What changes do I
need to make for production use ?
what is the way to put the server's public key in the client JDK's cacerts
file. Does CXF has anything to make this automatically?
Does CXF verify the authenticity of the server's public key with the CA?
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086015.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: writing SSL webservice client
Posted by siva naresh <sv...@progress.com>.
I also tried an example locally, Where I generated certificates using keytool
for the server
and used the same certificate to invoke the server from the client
using trustmanager in the following way.
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="truststore.jks"/>
it worked fine. But this is not for the production use. What changes do I
need to make for production use ?
what is the way to put the server's public key in the client JDK's cacerts
file. Does CXF has anything to make this automatically?
Does CXF verify the authenticity of the server's public key with the CA?
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086015.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: writing SSL webservice client
Posted by Glen Mazza <gl...@gmail.com>.
It sounds like you have it correct, but it's odd that you didn't need to put
the server's public key in your client JDK's cacerts file. Here's what I
have on the issue:
http://www.jroller.com/gmazza/entry/setting_up_ssl_and_basic
Glen
siva naresh wrote:
>
> Hi All,
>
> I have written a java client that invoke http webservice and it works
> alright.
>
> The requirements are now to make the communication secured. server part is
> being done by a different team and they are planning to complete in the
> next 10 days. All I know from the server team is :
> 1. The server certificate is issued by GlobalSign
> 2. The communication is simple handshake and not mutual.
> 3. No authentication is required.
>
> My job is to write a client that can invoke https webservice. For this I
> have taken a pubic https webservice :
> https://api.postalmethods.com/PostalWS.asmx?WSDL .
>
> To determine what needs to be done..
> I generated java classes using wsdl2java on the following public wsdl.
> https://api.postalmethods.com/PostalWS.asmx?WSDL .
>
> I ran the client file that is generated and that worked perfectly fine. I
> was wondering how.. because I have done nothing extra (dont I have to
> create http conduit file where I have to specify trustmanagers,
> ciphersuites etc ?)
> I could see that the above wsdl has certificate issued by Thawte CA.
>
--
View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1046872.html
Sent from the cxf-user mailing list archive at Nabble.com.