I added an HTTPS connection using certificates to a program I'm working on.
It works fine, but I'm seeing one strange thing and wanted to post it to the JavaRanch to see if anybody else has seen something like this or had any ideas on what I'm doing wrong.
I have two certificates - one good, one bad, and I added Unit tests for each condition. The thing that is odd, is that whenever I need to 'reset' the connection, it doesn't reset properly. If I put the "Good" Certificate Test first then that passes and the "Bad" one fails (it authenticates the certificate when it should throw an exception because it's a 'bad' certificate - it acts as if it's using the previous 'good' certificate).
If I put the "Bad" one first, the "Bad" one fails to authenticate (as expected) and then the good certificate test fails too but it should pass. I've checked my properties and it *looks* like they are being set when I print out their values, but it seems like it's not really over-riding properly on the second test.
Is there a Security Manager thing here at play and I'm not realizing it. Are there problems in over-riding some of the properties?
I added code in both tests to close my connections, I null out the variable pointing to my URL, and I call the garbage collector (I know that doesn't mean it was *really* called, just requested) but I am clueless why it doesn't work.
Has anybody seen anything like this before?
It's not a big deal because I'll just turn off my 'bad certificate' test, but I wanted to know if anybody knew why set-up only worked for the first one.
Thanks in advance if you have any clues on this -
Greg Ostravich ===== Here are some of my code-snippets if that helps, but they do work, just not in sequence one right after the other.
Settings for my keystore fqp is a string with a fully qualified path to my keystore. I checked using File.exists() and it is there.
Here's the code snippet to open (and close) my connection and file stream to test that I authenticated correctly. I pass in the HTTPS url through hostCGIdev.
I encountered exactly the same problem and observed the same results.
However, I found some explanation but have no solution yet. The difference bewteen the first time (SSLSession-1) when you load the certificate keystore file (either valid or invalid) and the second time (SSLSession-2) around is that the trustStore is initialized in the JVM for the first time. And the second time around, even if it a different SSLSession, the trustStore is not initialized (since it was already created by the first one) but will be, nonetheless, used to attempt the second SSL connection. This means that whenever the first certificate was loaded, it will still be active (whether it's good or bad). When you try to make the SSL the second time or the subsequent attempts to load a new certificate, it will always be the same result as the first time around. In other words, if the first time is a good certificate, then all the subsequent certificates (regardless it's good or bad) will be good. Same rule applies to the bad certificate as the first one, all the subsequent attempts (regardless good or bad) will be bad.
That explains why the result was what you saw. However, I don't have a solution for that yet -- I myself is looking for a remedy too. I
I have read some info about the trustStore, and I suspect that I might need to look into the TrustManagerFactory for updating the ketstore dynamically.