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.