I have IIS as a WebServer and WAS184.108.40.206 as an AppServer on Windows2000.
I turned on trace on IIS and run my app as with SSL
the request does not get executed.
and when I look at the IIS log it says GSK_ERROR_BAD_CERT rc=414. It
works fine on http://.. . I searched on IBM Website and found following
fix for WAS4.0 and I applied the fix(Added path variable D:\Program
Files\ibm\gsk5\lib). Still same problem. Any clue what can be the
problem. Below is the IIS log. Here is the site for GSK_ERROR_FIX.
THanks in Advance.
Here is the IIS log:
lib_stream: openStream: Opening the stream
Mon Apr 19 09:19:33 2004 00001570 00001548 - TRACE: lib_stream:
openStream: Stream is SSL
Mon Apr 19 09:19:33 2004 00001570 00001548 - ERROR: lib_stream:
openStream: Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc =
Mon Apr 19 09:19:33 2004 00001570 00001548 - TRACE: lib_stream:
destroyStream: Destroying the stream
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
10 replies Latest Post - 2011-05-20T15:44:23Z by BitBandit
Pinned topic With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS220.127.116.11 AppServer.
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-05-20T15:44:23Z at 2011-05-20T15:44:23Z by BitBandit
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS18.104.22.168 AppServer.2004-08-20T19:24:57Z in response to SystemAdminI've stumbled across the same error message today and after trying many things I'found a solution/workaround.
My configuration is a WAS 5.0 install on Windows. Originally we were using the IBM http server, this was working fine. Unfortunately we needed a module to authenticate securid user which is only available for IIS.
After switching over to IIS http was working fine, but https was not (r_gsk_secure_soc_init message in plugin.log). The solution we found was to delete the https port on the appserver we were using (port 9443 on server1).
It look to me like the iis plugin wants to use ssl to forward requests to the appserver when the incoming connection is ssl. As we did not set up ssl between the plugin and the appserver this failed (although with a unhelpful error message). The http server plugin seems to be more intelligent and to fall back to plain http when ssl is not configured.
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS22.214.171.124 AppServer.2004-10-31T13:14:41Z in response to SystemAdminI had the same problem and the solution is what the previous person posted. In our case we were running WebSphere Portal 5.0.2 on Solaris 9 using an external Sun Java Web Server 6.0 SP 5 (fka iPlanet). When we upgraded to Portal 126.96.36.199 we had this problem. We have two app svrs in a cluster.
Sat Oct 30 14:13:24 2004 0000337a 00000038 - ERROR: ESI: getResponse: failed to get response: rc = 4
Sat Oct 30 14:13:24 2004 0000337a 00000038 - ERROR: ws_common: websphereHandleRequest: Failed to handle request
Sat Oct 30 14:13:25 2004 0000337a 00000038 - ERROR: ws_server_group: serverGroupNextRoundRobinServer: Failed to
find a server; all could be down or have reached the maximimum connections limit
Sat Oct 30 14:13:25 2004 0000337a 00000038 - ERROR: ws_common: websphereFindServer: Failed to find a server
Sat Oct 30 14:13:25 2004 0000337a 00000038 - ERROR: ws_common: websphereWriteRequestReadResponse: Failed to find
The solution was to go to the depl. mgr Under Application Servers > WebSphere_Portal > Web Container >HTTP Transport
deleted port 9091 ssl enabled = false, deleted 9444 ssl enabled = true, deleted 9044 ssl enabled = true (only kept 9081 ssl enabled = false)
So I just kept http transport port 9081 (we don't use SSL between our web and app svrs).
I did this, regenerated the plugin and if worked like a champ. For some reason having the extra http transport ports was not a problem prior to the Portal upgrade to 188.8.131.52. So Prior we had WAS 5.0.2 and after the upgrade we had WAS 184.108.40.206 which when we experienced this problem.
I hope this help, James Stroud
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS220.127.116.11 AppServer.2005-02-03T23:03:37Z in response to SystemAdminI had the same problem has above and the fix described in the proceding posts fixed the problem except that I had to manualy edit my plugin-cfg.xml file.
I'm running WPS5.1 and IBM HTTP 18.104.22.168
Excellent fix guys, thank you
Re: Same problem with portal 6.02007-02-11T03:09:41Z in response to SystemAdminHi all!
Same problem here.
I am using Websphere Portal 6.0, Websphere Application Server 22.214.171.124
What I did though was I removed the "WCInboundDefaultSecure" chain under:
Servers -> Application Servers -> <server name(Websphere Portal in my case)> -> Web container settings -> Web container Transport chains.
I then regenerated the plugin under the servers -> webserver menu and everything worked like a charm!
Difficult problem though because before you could see the fault, trace logging had to be enabled in the plugin.
Strand Interconnect AB
BitBandit 0600016YQ61 PostACCEPTED ANSWER
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS126.96.36.199 AppServer.2011-05-20T15:44:23Z in response to SystemAdminThis solution worked awesome for me - I was having a lot of problem and disabling the SSL between the webserver and the application servers worked.
SysGeeks.com: Remote System Administration and Monitoring
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS188.8.131.52 AppServer.2008-02-21T10:07:56Z in response to SystemAdminHi,
but what to do if I want to have SSL connection from client to IIS , and SSL connection from IIS to Application Server? I 'm actually receiving GSL_ERROR_BAD_CERT ..
sunny.sunny 060001Y4KT1 PostACCEPTED ANSWER
Re: With SSL I get GSK_ERROR_BAD_CERT 414 Error with IIS WebServer- WAS184.108.40.206 AppServer.2009-09-11T18:41:45Z in response to SystemAdminIn WebSphere Application Server 6.1, each profile is created with its unique self signed certificates. All profiles have their own node level key and trust stores. For ND, there is also a cell level key store, CellDefaultKeyStore, and a cell level trust store, CellDefaultTrustStore, which are pointed out by all nodes in default cell settings. To establish a proper SSL configuration in which all nodes (including the dmgr node) can communicate with each other, their default certificates are added to the cell level trust store as signer certificates.
In addition, for SSL to be properly configured between a web server and WebSphere Application Server 6.1, its plugin-key.kdb must include all nodes' default certificates as signer certificates, and web server node's default certificate must exist in the CellDefaultTrustStore considering that a web server also works in a node.
The above is extract from