First off, I apologize for taking so long to respond. We had an "all hands on deck" issue late Friday and over the weekend, and I'm only now getting back to normal business...
> Chris, you mention several places you tried to import the cert to. The first two are in JVMs that you say you couldn't get JRun to use, right? No. I'm sorry, my original wording could have been a bit more clear: When I said I could not get a newer JVM to work, what I meant was that 1.6 was the latest version that appears to work - in case someone answered with "1.6 is old, why not use a newer JVM?" JRun is configured to use the JVM that's at C:\Programs\jdk1.6.0\jre , and that one definitely works. There is *NO* JVM directly inside the JRun folder. That is to say that the path you mention - "C:\JRun4\jre\lib\security\cacerts" - does not exist. "jvm.config" has "java.home" set as "C:/Programs/jdk1.6.0" (java.home=C:/Programs/jdk1.6.0)... > Anyway, If you search the JRun folder, you should find C:\JRun4\jre\lib\security\cacerts. THAT is where you want to import the cert to, I'm pretty sure you will find. Then restart JRun, of course, and run your test. As I say, that folder does *NOT* exist. I'm sure that JRun is using the JDK/JRE specified above because I had to install it special to get JRun to start. I used the Java install version that was saved on the server. The install was for the full JDK rather than just a JRE, and consequently I was a bit unsure whether JRun would use the cacerts file from the JDK or the JRE, that's why I imported it in both places. > BTW, with respect to the JVM's you tried to point to, and the jvm.dll error, there could be a number of possible explanations... <snip> ...If it IS a 64-bit machine, I suspect the jdk's you found were 64-bit, not 32-bit. You could install a 32-bit one and point JRun to that, which may work. That's an excellent point about 32 versus 64 bit, and I bet that's exactly why it doesn't work. I tried using the version of Java that is internally distributed by our SCCM, and it unquestionably is 64 bit. I installed the 32 bit JVM specially on my workstation (as mentioned in the previous answer) to match up what is used on the production server. (Luckily the person that originally configured the server included all the install software such that I could replicate the production environment!) > Finally, back to your first issue, if you DO end up getting JRun to use a different JVM, note that you will then need to import the cert into THAT jvm's \jre\lib\security\cacerts file. :-) As I say, I'm sure that JRun is using the JVM found at C:\Programs\jdk1.6.0 . As to whether it uses the cacerts found at the JDK or at the JRE - who knows? But seeing as how I imported the signing certificate in both places, I would have thought it would work. I'm leaning towards just putting a proxy in front of the server. As I said in a different thread, that means ceding control of the SSL to a notoriously unresponsive group, but I'm just not seeing why this doesn't work, and I don't know how much work I'm willing to throw at EOL software. Particularly considering that one of my future tasks is to consume that functionality inside a different program. Thanks for the post though. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/jrun-talk/message.cfm/messageid:5857 Subscription: http://www.houseoffusion.com/groups/jrun-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/jrun-talk/unsubscribe.cfm
