Apex SSL from HTTP server - err 29040

Question

Have apex environment (originally 3.1.2 now 3.2) workiing fine under http server 10.1.3. regular http port 7777.
After going thru the ssl and wallet documentation steps to apply certificates supplied to me, and scouring all the blogs, I'm still failing under https 4443 with:
SSL call to NZ function nzos_Handshake failed with error 29040
The default oracle ewallet.p12 lets me in after first complaining about the certificates. I made a new wallet, with owm, and added in the trusted certs that are suppsoed to match our internal browsers. Thats when things go wrong.
I've tried, and of course bounced opmnctl with stopall, startall after changing each one:
(1) in opmn.xml verified <ssl enabled="true"
(2) auto-logon checked in the wallet with cwallet.sso,
(3) left it off, regen'd wallet and set SSLWalletPassword to it's value,
(4) tried and verified different wallet locations and the right settings in ssl.conf. (feel confident the ssl.conf settings work cause I can cause other errors by commenting out SSLWalletPassword in ssl.conf with auto-logon=off),
(5) SSLVerifyClient set to none
(6) in opmn.xml verified <data id="start-mode" value="ssl-enabled"/>
(7) set LogLevel in httpd.conf to Debug (more output but nothing obviously usefull)
(8) set SSLLogLevel in ssl.conf to debug (more output but nothing obviously usefull)
any ideas would be much appreciated. AND especially does anyone know what the default password is for that default ewallet.p12 ?
if it told me during install I must have missed it. first born for that cause maybe I can modify it and add in my certs ?

Answer 1

Srini, thanks so much for helping. Sorry I didn't reply right off hand. To be honest I couldn't find doc id 473047 in metalink and then I finally got hold of our Certificate group and have been busy with them and just now got things resolved. Thanks again for replying. Really appreciate it.
If anyone else stumbles across this in the future, after having installed just the http server and not knowing much about it, the default pwd to the default wallet is welcome. (be sure and make a copy of this ewallet.p12 in conf/ssl.wlt/default before playing with it). The invalid cipher clues of the 29040 msg were not the direct problem in my case. For me it ended up being incomplete wallet information as the root cause under 10.1.3.
At first we had been just inserting trusted certificates into the wallet thinking that should match our inhouse browser images. Instead the "Warning, this is a development" msg kept showing. Finally we went thru the steps outlined in the documentation, using owm xwindows (or orapki) to create a new wallet from scratch, add a user certificate request, save the wallet, then export the user cert req to a flat file. You can then send that to your internal security group (assuming you have one) or whoever your Cert Authority is. They then send you back a new certificate that should constitute your User Certificate. You must first load in your trusted certificates (usually a Root and Issuing type trusted certs to constitute your "chain"). Then you can do a Import User Cert under owm and load in the afiorementioned fiel recvd from you security group. Also note the ON= value on your request must equal your DNS name as in server.xyz.com Also, I was being sent .key files that I could never import in. They then sent me pem files that had the key info blended in from what I understand and those worked.
I was able to get variations of the 29040 error (290xx) by trying different values within the HTTPD.conf -> ssl.conf file for the various SSL variables. In the end I've ended up with the modified settings of
SSLCipherSuite ALL
SSLProxyCipherSuite ALL
SSLVerifyClient none
SSLProtocol ALL
SSLProxyProtocol ALL
although I suspect other combinations would be fine as well.
The opmn/conf settings were set to the various values as seen in other postings and blogs but in the end did nto seem to be the issue for me. Other than modifying those <port local="6xxx" remote="6xxx" request="6xxx"/> to prevent the opmn logs from filling up fast. To do that I had to try different values that the ones found in some of the main google postings.