SSL and Plugin
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 architecturing 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.
Before your start ask yourself the following questions:
- Will I have SSL setup 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)
- Will I have SSL setup between the WebLogic Plugin and the WebLogic Server?If the answer is Yes – Will I need to “intercept” a client certificate from the first frontend handshake?
- Is it only 1-way SSL that I need? Is it only to encrypt the data between the plugin and the WebLogic Server?
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.
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.conf
file need to be configured:
SSLVerifyClient
SSLVerifyDept
# 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 has not to be (successfully) verifyable. 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. |
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:
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 SSLCACertificateFile
does 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 SSLVerifyClient
require to SSLVerifyClient
none 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
- Open the SunOne console:http://myIPlanet:9995/https-server.beas.com/bin/index
- 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).
- 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.
- 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.
- 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.
- 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 straight forward and as follow:
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.
Go to Security – Install Certificate
- Select Trusted Certificate Authority (CA)
- Specify a Client Root CA name in Certificate Name
- 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:
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 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.
If your 2-way SSL is not working, step back and verify that the 1-way SSL configuration is working. To do this:
- Set Client Auth to OFF
- Restart the server
- 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:
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 Services
error 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.
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:
- Select the root CA (at the top)
- Display it
- Detail and then copy this certificate to a file using the Coded Base 64 X509 option
- Save the file, for example, to “MyWeblogicCAToTrust.cer” (which is a PEM file also)
Plugin Parameters to Consider
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. STRONG Default. The BasicConstraints for V3 CA certificates are checked and the certificates are verified to be CA certificates. 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 to strict conformance to RFC 2459. |
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 SecureProxy parameter 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:
|
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> SecureProxy ON Debug ALL |
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:
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.
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.conf file
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:
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-Cert
to be written to the HTTP header.
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.
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 iIIS server, such as:
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
More explanations around logs & 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 reason it could be import to control them at 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 troubleshooting 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 analyse the log. It should tell you want is wrong.
ERROR 1 – Plaintext data for protocol HTTP was received from peer
(Seen on Apache, iPlanet, and IIS)
<4 juin 2004 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 ON
to 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 RequireSSLHostMatch
false or ensure that the machine name in WebLogicHost
is a DNS name and not an IP. The DNS will still need to match the CommonName
of 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 SSLExportClientCertificates
was 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 Enabled
needs to be selected in the Server – Configuration tab.
This will allow WLS to pick up the header WL-Proxy-Client-Cert and use it.
Attribute |
Description |
Range of Values and Default |
ClientCertProxyEnabled | A value of true causes 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 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 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):
|
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 2004 INFO: SSL certificate chain validation failed: 3015 Mon Jun 7 16:46:32 2004 trusted certs = 0 Mon Jun 7 16:46:32 2004 dumping cert chain Mon Jun 7 16:46:32 2004 commonName is smalbois01 Mon Jun 7 16:46:32 2004 INFO: DeleteSessionCallback Mon Jun 7 16:46:32 2004 ERROR: SSLWrite failed Mon Jun 7 16:46:32 2004 SEND failed (ret=-1) at 719 of file URL.cpp Mon Jun 7 16:46:32 2004 *******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:
- A small lock should appear at the bottom right of the internet browser.
- Double click the lock and go to the certificates path.
- Select the root CA (at the top)
- Display it
- Detail and then copy this certificate to a file using the Coded Base 64 X409 option.
- Save the PEM encoded file and have it used by the TrustedCAFile option.
ERROR 5 – Do I need a 128 bits encryption plugin?
The plugin from BEA 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 ensure it is says 128-bit encryption or less. If it says 128-bit, use the BEA plugin for 128-bit connections. Otherwise don’t.
ERROR 6 – Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate.
When propagating the client certificate, the following issue may occur:
<7 juin 2004 18 h 11 CEST> <Error> <HTTP> <BEA-101257> <Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory. java:97) at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory. java:389) at weblogic.servlet.internal.ServletRequestImpl.setClientCertProxy (ServletRequestImpl.java:301) at weblogic.servlet.internal.ServletRequestImpl.setContext (ServletRequestImpl.java:205) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch (MuxableSocketHTTP.java:460) at weblogic.socket.SSLFilter.dispatch(SSLFilter.java:281) at weblogic.socket.MuxableSocketDiscriminator.dispatch (MuxableSocketDiscriminator.java:284) at weblogic.socket.SSLFilter.dispatch(SSLFilter.java:281) at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:105) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170) > |
Solution
This is a known WLS 8.1 Service Pack 2 issue. It is fixed in 8.1 SP3
ERROR 7 – HTTP 403.7 – Forbidden: Client certificate required – Internet Information Services
IIS gives a HTTP 403.7 - Forbidden: Client certificate required - Internet Information Services
error.
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.
Hey, thanks! I was running into the “SSLCertificateChainFailed” problem in my own set up and I came across your blog and you fixed the problem. Many thanks!
I am glad it helped. SKU
Hi there, just became aware of your blog through Google,
and found that it is really informative. I am going to watch out for brussels.
I’ll be grateful if you continue this in future. Lots of people will be benefited from your writing. Cheers!
Thank you .. I will try to be updated , if time permits .