Oracle WebLogic Server Plug-Ins and SSL

Introduction

This document was created to help users understand their needs when using the WebLogic plugin and SSL. It describes in detail questions to ask when setting up the architecture of the environment. The three web servers that will be used as examples are: Apache, iPlanet (SunOne), and Microsoft IIS.

Prerequisites

Before you start, it is important to understand the handshake process. Refer to the Understanding and Investigating SSL Issues  for information.
Before you start, ask yourself the following questions:

1. Will I have SSL set up between the client and the web server hosting the proxy (Apache, Sun One. IIS)?
   
   If the answer is yes, will it need to be 2-way SSL? This design has the advantage of offering the possibility to propagate client certificates to the back-end WebLogic Server (e.g., for authentication).
    
2. Will I have SSL set up between the plugin and the WebLogic Server?
   
   If the answer is yes, will I need to "intercept" a client certificate from the first front-end handshake?
    
3. Is it only 1-way SSL that I need? Is it only to encrypt the data between the plugin and the WebLogic Server?

Troubleshooting Steps

Configuration of Apache for SSL between the Client (e.g., browser) and the Web Server

Pre-setup

You need to have the following SSL certificates that which will be used to establish the connection:

• Private key certificate
• Public key certificate or server cert
• Certificate Authority (CA)

In the example that follows, these will be named:

• Private key = FrontEndDemoKey.crt
• Public Key = FrontEndDemoCert.crt
• CA = FrontEndCA.crt

For 2-way SSL, another CA file is needed:

• FrontEndCAwithCAClientChainToAuthenticate.crt

This file is the same as the CA FrontEndCA.crt file but contains, concatenated to it, the CAchain it will need to authenticate the client certs in case of 2-way SSL.
Refer to http://www.modssl.org/docs/2.1/ssl_reference.html#ToC13 for more information.

Simple Setup for 1-way SSL

Three properties need to be configured in the Apache httpd.conf file:

• SSLCertificateFile
• SSLCertificateKeyFile
• SSLCACertificateFile.

For example:

# server cert to use
SSLCertificateFile /home2/support/apacheSSL1.3.28/conf/ssl.crt/FrontEndDemoCert.crt
# server private key to use
SSLCertificateKeyFile /home2/support/apacheSSL1.3.28/conf/ssl.key/FrontEndDemoKey.crt
# CA to use
SSLCACertificateFile /export/home/smalbois/FrontEndCA.crt

Simple Setup for 2-way SSL

In addition to the above 3 properties, the following properties in the Apache httpd.conffile need to be configured:

• SSLVerifyClient
• SSLVerifyDepth

# server cert to use
SSLCertificateFile /home2/support/apacheSSL1.3.28/conf/ssl.crt/FrontEndDemoCert.crt
# server private key to use
SSLCertificateKeyFile /home2/support/apacheSSL1.3.28/conf/ssl.key/FrontEndDemoKey.crt
# CA to use
SSLCACertificateFile /export/home/smalbois/FrontEndCAwithCAClientChainToAuthenticate.crt
# Force 2 way SSL
# none: no client Certificate is required at all
# optional: the client may present a valid Certificate
# require: the client has to present a valid Certificate
# optional_no_ca: the client may present a valid Certificate but does not have to be (successfully) verified.
SSLVerifyClient require
# This directive sets how deeply mod_ssl should verify before deciding that the clients
# don't have a valid certificate. The depth actually is the maximum number of intermediate
# certificate issuers
SSLVerifyDepth 10

It is assumed that the client CAs to be used to authenticate have been extracted. These CAs need to be concatenated to the SSLCACertificateFile.
If the goal is to propagate the client certificate to WebLogic for authentification, consider adding the option:

SSLExportClientCertificates
# SSLExportClientCertificates: Export client certificates and the certificate chain
# behind them to CGIs. The certificates are base 64 encoded in the
# environment variables SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAIN_n,
# where n runs from 1 upwards.

Refer to http://www.apache-ssl.org/docs.html for more information.

How to Debug

SSLLog: This directive sets the name of the dedicated SSL protocol engine logfile. Error-type messages are additionally duplicated to the general Apache error log file (directive ErrorLog). Put this somewhere where it cannot be used for symlink attacks on a real server (somewhere where only root can write). For example:

SSLLog     /home2/support/apacheSSL1.3.28/logs/ssl_engine_log

SSLLogLevel: This directive sets the verbosity degree of the dedicated SSL protocol engine logfile. The level is one of the following (in ascending order where higher levels include lower levels):

• none- no dedicated SSL logging is done, but messages of level ``error'' are still written to the general Apache error logfile
• error- log messages of error type only, i.e. (messages which show fatal situations (processing is stopped). Those messages are also duplicated to the general Apache error logfile
• warn- log also warning messages, i.e., messages which show non-fatal problems (processing is continued)
• info- log also informational messages, i.e. messages which show major processing steps
• trace- log also trace messages, i.e. messages which show minor processing steps
• debug- log also debugging messages, i.e. messages which show development and low-level I/O information

For example:

SSLLogLevel info

Test the Configuration and Troubleshoot

To ensure that this first step is working, open a web browser and access the Apache server to see the result:

https://myapache:myport/

1-way SSL Setup

If you get an Internet Explorer window asking if you want to trust the CA, answer yes. A connection should then be established and the Apache welcome page displayed.
If this fails, verify that the following certificates are not expired or corrupted:

• SSLCertificateFile
• SSLCertificateKeyFile
• SSLCACertificateFile

2 way SSL Setup

When you access the Apache server with your browser, a popup box should ask which client certificate in your browser's certs store you want to use.
An empty box means that the SSLCACertificateFiledoes not contain the CA of the client cert you want to use.
If your 2-way SSL is not working, then step back and verify that the one way SSL configuration is working in the first place. To do this, change SSLVerifyClientrequire to SSLVerifyClientnone and retest the URL. If this works, then the issue is with the 2-way SSL configuration. In this case, recheck the client certificate to ensure it is not expired or corrupt.

Configuration of Sun One/iPlanet for SSL between the Client (e.g., browser) and the Web Server

This configuration will use iPlanet WebServer 6.0. The process for setting up the iPlanet WebServer with SSL will be described.

Simple Setup for 1-way SSL

1. Open the SunOne console, for example: http://myIPlanet:9995/https-server.beas.com/bin/index
2. Go to the Security Tab and create a database, if not already created. You will be asked to specify a password (store the password in a safe location).
3. Request a certificate for the server. You will be asked to provide the private key password along with some details for the certificate you will be creating.
4. Send the CSR you receive to an authority to have it signed (you may use Verisign for a free 14 day trial cert to make the test). The signing authority will send you a server certificate.
5. Select install Certificate and copy and paste the PEM encoded file to this certificate. Do not give a name for the certificate as it is for this server.
6. Go to Preferences and Edit Listen Sockets

NOTE: Security must be ON.

NOTE: For 1-way SSL, ClientAuth must be OFF.

Simple Setup for 2-way SSL

To set up the SunOne server it should be straightforward and as followa:

NOTE: Security must be ON.

NOTE: For 2-way SSL, Client Auth must be ON to force the web server to ask for a Client Certificate.

If you are unsure whether the client Root CA was added to the certificate database, extract it from a web browser and have it in PEM encoded format.

1. Go to Security -> Install Certificate
2. Select Trusted Certificate Authority (CA)
3. Specify a Client Root CA name in Certificate Name
4. Specify the appropriate option to add the content of your file to the database

How to Debug

Go to the Logs tab and click View Error Log.

Test the Configuration and Troubleshoot

To ensure that this first step is working, open your web browser and access the SunOne server:

https://mysunone:myport/

1-way SSL Setup

If you get a Internet Explorer window asking if you want to trust the CA, answer "Yes." A connection should then be established and the SunOne welcome page displayed.
If this fails, verify the certificate database (Manage Certificates). For example, click Server-Cert and check the expiration dates. The type for this certificate should be own.

2-way SSL Setup

When you access the SunOne page with your browser, a popup box should sgould display asking which Client certificate in your browser's certs store you want to use.
If the box is empty, it means that the you probably do not have the correct Client Root CA in your database. Refer to Simple Setup for 2-way SSL for more information.
If your 2-way SSL is not working, step back and verify that the 1-way SSL configuration is working. To do this:

1. Set Client Auth to OFF
2. Restart the server
3. Retest the URL.

If this works, the issue is with the 2-way SSL configuration. In this case, verify that the Client certificate is not expired or corrupt.

Configuration of Microsoft IIS for SSL between the Client (e.g., browser) and the Web Server

Pre-setup

First ensure that you have specified an SSL port to your website. (Web Site tab, then SSL Port). This one will be needed for the https requests from your web browser.

Simple Setup for 1-way SSL

You will need SSL certificates for your IIS. Instructions for obtaining SSL certificates for IIS can be found at http://support.microsoft.com/default.aspx?scid=kb;EN-US;290625.
Instructions for getting 1-way SSL up and running on IIS can also be found.

Setup for 2-way SSL

After setting up and testing the 1-way SSL, import your Client Root CA into your certificate store.

• Ignore client certificates will be used for 1 way SSL connections.
• Accept client certificates means that we may use client certs if they are presented to the server but they will not be mandatory.
• Require client certificates means that the client cert has to be presented. Otherwise the connection will be lost.

To import your client root CA, double click the file and install it. You are ready to connect through 2-way SSL.

How to Debug

A common problem for administrators of IIS servers is configuring and troubleshooting SSL enabled websites. To assist in administrators efforts, Microsoft has designed a tool, SSL Diagnostics, to aid in quickly identifying configuration problems in the IIS metabase, certificates, or certificate stores. This tool should allow you to diagnose an SSL issue between the browser and IIS.

Test the Configuration and Troubleshoot

To ensure that this first step is working,open your web browser and access the SunOne server:

https://mysunone:myport/

1- way SSL Setup

If your get a Internet Explorer window asking if you want to trust the CA, answer "Yes." A connection should then be established and show the content of the directory associated with the web site on which you setup SSL.
If this fails, verify that the certificate is not expired or corrupt.

2-way SSL Setup

When you access the IIS website page with your browser, you should see the SSL connection established.
An HTTP 403.7 - Forbidden: Client certificate required - Internet Information Serviceserror means that no client certificate was provided.
It could also mean that the correct Client Root CA wasn't specified or that the browser you used did not have the appropriate client certificate.

Configuration of SSL between the WebLogic Plugin and WebLogic Server

The WebLogic Plugin allows you to connect to a WebLogic instance using 1-way SSL only. You will have to propagate the Client certificate when 2-way SSL is setup on the WebServer (frontend).
In this configuration, it is assumed that you know how to setup SSL on the WebLogic Server. Refer to the Understanding and Investigating SSL Issues Support Pattern Note 1078957.1 for more information.

Verification and Preparation

Before we start configuring the plugin, it is important to figure out whether the WebLogic instance, the plugin will be connecting to, is correctly configured.
To verify this, start your WebLogic Server and ensure that you can connect with your browser. Verify in the configuration of SSL for the WLS server that the client certificate is not enforced. You do not want to force the client authentication this way -- not at the SSL handshake level.
Request a page through SSL (with https) with your browser to ensure that the connection is working. You should be able to see your application or a 404 error (this still means that the transport layer is OK). A small lock   should also appear at the bottom right of the browser.
To prepare the plugin configuration, double click the lock and go to the certificates path:

1. Select the root CA (at the top)
2. Display it
3. Detail and then copy this certificate to a file using the Coded Base 64 X509 option
4. Save the file, for example, to "MyWeblogicCAToTrust.cer" (which is a PEM file also)

Plugin Parameters to Consider

Refer to http://download.oracle.com/docs/cd/E13222_01/wls/docs81/plugins/plugin_params.html#1143241 for more information.

Parameter	Default	Description
EnforceBasicConstraints	Strong	This parameter closes a security hole which existed with SSL certificate validation where certificate chains with invalid V3 CA certificates would not be properly rejected. This allowed certificate chains with invalid intermediate CA certificates, rooted with a valid CA certificate to be trusted. X509 V3 CA certificates are required to contain the BasicConstraints extension, marked as being a CA, and marked as a critical extension. This checking protects against non-CA certificates masquerading as intermediate CA certificates. The levels of enforcement are as follows: OFF This level entirely disables enforcement and is not recommended. Most current commercial CA certificates should work under the default STRONG setting. EnforceBasicConstraints=off EnforceBasicConstraints=false STRONG Default. The BasicConstraints for V3 CA certificates are checked and the certificates are verified to be CA certificates. EnforceBasicConstraints=strong EnforceBasicConstraints=true STRICT This level does the same checking as the STRONG level, but in addition it also strictly enforces IETF RFC 2459 which specifies the BasicConstraints for CA certificates also must be marked as "critical." This is not the default setting because a number of current commercially available CA certificates don't conform to RFC 2459 and don't mark the BasicConstraints as critical. Set this if you want strict conformance to RFC 2459. EnforceBasicConstraints=strict
SecureProxy	OFF	Set this parameter to ON to enable the use of the SSL protocol for all communication between the plug-in and WebLogic Server. Remember to configure a port on the corresponding WebLogic Server for the SSL protocol before defining this parameter. This parameter may be set at two levels: in the configuration for the main server and -- if you have defined any virtual hosts -- in the configuration for the virtual host. The configuration for the virtual host inherits the SSL configuration from the configuration of the main server if the setting is not overridden in the configuration for the virtual host.
TrustedCAFile	none	Name of the file that contains the digital certificates for the trusted certificate authorities for the plug-in. This parameter is required if the SecureProxyparameter is set to ON. The filename must include the full directory path of the file.
RequireSSLHostMatch	true	Determines whether the host name to which the plug-in is connecting must match the Subject Distinguished Name field in the digital certificate of the WebLogic Server to which the proxy plug-in is connecting.
SSLHostMatchOID	22	The ASN.1 Object ID (OID) that identifies which field in the Subject Distinguished Name of the peer digital certificate is to be used to perform the host match comparison. The default for this parameter corresponds to the CommonName field of the Subject Distinguished Name. Common OID values are: Surname -- OID 23 Common Name -- OID 22 Email -- OID 13 Organizational Unit -- OID 30 Organization -- OID 29 Locality -- OID 26

Configuration of Apache for SSL between the WebLogic Plugin and WebLogic Server

How to configure

The configuration below will allow you to connect to the WebLogic Server IP (myIP) at port mySSLPort. Note that the configuration is to be added to the Apache conf file (httpd.conf).
SecureProxy-- ON to force the https protocol with the application server
RequireSSLHostMatch-- OFF as in that example the Subject Distinguished name was not matching
TrustedCAFile-- very important for the configuration and holds the CA of the application server

<Location "/">
SetHandler weblogic-handler
</Location>

<IfModule mod_weblogic.c>
SetHandler weblogic-handler
WebLogicHost myIP
WebLogicPort mySSLPort

SecureProxy ON
TrustedCAFile /user/plugin/MyWeblogicCAToTrust.cer
RequireSSLHostMatch false

Debug ALL
WLLogFile /home2/support/smalbois/LogServer1-1.3.28.txt
</IfModule>

WARNING: If using the WebLogic demo certificates, you may need to turn OFF the EnforceBasicConstraints property.

Verification

To verify that this working properly, make a request to the Apache server, such as:

https://myapache:port/myweblogictestpage.html

NOTE: myweblogictestpage.html is a test page on WebLogic Server.

If your page displays over the WebLogicPort (which is the SSL port of WLS), then the standard configuration is working OK.
There is one more thing that can be done to ensure that you have setup 2-way SSL between your browser. You may want to verify that the client certificate was properly propagated.
To verify this, it is recommended that you install the SnoopServlet.jsp. The SnoopServlet.jsp will show you the client certificate, if it was properly sent. It will be shown in the "Certificate Information" section. If you get

Not using SSL or client certificate not required.

then the client certificate was not propagated. You will have no way to use the client certificate for authentication.
Refer to ERROR 3 -- Client cert not exported to the backend WebLogic Server on Apache for resolution information.

Configuration of Sun One/iPlanet for SSL between the WebLogic Plugin and WebLogic Server

How to configure

The configuration below will allow you to connect to the WebLogic Server IP (myIP) at port mySSLPort.
SecureProxy-- ON to force the https protocol with the application server
RequireSSLHostMatch-- OFF as in that example the Subject Distinguished name was not matching
TrustedCAFile-- very important for the configuration and holds the CA of the application server
This needs to be added to the obj.conffile of SunOne.

<Object name="weblogic" ppath="*/DefaultWebApp/*">
Service fn=wl_proxy WebLogicHost="myIP WebLogicPort="mySSLPort SecureProxy="ON" Debug="ALL" WLLogFile="/home/support/IPlanet60SP5/server/logsupport.txt" TrustedCAFile="/home/support/IPlanet60SP5/TrustedCA.pem" RequireSSLHostMatch="true"
</Object>

Verification

To verify that this working properly, make a request to the iPlanet server, such as:

https://mysunone:port/myweblogictestpage.htm

NOTE: myweblogictestpage.html is a test page on WebLogic Server.

There is one more thing that can be done to ensure that you have setup 2-way SSL between your browser. You may want to verify that the client certificate was properly propagated.
To verify this, it is recommended that you install the SnoopServlet.jsp. The SnoopServlet.jsp will show you the client certificate, if it was properly sent. It will be shown in the "Certificate Information" section. If you get

Not using SSL or client certificate not required.

then the client certificate was not propagated. You will have no way to use the client certificate for authentication.
Unlike Apache, there is no additional configuration to add to the SunOne server to force the WL-Proxy-Client-Certto be written to the HTTP header.
The remaining thing to check to ensure it is read by WLS is to select WebLogic Plug-In Enabled.

Configuration of Microsoft IIS for SSL between the WebLogic Plugin and WebLogic Server

How to configure

It is assumed you know how to configure proxy without SSL. Refer to http://download.oracle.com/docs/cd/E13222_01/wls/docs81/plugins/isapi.html for more information.
The iisproxy.ini file in my example case looks like:

WebLogicHost=myIP
WebLogicPort=mySSLPort
Debug=ALL
SecureProxy=ON
RequireSSLHostMatch=true
TrustedCAFile=D:\IIS\TrustedCACerts\CAWLS.cer
#Proxying by path
WlForwardPath=/
PathTrim=/
WLLogFile=D:\IIS\Logs\WebServerSSL.log

Again, this is the same as the last 2 web servers configuration:
SecureProxy-- ON to force the https protocol with the application server
RequireSSLHostMatch-- OFF as in that example the Subject Distinguished name was not matching
TrustedCAFile-- very important for the configuration and holds the CA of the application server

Verification

To verify that this working properly, make a request to the IIS server, such as:

https://myiis:sslport/myweblogictestpage.html

NOTE: myweblogictestpage.html is a test page on WebLogic Server.

If your page displays over the WebLogicPort (which is the SSL port of WLS), then the standard configuration is working OK. You can verify WLLofFile if there is some doubt.
There is one more thing that can be done to ensure that you have setup 2-way SSL between your browser. You may want to verify that the client certificate was properly propagated.
To verify this, it is recommended that you install the SnoopServlet.jsp. The SnoopServlet.jsp will show you the client certificate, if it was properly sent. It will be shown in the "Certificate Information" section. If you get

Not using SSL or client certificate not required.

then the client certificate was not propagated. You will have no way to use the client certificate for authentication.
No additional properties need to be added to IIS to force it to add the SSL WL-Proxy-Client-Cert header being sent to the WebLogic Server.

Others

Following are more explanations around logs and depending on the plugin version you are using.

What is [WL-Proxy-Client-Keysize]=[128]?

This is meant to exist to let WLS know if the client browser was supporting exportable or domestic cipher strength. For security reasons, it could be important to control them at the WebLogic level.

What is [WL-Proxy-Client-Secretkeysize]=[128]?

WL-Proxy-Client-Secretkeysize gives the number of bits that are secret.

Troubleshooting the WebLogic Plugin and SSL

Before starting to troubleshoot a SSL hanshake issue between the plugin and the WebLogic Server, you need to enable the debug on the plugin and the WLS Server. On the plugin you need the following:

Debug ALL
WLLogFile /user/plugin/mylog.txt

Restart the Apache Server, reproduce the issue and analyze the log. It should tell you what is wrong.

ERROR 1 -- Plaintext data for protocol HTTP was received from peer

(Seen on Apache, iPlanet, and IIS)

<4 juin 2009 15 h 48 CEST> <Warning> <Security> <BEA-090475> <Plaintext data for protocol HTTP was received from peer 172.23.135.56 - 172.23.135.56 instead of an SSL handshake.>

Solution

The plugin was not told that you want SSL communication. Add SecureProxy ONto the plugin configuration.

ERROR 2 -- Host (XXXXX) doesn't match (YYYYY)

(Seen on Apache and iPlanet)

Fri Jun 4 15:51:48 2009 INFO: Host (penelope) doesn't match (88.123.15.201), validation failed
Fri Jun 4 15:51:48 2009 INFO: DeleteSessionCallback
Fri Jun 4 15:51:48 2009 ERROR: SSLWrite failed
Fri Jun 4 15:51:48 2009 SEND failed (ret=-1) at 729 of file ../nsapi/URL.cpp
Fri Jun 4 15:51:48 2009 *******Exception type [WRITE_ERROR_TO_SERVER] raised at line 730 of ../nsapi/URL.cpp
Fri Jun 4 15:51:48 2009 Marking 172.23.135.201:7002 as bad
Fri Jun 4 15:51:48 2009 got exception in sendRequest phase: WRITE_ERROR_TO_SERVER [os error=0, line 730 of ../nsapi/URL.cpp]: at line 2458

Solution

You need to specify RequireSSLHostMatchfalse or ensure that the machine name in WebLogicHostis a DNS name and not an IP. The DNS will still need to match the CommonNameof the certificate if you use the default SSLHostMatchOID. It should appear as:

Fri Jun 4 17:15:48 2009 INFO: Certificate validation succeeded

ERROR 3 -- Client cert not exported to the backend WebLogic Server on Apache

(Seen on all plugins)
I want to propagate my client certificate to WebLogic. I have setup 2-way SSL between the browser and WebLogic Server, and SSL between the plugin and WLS, but it is not working.

Solution

The first thing to do is to verify that SSLExportClientCertificateswas added in the Apache conf file. If you have the Debug ALL option you should be able to see something similar to

Fri Jun 4 17:15:48 2009 Hdrs to WLS:[WL-Proxy-Client-Cert]=[some PEM format certificate]

If the file is being sent to WLS, along with this, you need to ensure the following on the WebLogic Server:
Client Cert Proxy Enabledneeds to be selected in the Server -- Configuration tab.
This will allow WLS to pick up the header WL-Proxy-Client-Cert and use it.
Refer to http://download.oracle.com/docs/cd/E13222_01/wls/docs81/config_xml/Cluster.html for more information.

Attribute	Description	Range of Values and Default
ClientCertProxyEnabled	A value of truecauses proxy-server plugins to pass identity certificates from clients to all web applications that are deployed on all server instances in the cluster. A proxy-server plugin encodes each identify certification in the WL-Proxy-Client-Cert header and passes the header to WebLogic Server instances. Each WebLogic Server instance takes the certificate information from the header, trusting that it came from a secure source, and uses that information to authenticate the user. If you specify true, use a weblogic.security.net.ConnectionFilter to ensure that each WebLogic Server instance accepts connections only from the machine on which the proxy-server plugin is running. Specifying true without using a connection filter creates a potential security vulnerability because the WL-Proxy-Client-Cert header can be spoofed. A value of true overrides the value that each server instance within the cluster specifies with ServerMBean#setClientCertProxyEnabled(boolean). By default (or if you specify false): Each server instance can determine whether its applications trust certificates sent from the proxy server plugin. If a server instance does not set a value for its ClientCertProxyEnabledattribute (or if it specifies false), the weblogic.xmldeployment descriptor for each web application determines whether the web application trusts certificates sent from the proxy server plugin. By default (or if the deployment descriptor specifies false), users cannot log in to the web application from a proxy server plugin.	Admin Console field label: Default: false Secure value: Client Cert Proxy Enabled false

Two Way Client Cert Behavior: Client certs not Requested in the Server -- Keystores & SSL tab.

There is no 2-way SSL between WLS and the plugin so this option must be disabled.
To test the solution, use the SnoopServlet.jsp example delivered with WebLogic. Ensure that when called, the Certificate Information is displayed properly.

ERROR 4 -- SSL certificate chain validation failed: 3015

(Seen on iPlanet)

Mon Jun 7 16:46:32 2009 INFO: SSL certificate chain validation failed: 3015
Mon Jun 7 16:46:32 2009    trusted certs = 0
Mon Jun 7 16:46:32 2009     dumping cert chain
Mon Jun 7 16:46:32 2009        commonName is smalbois01
Mon Jun 7 16:46:32 2009 INFO: DeleteSessionCallback
Mon Jun 7 16:46:32 2009 ERROR: SSLWrite failed
Mon Jun 7 16:46:32 2009 SEND failed (ret=-1) at 719 of file URL.cpp
Mon Jun 7 16:46:32 2009 *******Exception type [WRITE_ERROR_TO_SERVER] raised at line 720 of URL.cpp

Solution

Verify that you have the correct file in TrustedCAFile. If you have the wrong trusted CA to connect to WLS, you will get this exception. To get the trusted CA from WLS, use your web browser and connect to WLS directly on the https port. After you have access to the WLS page:

1. A small lock   should appear at the bottom right of the Internet browser.
2. Double click the lock  and go to the certificates path.
3. Select the root CA (at the top)
4. Display it
5. Detail and then copy this certificate to a file using the Coded Base 64 X409 option.
6. Save the PEM encoded file and have it used by the TrustedCAFile option.

ERROR 5 -- Do I need a 128 bits encryption plugin?

The WebLogic plugin is available in 2 versions: one that does not support 128-bit encryption and one that does.
If you want to find out if you need 128-bit encryption, it is recommended you use your web browser and connect to the WebLogic Server you want to connect to on the SSL port.
After doing so, verify the lock  and check if it says 128-bit encryption or less. If it says 128-bit, use the plugin for 128-bit connections. Otherwise don't.

ERROR 6 -- HTTP 403.7 -- Forbidden: Client certificate required - Internet Information Services

IIS gives a HTTP 403.7 -- Forbidden: Client certificate required - Internet Information Serviceserror.

Solution

This means that no client certificate was provided (the browser used did not have the the appropriate client certificates) or that the correct Client Root CA wasn't specified.