As documented here and here, Java applications that could do SSL two days ago no longer can for many SSL certificates signed by Verisign.

This happened because the root certificates shipping with Java (until _very_ recently) were set to expire January 7, 2004. To fix this, you need to install new Verisign root certificates into your JRE (this is documented in the first link above).

Here's my unhappy story of how I discovered this:

This morning my billing systems emailed me that billing had failed on all my servers. I immediately began research, and pointed my finger at Authorize.net since their SSL certificate that has worked for years now gave me "SSLException: untrusted server cert chain". I figured they had changed their SSL certificate without notifying us. I called Authorize.net and they said they would do what they could on their end, but I probably needed to contact my SSL provider to get an update. I "knew" they were wrong because I don't have an SSL provider for this communication. The support person didn't understand, so I gave up trying to talk to him.

After some more research I found the above links and wondered, "Why couldn't Slashdot or TSS have told me about this before everything broke? :)" But to save others hassle, I'm posting this to both Slashdot and TSS.

Our company was hit by this too.

We are using Webpshere with HP's JVM.

HP-UX users should visit this page:

http://www.hp.com/products1/unix/java/infolibrary/verisign.html

Imagine the tearing of clothes and gnashing of teeth that would be going on if this were a MS problem.

Sartoris: Imagine the tearing of clothes and gnashing of teeth that would be going on if this were a MS problem.

It is a conspiracy. Bill Gates himself is behind it. It's just part of his plan to make Java look bad. And even though .NET did not copy anything at all from Java, all ASP.NET SSL-enabled apps mysteriously stopped working today.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

p.s. The above was not supposed to be serious.

Stop whining, Cameron, please..

Regards
Rolf Tollerud

mark me as noisy please.

i only want to say, sh*t, rolf is still alive.

must everything be a .NET vs Java issue?

I was bitten by this too.. Though the strange thing (with authorize.net alteast) was that after a while it started working again. I don't know if I just hit a better server in their pool, as far as my certificates are concerned, or if they changed something on their end.

Its working now for me, but I'm getting my cacert's updated asap.. Shame there isn't a monitoring tool or something that could check my certs and flag ones close to expiration...

If you are a registered WebLogic user you should have received an alert on Dec. 31, 2003.

For General Information:

http://verisign.com/support/vendors/exp-gsid-ssl.html

For Java:

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

Story on Slashdot

http://slashdot.org/article.pl?sid=04/01/08/1849245

I have did my server "patch" for IBM Http Server 1.3.X with WebSphere 3.5.X and apache web server 2.X.

Verisign Intermediate CA Certificate

Hope it is of some help!!!

Gabriel

Is there a reason why VeriSign would issue certificates whose intermediate cert would expire prior the issued certificate?

wow, did they do that ?

Legally that's even not allowed, any issuing certificate must have an expiration date that completely covers the issued certificate, Certification Authorities are bound by a Certificate Practice Statement that typically describe this

Certificate management implementations on the CA level are often audited, for example to have your root included into IE Microsoft recommends following its WebTrust accreditation program, I don't remember all the details but it would surprise me if this kind of practice (end-users certificates having an expiration date beyond the one of the issuing certificates) would pass those audits _in_theory_.

CA cert expiration dates are chosen based on the estimated security of the underlying crypto algorithm strength, for example RSA (1024b) + SHA1 is said to be /safe/ until 2010, eg. in 1998 it would take an average computer 3 times the age of the universe the brute-force crack the private key (or at least that's what's being told).

Typically new CA certs are generated once the maximum end-user expiration date minus at least 1 time the validation period is reached, so if the CA cert expires in 2010 an end-user cert that is valid for 1 year changes root in 2008-2009, and this goes up to the root, you can see that if this is done for intermediate certs also calculation of the expiration dates must in fact be done with caution.

<Paul Danckaert>
Its working now for me, but I'm getting my cacert's updated asap.. Shame there isn't a monitoring tool or something that could check my certs and flag ones close to expiration...
</Paul Danckaert>

I am sure to have already seen some tools based on OCSP that do this, although OCSP and CRL check for revocation, they are primarily used to check if the private key has been compromised (typical expiration can be checked offline), can't remember where I've seen them though.

regards
Wouter.

>
> wow, did they do that ?
>
> Legally that's even not allowed, any issuing certificate must have an expiration date that completely covers the issued certificate, Certification Authorities are bound by a Certificate Practice Statement that typically describe this

I smell lawsuit...

I don't think the problem is java specific. Same thing happened in out department. Probably just a Verisign cock up. Network support was on the phone to Verisign the whole of yesterday! We have to upgrade most of our Win2k servers with new certificates. Not sure of the details though (I'm a developer not a network support guy)

Cheers

Smythe

What a pain TSS! I've been trying to post for an hour, and I keep getting

  The message body contains invalid HTML (check [a], [b], [u], [i] tags for correctness)

Argh!

I can't just give up, I have to figure out if TSS will accept any part of my message:

http://www.verisign.com/support/site/caReplacement.html

Check the expiration dates on your IE's trusted root certificates. Verisign's commercial software root expires on 1.8.2004 and one of my clients who is exclusively running Microsoft platforms had the same problem with its IIS sites.