Verisign Certificate Expiration Causes Multiple Problems

We had to do a little sleuthing today. Many readers wrote in with problems that turned out to be related. A certificate which Verisign used for signing SSL certificates has expired. When applications which depend on that certificate try to make an SSL connection, they fail and try to access crl.verisign.com, the certificate revocation list server. This has effectively DOS'ed that site, and Verisign has now updated the DNS record for that address to include several non-routable addresses, reducing the load on their servers. Some applications affected include older Internet Explorer browsers, Java, and Norton Antivirus (which may manifest itself as Microsoft Word being very slow to start). Hope this helps a few people, and if you have other apps with problems, please post about them below.

Comments

Unroutable, schmunroutable

[marnanel]

Unroutable addresses? Anyone on private corporate networks which are large enough to use 10.0.0.0/8, who are unfortunate enough to have been allocated the IP addresses 10.0.0.{1,2,3}, may be experiencing a little more network load than usual today as every machine in the place tries to query them.

Why should expired cert => CRL traffic spike??

[Y2]

I'll take the risk of looking stupid and ask the musical question: Why should the expiration of a certificate cause an increase in traffic to a CRL server? Once a certificate has expired its revocation status is irrelevant. Revocation lists exist solely to cancel a key before its certificate expires.

Or is it merely that some software automatically calls the mothership for new information on expiration, and the hostname of the mothership happens to start with "crl"?

(Antidisclaimer: I operate five private CAs and delude myself that I basically understand this stuff.)

Not the first Verisign CRL certificate problem

[securitas]

This vaguely reminds me of the fraudulent Verisign / Microsoft code-signing digital certificates that Verisign issued a few years back.

While not an identical problem, an essential element of why those certificates were potentially harmful was also because of a problem with the CRL checking. Verisign didn't support CRL distribution points in their certificates and you all remember the problems that ensued.

I found security researcher Gene Spafford's comments on the PKI / Verisign issue interesting, which were picked up in Bruce Schneier's Crypto-Gram. Schneier's comments on the incident as well as the Microsoft response are also worth reading.

It's unbelievable that Verisign which claims to be in the business of Internet security and SSL/TLS digital certificates - the dominant company with 95%+ market share - could let their Root Certificate Authority expire, then force its users to effectively patch their systems by importing the new certificate for the root CA after the fact. That's just bad engineering.

Yes, end-users need to take some responsibility for their systems, but PKI and related technologies are complex and not for novices. It's no better than the keep-your patches-updated-and-use-a-firewall comment that Bill Gates made a couple of months ago. That's a bandage, not a solution.

I'm no socialist, but....

[spike2131]

I would love to see the Federal Trade Commission start granting digital certificates for little or no cost. Governments are already responsible for public security, and for granting identification documents such as social security cards and drivers' licenses, and for communications services such as running the postal service and opperating the Do Not Call Registry... why don't they do these things in the digital realm as well?

Mind you, I'm not calling for government regulation of the Internet... and certainly there is no way that government certificates should be in any way a requirement for opperating a secure website. There must still be commercial options available - and I'm sure they would become a lot more reasonably priced in the face of public competition. But if govenments are going to start taxing the Net (which they will), then certifying SSL certificates is the kind of service that they should be giving people in return.

see also Windows Update

[Siva]

I have walked a user through performing the following procedure, and she has reported success with her two machines. She is running Windows 2000 Pro with Office 2000 and NAV 2003 (only 99% sure about the last one).

- goto http://windowsupdate.microsoft.com/
- click Scan for Updates link (may be prompted to accept the ActiveX thing)
- Navigate to the page of non-critical updates (ironic, no?)
- Find the update named something like "Root Certificate Update" or "Root Certificate Authority" (can't remember which)
- Install it
- rejoice at the ability to use MS Word again :P