After spending a morning reading reams of WebLogic Server 10.3 documentation, I was delighted to discover that configuring your WebLogic Server 10.3 to serve an application via HTTPS/SSL is just a few mouse clicks. Nice :-)
As such this is a short(ish) post to document my own findings, which may be useful to other readers. Usual disclaimer, your mileage may vary. I've yet to test this in a production environment, though I can confirm I've used a packet sniffer to ensure the relayed data is encrypted (well, at least not readable by me, so I assume it's encrypted ;-)
The following describes the steps to get this going.
Assumptions
For this post the assumed environment is as follows: an internal Window server "oberon.sagecomputing.com.au" running a WLS installation in production mode configured with 2 WLS domain servers:
http://oberon.sagecomputing.com.au:7002/BookTraining
Note the 7002 port number of the AdfServer and default HTTP protocol (not HTTPS).
I'm also using the WLS demo identity keystore and demo trust keystore for development/testing purposes. For production neither of these keystores are appropriate, and you will need to learn how to obtain and configure new digital certificates/keystores.
Enabling SSL under WLS 10.3
Steps to configure WLS for SSL:
1) Open the WLS console
2) Select from the Domain Structure -> (your domain) -> Environment -> Servers
3) Select the server from the Summary of Servers page you wish to configure for SSL.
4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).
5) If WLS is running in production mode, select the Lock & Edit button.
6) Select the SSL Listen Port Enabled checkbox, and enter your preferred port in the SSL Listen Port.
7) Press the Save button.
8) If WLS is running in production mode, select the Release Configuration button.
Now to access my running app using SSL (say configured port 7005), I'd use the following URL:
https://oberon.sagecomputing.com.au:7005/BookTraining
Note the HTTPS protocol and the SSL port 7005, as separate to the original HTTP protocol on port 7002.
Browsers are our enemy
As I'm running with the WLS demo keystores, any browser access to this URL will raise a security error. For example in Internet Explorer 7 you'll see something like the following:
For development and testing purposes you can pretty much ignore this issue and just accept "Continue to this website". However for production purposes as indicated earlier you should not use the WLS demo keystores.
Once you click "Continue to this website", your application's pages should be served via HTTPS/SSL. Under your browser you should see some sort of notification that the traffic is encrypted with SSL (under Firefox this is the little lock symbol bottom right of your browser).
Disabling non-SSL under WLS 10.3
Once you have SSL up and running, you may decide you no longer want to serve unsecure content from your WLS server. To disable non-SSL traffic follow these steps:
1) Open the WLS console
2) Select from the Domain Structure -> (your domain) -> Environment -> Servers
3) Select the server from the Summary of Servers page you wish to configure for SSL.
4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).
5) If WLS is running in production mode, select the Lock & Edit button.
6) Unselect the Listen Port Enabled checkbox (not the SSL Listen Port Enabled checkbox).
7) Press the Save button.
8) If WLS is running in production mode, select the Release Configuration button.
Access to the original URL via port 7002 http://oberon.sagecomputing.com.au:7002/BookTraining now raises a forbidden access error.
Application architecture versus WLS SSL configuration
As readers will know, within a WLS installation it has the concept of a server. Each WLS domain can have 1 or more servers as per my example above where I had the default AdminServer and a separate AdfServer (let's refer to these as a WLS domain server, as separate to a host server in order not to get confused). Given the understanding above of turning SSL on/off for a WLS domain server, this implies if you want both protected and non protected content in your application, you will need to configure one domain server with SSL turned off, and another domain server with SSL turned on, followed by deploying your separate unsecure and secure content to the respective domain server.
This does present an issue for JDeveloper JSF derived applications, because it dictates a JSF application with both secure and unsecure content will need to be split across domain servers. As a split JSF application cannot easily share state (though the new remote task flows and bookmarkable URLs supported by JDeveloper 11g's JSF-ADF Controller provide solutions to this problem), this constraint should be considered when architecting your JSF application. However this is probably a non-issue for most applications as typically all content is secured or unsecured, not a combination of both.
Troubleshooting
Initially under Firefox 3 if I didn't use the full URL of the server such as:
https://oberon:7005/BookTraining
rather than:
https://oberon.sagecomputing.com.au:7005/BookTraining
.... I would receive the following 502 HTTP proxy error raised by the local MS ISA Proxy Server:
"HTTP 502 Proxy Error - The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. (12204) Internet Security and Acceleration Server"
Yet the error didn't happen under IE7. Why was Firefox hitting our proxy server (which only allows SSL via port 443), yet IE7 wasn't?
It turns out that IE7 has some magical mechanism to work out local servers and exclude the proxy when talking to them (ie. a mechanism which I didn't care to investigate ;-), while Firefox 3 only had a proxy exclusion for servers ending with sagecomputing.com.au. As such https://oberon always hits the ISA proxy. This is simply solved by either addition of the oberon server name to the Firefox proxy exclusion list, or specifying the full URL in the browser.
As such this is a short(ish) post to document my own findings, which may be useful to other readers. Usual disclaimer, your mileage may vary. I've yet to test this in a production environment, though I can confirm I've used a packet sniffer to ensure the relayed data is encrypted (well, at least not readable by me, so I assume it's encrypted ;-)
The following describes the steps to get this going.
Assumptions
For this post the assumed environment is as follows: an internal Window server "oberon.sagecomputing.com.au" running a WLS installation in production mode configured with 2 WLS domain servers:
- AdminServer port 7001 (default)
- AdfServer port 7002
http://oberon.sagecomputing.com.au:7002/BookTraining
Note the 7002 port number of the AdfServer and default HTTP protocol (not HTTPS).
I'm also using the WLS demo identity keystore and demo trust keystore for development/testing purposes. For production neither of these keystores are appropriate, and you will need to learn how to obtain and configure new digital certificates/keystores.
Enabling SSL under WLS 10.3
Steps to configure WLS for SSL:
1) Open the WLS console
2) Select from the Domain Structure -> (your domain) -> Environment -> Servers
3) Select the server from the Summary of Servers page you wish to configure for SSL.
4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).
5) If WLS is running in production mode, select the Lock & Edit button.
6) Select the SSL Listen Port Enabled checkbox, and enter your preferred port in the SSL Listen Port.
7) Press the Save button.
8) If WLS is running in production mode, select the Release Configuration button.
Now to access my running app using SSL (say configured port 7005), I'd use the following URL:
https://oberon.sagecomputing.com.au:7005/BookTraining
Note the HTTPS protocol and the SSL port 7005, as separate to the original HTTP protocol on port 7002.
Browsers are our enemy
As I'm running with the WLS demo keystores, any browser access to this URL will raise a security error. For example in Internet Explorer 7 you'll see something like the following:
For development and testing purposes you can pretty much ignore this issue and just accept "Continue to this website". However for production purposes as indicated earlier you should not use the WLS demo keystores.
Once you click "Continue to this website", your application's pages should be served via HTTPS/SSL. Under your browser you should see some sort of notification that the traffic is encrypted with SSL (under Firefox this is the little lock symbol bottom right of your browser).
Disabling non-SSL under WLS 10.3
Once you have SSL up and running, you may decide you no longer want to serve unsecure content from your WLS server. To disable non-SSL traffic follow these steps:
1) Open the WLS console
2) Select from the Domain Structure -> (your domain) -> Environment -> Servers
3) Select the server from the Summary of Servers page you wish to configure for SSL.
4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).
5) If WLS is running in production mode, select the Lock & Edit button.
6) Unselect the Listen Port Enabled checkbox (not the SSL Listen Port Enabled checkbox).
7) Press the Save button.
8) If WLS is running in production mode, select the Release Configuration button.
Access to the original URL via port 7002 http://oberon.sagecomputing.com.au:7002/BookTraining now raises a forbidden access error.
Application architecture versus WLS SSL configuration
As readers will know, within a WLS installation it has the concept of a server. Each WLS domain can have 1 or more servers as per my example above where I had the default AdminServer and a separate AdfServer (let's refer to these as a WLS domain server, as separate to a host server in order not to get confused). Given the understanding above of turning SSL on/off for a WLS domain server, this implies if you want both protected and non protected content in your application, you will need to configure one domain server with SSL turned off, and another domain server with SSL turned on, followed by deploying your separate unsecure and secure content to the respective domain server.
This does present an issue for JDeveloper JSF derived applications, because it dictates a JSF application with both secure and unsecure content will need to be split across domain servers. As a split JSF application cannot easily share state (though the new remote task flows and bookmarkable URLs supported by JDeveloper 11g's JSF-ADF Controller provide solutions to this problem), this constraint should be considered when architecting your JSF application. However this is probably a non-issue for most applications as typically all content is secured or unsecured, not a combination of both.
Troubleshooting
Initially under Firefox 3 if I didn't use the full URL of the server such as:
https://oberon:7005/BookTraining
rather than:
https://oberon.sagecomputing.com.au:7005/BookTraining
.... I would receive the following 502 HTTP proxy error raised by the local MS ISA Proxy Server:
"HTTP 502 Proxy Error - The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. (12204) Internet Security and Acceleration Server"
Yet the error didn't happen under IE7. Why was Firefox hitting our proxy server (which only allows SSL via port 443), yet IE7 wasn't?
It turns out that IE7 has some magical mechanism to work out local servers and exclude the proxy when talking to them (ie. a mechanism which I didn't care to investigate ;-), while Firefox 3 only had a proxy exclusion for servers ending with sagecomputing.com.au. As such https://oberon always hits the ISA proxy. This is simply solved by either addition of the oberon server name to the Firefox proxy exclusion list, or specifying the full URL in the browser.
3 comments:
Hey Chris,
For completeness this is the same actions but from WLST:
def enableSSL():
print("Trying to cd")
cd('/Servers/DefaultServer')
create ('DefaultServer', 'SSL');
cd('SSL/DefaultServer')
set('Enabled' , 'True')
set('ListenPort', 7005)
try:
enableSSL()
finally:
dumpStack();
print('Done executing the script')
If memory serves me right you can do set('Enabled',false) before the second CD to disable the normal port. This script is actually taken from a template I put together for our automated tests. Turns out they are quite easy to put together.
Right back to business,
Gerard
Thanks Gerard.
To set the normal port, it looks like the command is set('ListenPortEnabled','False')
CM.
Whoops, sorry I think you are right.
Gerard
Post a Comment