According to the Sun alert Nr 57436

( see: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436
)

the Verisign Level 2,3 root certificates wil expire on January the 7th
2004.

The implications are that signed code can not be verified anymore and
that the JRE is not able to establish an SSL connection if the default
security provider is being used.

May be I am wrong, but I think, that the implications of this are
somehow being overseen by the majority of java developers and system
administrators.

I think, that there will be a tremidous number of systems which will
be affected by this expiration. The users of this systems may very
well overread the tiny alert on sun's site, or not even consider
looking there untill January the 7th.

I would like to discuss this topic and to see my view of the
implications being prooved wrong, since the implication from my point
of view is, that numerous systems will fail to comply with their
duties on 7th January and will through exceptions instead.

Especially the users of application servers who rely on handling the
SSL connections through the JSSE and not outsource such duties to the
apache or any other HTTP server may see their machines fail.

so long...
Boris Gruschko

Boris Gruschko wrote:
<snip>
> I would like to discuss this topic and to see my view of the
> implications being prooved wrong, since the implication from my point
> of view is, that numerous systems will fail to comply with their
> duties on 7th January and will through exceptions instead.
> 
> Especially the users of application servers who rely on handling the
> SSL connections through the JSSE and not outsource such duties to the
> apache or any other HTTP server may see their machines fail.
<snip>

Before pulling a Chicken Little, let's see what Sun has to say:

"It is highly unlikely that you will encounter a web site with a SSL
server certificate that is a subordinate certificate of the expiring
Class 3 Verisign PCA root certificate. In addition, Java applications
and applets signed after August 2002 should not be signed by a code
signing certificate that is a subordinate certificate of the expiring
Class 3 Verisign PCA root certificate."

So how many sites can we realistically expect to go dark? It should
also be noted that Verisign is only one of many root CAs. My certs
are signed by Thawte, for example.
Further, most certificates have a validity period of one year. You
have to renew on an annual basis and so will always be using the most
up-to-date root certificate available.
I would also expect that those sites affected will have received an
e-mail (or six) warning them of the implications and offering to re-
sign the certificate.
But that's just my take.

On 21 Dec 2003 07:26:23 -0800, boris@gruschko.org (Boris Gruschko)
wrote or quoted :

>
>the Verisign Level 2,3 root certificates wil expire on January the 7th
>2004.
>
>The implications are that signed code can not be verified anymore and
>that the JRE is not able to establish an SSL connection if the default
>security provider is being used.

they made this same error before. I'd suggest giving up on Verisign.
Try Thawte (even though Verisign owns it).  They are much better
organised and cheaper.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

> they made this same error before. I'd suggest giving up on Verisign.

With 'they' I assume you mean Sun, since this is their mistake.
But, then, shouldn't you urge people to give up on Sun instead?
I don't understand.

> Try Thawte (even though Verisign owns it).  They are much better
> organised and cheaper.

Oh, I see, your post is about bashing VeriSign, not providing 
facts. I'm sorry, my mistake. Won't happen again!

-Hans

In comp.lang.java.security Hans Granqvist <hgranqvistx-google@yahoo.com> wrote:
>> they made this same error before. I'd suggest giving up on Verisign.
>
>With 'they' I assume you mean Sun, since this is their mistake.
>But, then, shouldn't you urge people to give up on Sun instead?
>I don't understand.

Obviously.  The problem lies with Verisign's poor planning.  Sun, like a
number of other suckers^Wvendors, bought Verisign's marketing hook, line,
and sinker.  That aside there's little utility in blaming the victim.

>Oh, I see, your post is about bashing VeriSign, not providing 
>facts. I'm sorry, my mistake. Won't happen again!

The post, like many before it, points out Verislime's shortcomings.
But the facts themselves are clear enough for those who, unlike Hans,
aren't too blind to see.

  <http://groups.google.com/groups?q=verislime&ie=ISO-8859-1&hl=en>

  <http://www.geotrust.com/equifax/>

  <http://www.sslreview.com/content/pricing.html>

  ...

WP

Boris Gruschko wrote:
> According to the Sun alert Nr 57436
> 
> ( see: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436
> )
> 
> the Verisign Level 2,3 root certificates wil expire on January the 7th
> 2004.
> 

Expiring certificates is a recommend best practice in PKI management. 
Now, I don't fully understand the cause of the problem. I think that the 
real problem is that Sun did not included the new version of the PCA 
certificate (with extended length) in any recent release of the JDK/Java 
Plugin. So it seems that the blame is really on Sun. Is this right?

Hopefully, this document shows a "simple" way to get around the problem. 
Still, it is quite possible that January 7th will see a large numbers of 
users and administrators straching their head in front of a security 
warning. Good luck to them.

Regards
David

David Garnier wrote:
> Boris Gruschko wrote:
> 
>> According to the Sun alert Nr 57436
>>
>> ( see: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436
>> )
>>
>> the Verisign Level 2,3 root certificates wil expire on January the 7th
>> 2004.
>>

Just happened to me early this morning .....

First, the 3rd party I was send HTTPS to had to change update their 
Verisign CA certificate. After that was done, I was still getting 
"untrusted server cert chain" .... and doing a 
javax.net.debug=ssl:handshake:data" ... saw that JSSE was complainin 
about the local CA certificate.

Couldn't find any info about this problem on the web ( maybe using the 
wrong keyword search on google ) ... and then finally looked at this 
newsgroup, and lo and behold ... I saw this thread.

After updating the cacerts file as above, things were back to normal.


> 
> Expiring certificates is a recommend best practice in PKI management. 
> Now, I don't fully understand the cause of the problem. I think that the 
> real problem is that Sun did not included the new version of the PCA 
> certificate (with extended length) in any recent release of the JDK/Java 
> Plugin. So it seems that the blame is really on Sun. Is this right?

It is included in 1.4.2_03 and 1.3.1_10 ... anything prior to that, you 
have to do the steps mentioned in the above URL. Every time we move to a 
new JDK release, we have to regresstion test our entire application and 
monitor it for a few days or weeks.

Why did not Sun include  that warning on Java's site ( java.sun.com or 
developer.java.sun.com ) is another question.

Has anyone attempted this fix with the Java Plugin 1.3.0-c?  I am
currently working on a system forced to use the 1.3.0-c plugin and
have applied the fixes at the Sunsolve URL, but they did not work. 
After contacting Verisign, they had us apply the fixes to the machine
that generated the certificate request, regenerate the request, get a
new certificate, and that still did not fix the problem.

   The problem actually appears to be in the Java plugin.  When I view
my certificate using the Java 1.4.2_03 plugin The root certificate
expiration date is correct 9/2/2028.  When I view the certificate
using the Java 1.3.0-c plugin the root certificate expiration date is
1/7/04.

Any ideas??

Andrew Hammer
Ciber, Inc.


noone <noone@noone.org> wrote in message news:<o26Lb.511$Wa.302@news-server.bigpond.net.au>...
> David Garnier wrote:
> > Boris Gruschko wrote:
> > 
> >> According to the Sun alert Nr 57436
> >>
> >> ( see: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436
> >> )
> >>
> >> the Verisign Level 2,3 root certificates wil expire on January the 7th
> >> 2004.
> >>
> 
> Just happened to me early this morning .....
> 
> First, the 3rd party I was send HTTPS to had to change update their 
> Verisign CA certificate. After that was done, I was still getting 
> "untrusted server cert chain" .... and doing a 
> javax.net.debug=ssl:handshake:data" ... saw that JSSE was complainin 
> about the local CA certificate.
> 
> Couldn't find any info about this problem on the web ( maybe using the 
> wrong keyword search on google ) ... and then finally looked at this 
> newsgroup, and lo and behold ... I saw this thread.
> 
> After updating the cacerts file as above, things were back to normal.
> 
> 
> > 
> > Expiring certificates is a recommend best practice in PKI management. 
> > Now, I don't fully understand the cause of the problem. I think that the 
> > real problem is that Sun did not included the new version of the PCA 
> > certificate (with extended length) in any recent release of the JDK/Java 
> > Plugin. So it seems that the blame is really on Sun. Is this right?
> 
> It is included in 1.4.2_03 and 1.3.1_10 ... anything prior to that, you 
> have to do the steps mentioned in the above URL. Every time we move to a 
> new JDK release, we have to regresstion test our entire application and 
> monitor it for a few days or weeks.
> 
> Why did not Sun include  that warning on Java's site ( java.sun.com or 
> developer.java.sun.com ) is another question.

On 8 Jan 2004 16:01:52 -0800, ahammer@ciber.com (Andrew Hammer) wrote
or quoted :

> When I view
>my certificate using the Java 1.4.2_03 plugin The root certificate
>expiration date is correct 9/2/2028.  When I view the certificate
>using the Java 1.3.0-c plugin the root certificate expiration date is
>1/7/04.

Are there perhaps two certs in there?  Verisign used to have problems
with cert matching since they reused something (I forget what now)that
confused the matching logic.

Perhaps what you have to do is examine the entire cacerts file and
pull anything you don't want.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

I work for tech Support at a large bank in Australia,

We were caught completely unaware and are now inundated with calls
from concerned customers - as it closely followed a widespread fraud
issue.

Cheers
FOGAL


boris@gruschko.org (Boris Gruschko) wrote in message news:<abdbdab9.0312210726.ef3fd3@posting.google.com>...
> According to the Sun alert Nr 57436
> 
> ( see: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436
> )
> 
> the Verisign Level 2,3 root certificates wil expire on January the 7th
> 2004.
> 
> The implications are that signed code can not be verified anymore and
> that the JRE is not able to establish an SSL connection if the default
> security provider is being used.
> 
> May be I am wrong, but I think, that the implications of this are
> somehow being overseen by the majority of java developers and system
> administrators.
> 
> I think, that there will be a tremidous number of systems which will
> be affected by this expiration. The users of this systems may very
> well overread the tiny alert on sun's site, or not even consider
> looking there untill January the 7th.
> 
> I would like to discuss this topic and to see my view of the
> implications being prooved wrong, since the implication from my point
> of view is, that numerous systems will fail to comply with their
> duties on 7th January and will through exceptions instead.
> 
> Especially the users of application servers who rely on handling the
> SSL connections through the JSSE and not outsource such duties to the
> apache or any other HTTP server may see their machines fail.
> 
> so long...
> Boris Gruschko

"FOGAL" <google@haeden.net> wrote in message
news:be886497.0401082339.6b82c8df@posting.google.com...
| I work for tech Support at a large bank in Australia,

Not S- G---g-, by any chance?  I dropped their
applet a while ago after receiving some less than
convincing answers in relation to problems with it.

It seemed they did not know some very
rudimentary things about Java and applets, and
that introduced enough doubt about their
competence that I chose not to use it.

| We were caught completely unaware..

Sounding more like them by the second..

| ..and are now inundated with calls
| from concerned customers - as it closely followed a widespread
fraud
| issue.

A _bank_ of all places, should be keeping
abreast of the developments in the technology
they are using.

[ It's not as if they are lacking the money
required to hire 'top-gun' programmers ]

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

"Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote in message
news:0dzLb.3014$Wa.2512@news-server.bigpond.net.au...
> "FOGAL" <google@haeden.net> wrote in message
> news:be886497.0401082339.6b82c8df@posting.google.com...
> | I work for tech Support at a large bank in Australia,
>
> Not S- G---g-, by any chance?  I dropped their
> applet a while ago after receiving some less than
> convincing answers in relation to problems with it.
>
> It seemed they did not know some very
> rudimentary things about Java and applets, and
> that introduced enough doubt about their
> competence that I chose not to use it.

Probably a contractor was hired to implement the Java and he/she
is long gone. One of the things enterprises have to do better is
determine their long-term support support requirements for their infrastructure
and ensure they have guaranteed reliable resources to address important
issues like this.

- Mitch Gallant
   MVP Security
   http://pages.istar.ca/~neutron

"Michel Gallant" <neutron@NOSPAMistar.ca> wrote in message
news:%iBLb.107756$BA6.2042189@news20.bellglobal.com...
> Probably a contractor was hired to implement the Java and he/she
> is long gone. One of the things enterprises have to do better is
> determine their long-term support support requirements for their
infrastructure
> and ensure they have guaranteed reliable resources to address important
> issues like this.

The certificate expiration issue has turned into a big fiasco:
http://news.zdnet.co.uk/internet/security/0,39020375,39118996,00.htm
Symantec has blamed VeriSign after support forums were flooded with Norton
AntiVirus users complaining of slow and unstable computers after the latest
virus updates.

Users of the Norton products reported that their PCs locked up or slowed
down after downloading the latest virus definitions on Wednesday and
Thursday. Symantec itself reported that "after January 7th your computer
slows down and Microsoft Word and Excel will not start."
In a statement issued to address the certificate revocation problem,
VeriSign said that since 2001 it had taken steps to notify customers of the
situation and, with each communication, alert them to the expiration date
and steps necessary to obtain a new Intermediate CA.

I've checked the cacerts file and removed the old root certificate.  I
beleive they shared the same public key.  That doesn't solve the
problem.  After some more investigation, I found that the 1.3.0-c
plugin doesn't use the cacerts file to validate root certificates.  It
used the IE Browser's root certificate store.  I tried importing the
new certs in to the IE browser's sotre but that didn't work either.


Roedy Green <look-at-the-website-for-actual-Roedy@mindprod.com> wrote in message news:<t11svvc7sis0rcov45trdvpk4jlk4tt6o9@4ax.com>...
> On 8 Jan 2004 16:01:52 -0800, ahammer@ciber.com (Andrew Hammer) wrote
> or quoted :
> 
> > When I view
> >my certificate using the Java 1.4.2_03 plugin The root certificate
> >expiration date is correct 9/2/2028.  When I view the certificate
> >using the Java 1.3.0-c plugin the root certificate expiration date is
> >1/7/04.
> 
> Are there perhaps two certs in there?  Verisign used to have problems
> with cert matching since they reused something (I forget what now)that
> confused the matching logic.
> 
> Perhaps what you have to do is examine the entire cacerts file and
> pull anything you don't want.

"Mickey Segal" <ignored@example.com> wrote in message
news:3ffeea19$0$6755$61fed72c@news.rcn.com...
> The certificate expiration issue has turned into a big fiasco:
> http://news.zdnet.co.uk/internet/security/0,39020375,39118996,00.htm
> Symantec has blamed VeriSign after support forums were flooded with Norton
> AntiVirus users complaining of slow and unstable computers after the
latest
> virus updates.

Symantec is now directing users:
http://service1.symantec.com/SUPPORT/sharedtech.nsf/docid/2004010810205113
to download a certificate update if needed.  It is not clear how relevant
this suggestion is for most people because absence of the certificates
elsewhere is often the problem.  It looks like there will be a lot of finger
pointing before the dust settles and we get a sense of who messed up here.

On 9 Jan 2004 11:17:40 -0800, ahammer@ciber.com (Andrew Hammer) wrote
or quoted :

>I've checked the cacerts file and removed the old root certificate.  I
>beleive they shared the same public key.  That doesn't solve the
>problem.  After some more investigation, I found that the 1.3.0-c
>plugin doesn't use the cacerts file to validate root certificates.  It
>used the IE Browser's root certificate store.  I tried importing the
>new certs in to the IE browser's sotre but that didn't work either.

how many cacerts files do you have lying around.  Just in case update
them all.

At some point I would suggest announcing that 1.3.0 is broken and
everyone needs to install 1.4.2_03.  

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

No Andrew it wasn't that bank 'WHICH' I work for. To make matters
worse the Customer Service/Tech Support is soooo isolated from the
Techs that these issues take hours to invesitgate and come up with a
solution. Doesn't help being behind a really big ass firewall that
lowly Tech Support Officers can't research the issue themselves.

Anyways its the weekend now so there will be hundreds calling us about
it Monday.


"Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote in message news:<0dzLb.3014$Wa.2512@news-server.bigpond.net.au>...
> "FOGAL" <google@haeden.net> wrote in message
> news:be886497.0401082339.6b82c8df@posting.google.com...
> | I work for tech Support at a large bank in Australia,
> 
> Not S- G---g-, by any chance?  I dropped their
> applet a while ago after receiving some less than
> convincing answers in relation to problems with it.
> 
> It seemed they did not know some very
> rudimentary things about Java and applets, and
> that introduced enough doubt about their
> competence that I chose not to use it.
> 
> | We were caught completely unaware..
> 
> Sounding more like them by the second..
> 
> | ..and are now inundated with calls
> | from concerned customers - as it closely followed a widespread
>  fraud
> | issue.
> 
> A _bank_ of all places, should be keeping
> abreast of the developments in the technology
> they are using.
> 
> [ It's not as if they are lacking the money
> required to hire 'top-gun' programmers ]

"FOGAL" <google@haeden.net> wrote in message
news:be886497.0401091623.3b0a90c7@posting.google.com...
| No Andrew it wasn't that bank 'WHICH' I work for.

;-)

I suppose there all as bad as one another,
I'd previously left that one!

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site