In this article we will configure 2 weblogic domains, one hosting a webservice working as a "consumer" WS, that we will call ClientDomain.
The other domain, the ServiceDomain, will host a webservice working as a "service" WS. Both webservices are going to exchange information in 2-way SSL.
Keep reading the step by step instructions after the jump:
1. Before we begin
we assume we have 2 physical machines with a vanilla WLS 10.3.3 installation.
We need to create 2 standard Weblogic domains as following:
MachineA: ClientDomain
AdminServer
http listen port: 7001
https listen port: 7002
MachineB: ServiceDomain
AdminServer
http listen port: 7001
https listen port: 7002
2. Configuring Server’s Identity and Trust
Reference: WLS Identity and Trust
In our example, we will use Self Signed Certificates (generated with keytool) for our server’s identity. In a real world example, one would use certificates provided by one on the truested CA.
2.1 Generating the key pair for ClientDomain (Machine A):
a) Go to your domain home, "bin" folder and open a command prompt
b) Run setDomainEnv.cmd(sh)
c) Run the following command:
keytool -genkey -alias client_cert -keyalg RSA -keysize 1024 -keypass keypass123 -keystore ClientIdentity.jks -storepass storepass123
d) Provide the information required by the keytool.
e) A file should be created in your domain home: ClientIdentity.jks
2.2 Generating the key pair for Service Domain (Machine B):
a) Go to your domain home, "bin" folder and open a command prompt
b) Run setDomainEnv.cmd(sh)
c) Run the following command:
keytool -genkey -alias server_cert -keyalg RSA -keysize 1024 -keypass keypass123 -keystore ServerIdentity.jks -storepass storepass123
d) Provide the information required by the keytool.
e) A file should be created in your domain home: ServerIdentity.jks
Both files created are keystores which contains the server’s key pair (a public key and associated private key). The public key is wrapped as a self-signed certificate, which is stored as a single-element certificate chain.
3. Exporting the certificate to a certificate file
3.1 For the ClientDomain:
a) Run the following command: keytool -export -rfc -alias client_cert -file ClientCert.cer -keystore ClientIdentity.jks -storepass storepass123
b) A file should be created on your domain home, ClientCert.cer
3.2 For the ServiceDomain:
a) Run the following command: keytool -export -rfc -alias server_cert -file ServerCert.cer -keystore ServerIdentity.jks -storepass storepass123
b) A file should be created on your domain home, ServerCert.cer
Both files are the exported certificate, created with a printable encoding format, as defined by the Internet RFC 1421 standard, since the -rfc option was specified.
4. Importing the server’s certificate to the trust store
a) Copy the ClientCert.cer from MachineA to MachineB
b) Copy the ServerCert.cer from MachineB to MachineA
c) Save both files to your server’s "BEA_HOME\wlserver_10.3\server\lib" folder, in both MachineA and MachineB.
d) In Machine A, in the same command prompt used in the previous steps, change to "BEA_HOME\wlserver_10.3\server\lib" folder and run the following command:
keytool -import -v -trustcacerts -alias server_cert -file ServerCert.cer -keystore cacerts -storepass changeit
e) In Machine B, in the same command prompt used in the previous steps, change to "BEA_HOME\wlserver_10.3\server\lib" folder and run the following command:
keytool -import -v -trustcacerts -alias client_cert -file ClientCert.cer -keystore cacerts -storepass changeit
Now, both servers are configured to trust each other certificates.
5. Configuring keystores
a) Start Both ClientDomain and ServiceDomain AdminServer’s
b) Go back to you domain home, "bin" folder and run "startWebLogic.cmd(sh)"
c) Do this for ClientDomain and ServiceDomain
d) Once both servers are running, open the admin console by going to:
http://MachineA:7001/console
http://MachineB:7001/console
e) For both domain, go to "Environment > Servers > AdminServer"
f) Click on "Configuration > Keystore" tab
g) Click on the "Change" button for the server keystore
h) Select "Custom Identity and Custom Trust" and click "Save"
i) Fill the information for each domain according to the table bellow (you might need to adjust it to your own paths):
Keystore Settings for ClientDomain
----------------------------------
Custom Identity Keystore: D:\bea\wls1033\user_projects\domains\ClientDomain\ClientIdentity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: storepass123
Custom Trust Keystore: D:\bea\wls1033\wlserver_10.3\server\lib\cacerts
Custom Trust Keystore Type: JKS
Custom Trust Keystore Passphrase: changeit
Keystore Settings for ServiceDomain
-----------------------------------
Custom Identity Keystore: C:\bea\wls1033\user_projects\domains\ServiceDomain\ServerIdentity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: storepass123
Custom Trust Keystore: C:\bea\wls1033\wlserver_10.3\server\lib\cacerts
Custom Trust Keystore Type: JKS
Custom Trust Keystore Passphrase: changeit
6. Configuring SSL for both servers
a) Go to "Configuration > SSL" tab
b) Provide the following information according to the table below:
SSL Settings for ClientDomain
----------------------------------
Private Key Alias: client_cert
Private Key Passphrase: keypass123
Advanced:
Hostname Verification: None (the certificates we created are not bound to a host name, so host name verification would fail. In a real world example certificates are bound to a server's hostname)
Use Server Certs: checked
Two Way Client Cert Behavior: Client Certs Requested and Enforced
SSLRejection Logging Enabled: checked
Leave the other options as default values.
SSL Settings for ServiceDomain
----------------------------------
Private Key Alias: server_cert
Private Key Passphrase: keypass123
Advanced:
Hostname Verification: None (the certificates we created are not bound to a host name, so host name verification would fail. In a real world example certificates are bound to a server's hostname)
Use Server Certs: checked
Two Way Client Cert Behavior: Client Certs Requested and Enforced
SSLRejection Logging Enabled: checked
Leave the other options as default values.
7. Enable SSL logging
This is not really required but is useful for SSL debugging and to understand how the SSL handshake happens on both sides. Do it for both ClientDomain and ServerDomain.
a) Go to Logging > General
b) Rotation Type: None
c) Minimum severity to log: Debug
d) Redirect stdout logging enabled: checked
e) Log file : Severity level: Debug
f) Standard out : Severity level: Debug
g) Click "Save"
h) Go to "Debug" tab, expand "weblogic > security > SSL".
i) Check SSL and click "Enable"
j) Restart both Servers
8. The webservices
a) There are 2 WS provided with this article: HelloServiceEAR.ear and HelloClientEAR.ear
b) Deploy HelloServiceEAR.ear to the ServiceDomain
c) Open "HelloClientEAR.ear/HelloClient.war/WEB-INF/classes/servlets/messages.properties" and edit the file to point to the HelloServiceEAR endpoint address.
d) Save the messages.properties back to the EAR file.
9. The "Service" webservice
a) HelloServiceEAR.ear is a simple webservice that has just one method that returns a String:
@WebService
public class HelloWS {
@WebMethod
public String sayHello() {
return "Greetings from Remote Service !";
}
}
10. The "Client" webservice
a) Deploy HelloClientEAR.ear to ClientDomain.
HelloClientEAR.ear was built using WLS ant task ClientGen.
Reference: WLS Ant Tasks
The ant task is very simple and takes a WSDL URL as parameter:
With the generated stubs, all we need to do is call "Service" webservice inside a Servlet, so we can test our scenario:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
HelloWSService sample = new HelloWSService_Impl();
HelloWS port = sample.getHelloWSSoapPort();
((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, Messages.getString("ClientTest.0")); //$NON-NLS-1$
String res = port.sayHello();
PrintWriter pw = response.getWriter();
pw.print("Remote Server says: "+res); //$NON-NLS-1$
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Note that we set the end point address, in order to point to the correct server / https port of the "Service" webservice.
The String is externalized, but it should be something like:
https://MachineB:7002/HelloService/HelloWS
11. Testing
a) Once both webservices are deployed, go to you ClientDomain testing page. It should look something like:
http://MachineA:7001/HelloClient/ClientTest
b) If everything was properly configured, you should see a message:
Remote Server says: Greetings from Remote Service !
12. Checking the SSL hand shake.
a) If we look at the ClientDomain server logs, we should see the handshake information:
b) If we look at the ServiceDomain server logs, we can see the handshake taking place:
13. Files
HelloServiceEAR.ear
HelloClientEAR
Enjoy!
0 comments:
Post a Comment