B
Brian J. Sayatovic
I have a situation where a developer who is no longer available wrote
some code that depends upon a third party's custom key in order to
work. Now, the key expired and new one as been in place.
The old key was their own dummy. It looks as if the developer had
created his own keystore with that key in it. Then, the System
properties were altered to point to this custom file. When that key
was in place, everything worked fine. But now that the new third
party's key is in place, that custom keystore is not allowing us to
connect.
The odd thing is that the third party's new key appears to be rooted
with Verisign. Viewing the key in Internet Explorer, there are three
party's involved:
VeriSign Class 3 Public Primary CA
|__www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
|__(the third party who I'll keep anonymous)
The way I interpret that (and, remember, I'm naive about JSSE) is that
it is a Verisign-trusted certificate. If that is the case, the
standard stores that come with JSSE should trust this key, correct?
It's the whole chain of trust, which in this case leads to Verisign
who should be trusted.
So what I've done is:
(a) tried removing the System property hoping it would fall back to
the default
(b) tried pointing the System property to the 'cacerts' file that
comes with the Java distribution.
Neither of these have worked. The only way I'm able to connect is to
make a new keystore with their new key in it and use that instead of
the old custom keystore. But, since this new key is a Verisign key, I
don't see why this is necessary.
What am I missing here?
Regards,
Brian.
P.S. FWIW, I'm using IBM's 1.3.1 BM on Windows XP and AIX as it comes
with WebSphere 4.0 (including whatever its default JSSE implementation
is).
some code that depends upon a third party's custom key in order to
work. Now, the key expired and new one as been in place.
The old key was their own dummy. It looks as if the developer had
created his own keystore with that key in it. Then, the System
properties were altered to point to this custom file. When that key
was in place, everything worked fine. But now that the new third
party's key is in place, that custom keystore is not allowing us to
connect.
The odd thing is that the third party's new key appears to be rooted
with Verisign. Viewing the key in Internet Explorer, there are three
party's involved:
VeriSign Class 3 Public Primary CA
|__www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
|__(the third party who I'll keep anonymous)
The way I interpret that (and, remember, I'm naive about JSSE) is that
it is a Verisign-trusted certificate. If that is the case, the
standard stores that come with JSSE should trust this key, correct?
It's the whole chain of trust, which in this case leads to Verisign
who should be trusted.
So what I've done is:
(a) tried removing the System property hoping it would fall back to
the default
(b) tried pointing the System property to the 'cacerts' file that
comes with the Java distribution.
Neither of these have worked. The only way I'm able to connect is to
make a new keystore with their new key in it and use that instead of
the old custom keystore. But, since this new key is a Verisign key, I
don't see why this is necessary.
What am I missing here?
Regards,
Brian.
P.S. FWIW, I'm using IBM's 1.3.1 BM on Windows XP and AIX as it comes
with WebSphere 4.0 (including whatever its default JSSE implementation
is).