Thanks, I have always avoided doing these sorts of examples because I have never used/installed maven, which I can see will be required.
Thanks, Chris On Mon, Aug 13, 2012 at 3:52 PM, Glen Mazza <[email protected]> wrote: > Oh, nothing compared to trying to do it with raw Java code. Sure, it will > work with CXF 2.6.1; if you'd like to run the wsdl_first_https sample on > your local machine to see how easy it is: > > 1.) check out the samples in the CXF 2.6 source branch (unfortunately I > just made these mega-simplifications last week so it may take a week or two > to get into a downloadable CXF release): > > svn co http://svn.apache.org/repos/**asf/cxf/branches/2.6.x-fixes/** > distribution/src/main/release/**samples/<http://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes/distribution/src/main/release/samples/> > > 2.) navigate to the samples/wsdl_first_https sample, edit the pom.xml to > change the version from 2.6.2-SNAPSHOT to 2.6.1. > > 3.) run "mvn clean install" from the wsdl_first_https folder. > > 4.) Follow the README in the wsdl_first_https folder to see how to run the > sample. It's quite simple, basically, mvn -Pserver from one terminal > window and mvn -Psecure.client, mvn -Pinsecure.client, etc. in another > window. > > HTH, > Glen > > > On 08/13/2012 09:21 PM, Christopher Richmond wrote: > >> This is for CXF 2.6.1? >> >> How much overhead/work will it be to add what I need to use spring? >> >> Thanks, >> Chris >> >> On Mon, Aug 13, 2012 at 3:15 PM, Glen Mazza <[email protected]> wrote: >> >> I don't know of a non-Spring solution, at least not service-side, but the >>> code is very easy & clean if you're willing to incorporate Spring: >>> >>> http://svn.apache.org/viewvc/****cxf/trunk/distribution/src/**<http://svn.apache.org/viewvc/**cxf/trunk/distribution/src/**> >>> main/release/samples/wsdl_****first_https/src/main/java/** >>> demo/hw_https/server/Server.****java?revision=1368316&view=****markup< >>> http://svn.apache.org/**viewvc/cxf/trunk/distribution/** >>> src/main/release/samples/wsdl_**first_https/src/main/java/** >>> demo/hw_https/server/Server.**java?revision=1368316&view=**markup<http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java?revision=1368316&view=markup> >>> > >>> >>> >>> The wsdl_first_https sample above, does however offer a non-Spring >>> solution client-side, look in the hw_https/client folder for that. (Note >>> I'm showing the unreleased version presently in trunk, considerably >>> simplified from the current release versions.) >>> >>> Glen >>> >>> >>> On 08/13/2012 08:33 PM, Christopher Richmond wrote: >>> >>> I had implemented 2 way SSL web services with CXF 2.3.0 and referencing >>>> Jetty 7.2.2 libraries. >>>> >>>> This was a purely embedded service/server in my application and used no >>>> external spring configuration, very similar to this popular blog post on >>>> the subject: >>>> >>>> http://aruld.info/programming-****ssl-for-jetty-based-cxf-****services/<http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/> >>>> <http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/> >>>> > >>>> >>>> >>>> public class Server { >>>> >>>> protected Server() throws Exception { >>>> System.out.println("Starting Server"); >>>> String address = "https://localhost:9001/**** >>>> SoapContext/SoapPort <https://localhost:9001/**SoapContext/SoapPort>< >>>> https://**localhost:9001/SoapContext/**SoapPort<https://localhost:9001/SoapContext/SoapPort> >>>> > >>>> >>>> "; >>>> JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean(); >>>> sf.setServiceClass(Greeter.****class); >>>> >>>> sf.setAddress(address); >>>> >>>> Greeter implementor = new GreeterImpl(); >>>> sf.getServiceFactory().****setInvoker(new >>>> >>>> BeanInvoker(implementor)); >>>> >>>> sf = configureSSLOnTheServer(sf, 9001); >>>> org.apache.cxf.endpoint.Server server = sf.create(); >>>> String endpoint = >>>> server.getEndpoint().****getEndpointInfo().getAddress()****; >>>> >>>> >>>> System.out.println("Server started at " + endpoint); >>>> } >>>> >>>> private JaxWsServerFactoryBean >>>> configureSSLOnTheServer(****JaxWsServerFactoryBean sf, int port) { >>>> >>>> try { >>>> TLSServerParameters tlsParams = new TLSServerParameters(); >>>> KeyStore keyStore = KeyStore.getInstance("JKS"); >>>> String password = "password"; >>>> File truststore = new File("certs\\cherry.jks"); >>>> keyStore.load(new FileInputStream(truststore), >>>> password.toCharArray()); >>>> KeyManagerFactory keyFactory = >>>> KeyManagerFactory.getInstance(****KeyManagerFactory.** >>>> >>>> getDefaultAlgorithm()); >>>> keyFactory.init(keyStore, password.toCharArray()); >>>> KeyManager[] km = keyFactory.getKeyManagers(); >>>> tlsParams.setKeyManagers(km); >>>> >>>> truststore = new File("certs\\truststore.jks"); >>>> keyStore.load(new FileInputStream(truststore), >>>> password.toCharArray()); >>>> TrustManagerFactory trustFactory = >>>> TrustManagerFactory.****getInstance(****TrustManagerFactory.** >>>> getDefaultAlgorithm()); >>>> trustFactory.init(keyStore); >>>> TrustManager[] tm = trustFactory.getTrustManagers(****); >>>> tlsParams.setTrustManagers(tm)****; >>>> >>>> FiltersType filter = new FiltersType(); >>>> filter.getInclude().add(".*_****EXPORT_.*"); >>>> filter.getInclude().add(".*_****EXPORT1024_.*"); >>>> filter.getInclude().add(".*_****WITH_DES_.*"); >>>> filter.getInclude().add(".*_****WITH_NULL_.*"); >>>> filter.getExclude().add(".*_****DH_anon_.*"); >>>> tlsParams.****setCipherSuitesFilter(filter); >>>> >>>> ClientAuthentication ca = new ClientAuthentication(); >>>> ca.setRequired(true); >>>> ca.setWant(true); >>>> tlsParams.****setClientAuthentication(ca); >>>> JettyHTTPServerEngineFactory factory = new >>>> JettyHTTPServerEngineFactory()****; >>>> factory.****setTLSServerParametersForPort(****port, >>>> tlsParams); >>>> >>>> } catch (KeyStoreException kse) { >>>> System.out.println("Security configuration failed with the >>>> following: " + kse.getCause()); >>>> } catch (NoSuchAlgorithmException nsa) { >>>> System.out.println("Security configuration failed with the >>>> following: " + nsa.getCause()); >>>> } catch (FileNotFoundException fnfe) { >>>> System.out.println("Security configuration failed with the >>>> following: " + fnfe.getCause()); >>>> } catch (UnrecoverableKeyException uke) { >>>> System.out.println("Security configuration failed with the >>>> following: " + uke.getCause()); >>>> } catch (CertificateException ce) { >>>> System.out.println("Security configuration failed with the >>>> following: " + ce.getCause()); >>>> } catch (GeneralSecurityException gse) { >>>> System.out.println("Security configuration failed with the >>>> following: " + gse.getCause()); >>>> } catch (IOException ioe) { >>>> System.out.println("Security configuration failed with the >>>> following: " + ioe.getCause()); >>>> } >>>> >>>> return sf; >>>> } >>>> >>>> public static void main(String args[]) throws Exception { >>>> System.out.println("The server's security configuration will >>>> be >>>> done programatically."); >>>> System.out.println(); >>>> new Server(); >>>> System.out.println("Server ready..."); >>>> >>>> Thread.sleep(5 * 60 * 1000); >>>> System.out.println("Server exiting"); >>>> System.exit(0); >>>> } >>>> } >>>> >>>> This all worked fine, but at some point our Jetty .jars were upgraded to >>>> Jetty 7.5.4 and now I get things like this: >>>> >>>> FAILED org.eclipse.jetty.http.ssl.****SslContextFactory@4711581a#** >>>> >>>> FAILED: >>>> java.io.FileNotFoundException: C:\Users\<user>\.keystore (The system >>>> cannot >>>> find the file specified) >>>> java.io.FileNotFoundException: C:\Users\<user>\.keystore (The system >>>> cannot >>>> find the file specified). >>>> >>>> Clearly it is looking in the default keystore location. I copied my >>>> keystore file to that location just to verify and it locates it fine but >>>> then creates an error stating keystore password cannot be null. >>>> >>>> Clearly it seems as though the TLS parameters are not being recognized >>>> by >>>> the embedded Jetty server which is started using 7.5.4 instead of 7.2.2. >>>> >>>> Does anyone have an idea where to start or how I might have to ammend my >>>> code to make it work with Jetty 7.5.4 embedded version instead of 7.2.2? >>>> Keep in mind I am not using Spring/configuration files of any kind. >>>> It >>>> is >>>> all via code as shown. >>>> >>>> Thanks, >>>> Chris >>>> >>>> >>>> >
