Slashdot Mirror
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.
Unfortunately, unless you buy a cert from one of the officially blessed cert authorities, your users get this ugly-looking "security warning" popup from their browser. While this is fine for clued individuals, or internal sites and so on, things that are public-facing are more sensitive to that sort of thing.
It galls me every time I have to give someone on the officially "blessed CA" list money to do something I can do for myself in less time, but I don't know of an alternative that allows the public users of a secure website to not get alarming messages on their browser when they try to give us money.
unless your an average user who doesn't read certificates anyway, and will just click yes on pretty much everything
this sig is deprecated
I find it particularly disturbing that their solution to too much traffic to their CRL server is to use non-routable addresses in DNS. As a result of this action, they have reduced the integrity of their certificates (yes, that means diluting TRUST, which is the foundation of PKI) by making the revocation lists unavailable. Without CRL checking, Verisign certificates have no inherit integrity advantage over self-signed certificates. This is what we pay for?
Non-authoritative answer:
Name: crl.verisign.net
Addresses: 10.0.0.1, 10.0.0.2, 10.0.0.3, 64.94.110.11
198.49.161.200, 198.49.161.205, 198.49.161.206
Aliases: crl.verisign.com
Go figure.
It is stupid for VeriSign not to have taken the steps necessary to keep their CRL available under these conditions seeing that they get paid a lot of money to do only 2 things:
1) Be trustworthy
2) Be competent
The most unfortunate thing about this. Is that with VeriSign especially, I find them to be one of the _most_ untrustworthy companies on the planet (How many times have they mis-issued certificates now? And lets not forget all the screwups related to their DNS scams). So the question is, who do you go to for certificates? Can't sign your own because users may feel you're insecure (justifiable or not) and can't trust certificates from the "official" CA's, because... well that's like trusting the goverment to make sure you get all your tax deductions whether you knew they were owed you or not ;)
I just really wish I could find an affordable CA that I felt was trustworthy enough themselves as to feel safe making my customers trust their certificates.
I would have to say more users click on "yes" for everything. I have to reinstall several family members computer because of spy/ad ware and a ton of other crap because the click yes to everything.
I didn't use the preview button, so get over it!!!!
Mike
Except the Verisign cert actually translates to "This conversation is encrypted, and I paid Verisign a bunch of money so they'd say I'm me." Verisign does fuck all for identity checking. I'm sure they'd gladly issue an SSL certificate to Santos L Halper, as long as he paid them.
The fact is, this is a huge problem, in that you have to basically pay protection money in order to sell stuff online. SSL certificates should be available from state governments, when you get your "Permit to Make Sales at Retail" and that sort of thing. It wouldn't be that difficult to implement.
Also, someone needs to get together and start a new, free Certificate Authority. Or perhaps a nominal processing fee, like no more than $10. They could easily get their root CA into Mozilla and the other open browsers. Netscape probably wouldn't be terribly difficult. IE would of course be nigh on impossible, but that wouldn't be too terrible, I guess. There are enough huge companies backing Free Software these days that it wouldn't be impossible to convince them to start using this new root CA. After all, a free CA is a logical next step from Free Software, in my opinion. Of course, there's the problem of how to verify that people really are who they say they are, and there's no good way to do that without at least coming in in person. Which is probably why local municipalities are a better choice. Companies have to fill out a bunch of paperwork when they want to get started in an area - it wouldn't be hard to issue certificates then.
The problem is, so many cheapskates have now signed their own certificate that the bogus authority error isn't stopping users since it's so common when nothing's really wrong. As a result, we're seeing a lot of look alike sites use SSL to get the padlock to come up, and users not being phased by the red-flag alerts that this doesn't seem to be the site they think it is.
Calling them cheapskates is a bit harsh. It's like saying "those cheapskates who walked to work instead of buying a Lexus". Personally, I think they're quite right to sign their own certs, explain it to their customers, and help to undermine Verisign's "trust", since it's not really trust anyway. The problem is with the system itself, not that people don't want to prop it up.
There is no sig, there is only Zuul.
"Trusted by 99.3% of current Internet users"
now is it just me or is that a funny statistic?
"...conducting sub $50 transactions (for sites conducting higher value transactions please see InstantSSL Pro or PremiumSSL certificate types)."
I really don't think I should disclose how big my transactions are to this company. It's really none of their business.
What if I'm selling bumper stickers for $5. and some users wants to buy all 12 of the kinds I have? Or is it only per item? If so. I could sell ICs for $1.75 each and just sell them in lots of 50,000 to OEMs.
“Common sense is not so common.” — Voltaire
Hell, where is that l33t_d00d@hotmail.com guy? I'm starting to think he'd be a better person to have in charge of the Internet's core infrastructure than Verisign...
Let's be honest. Who here trusts Verisign? If you trusted them before, do you trust them now?
All this whole ordeal seems to have shown is that Verisign (or in general SSL's) method of verification and validation is completely unscaleable.
Why don't we use a loose-knit network of trust like GPG? We could still have root certificates which are ultimately trusted if the user wants, but would be able to set up little isolated trust networks which wouldn't be crippled by this sort of stupidity.
Karma: It's all a bunch of tree-huggin' hippy crap!
True, but there are far cheaper options still that are effectively as good for 98%+ of the web surfing population. Go to www.ev1servers.net and get a GeoTrust certificate (GeoTrust acquired the old Equifax cert business, and the Equifax root cert is in browsers going back to IE 5.0 and Netscape 4.something I believe). And ev1servers.net will sell you a $150 retail price GeoTrust cert for 49 bucks. You'd have to really want to capture the "wicked old web browsers and Windows 95" market to justify the marginal cost of a Verisign (or Thawte) cert over this (900 bucks for a 128-bit cert from Verisign... lol).
OK, so fair enough about the MS code signing certs, although it's worth pointing out that they were issued because a single particular person failed to follow established protocol in verifying the identity of the cert requester. If they had, the certs wouldn't have been issued.
But as far as today is concerned, umm, excuse me, but VeriSign *has* done their due diligence.
EVERY SINGLE CUSTOMER who renewed their Global/Secure Site Pro SSL certs within the last thirteen months were told, when they received their certs that they also had to update their intermediates. They were given an address to get the intermediate, and instructions. They were told this would happen. VeriSign can't update their shit for them; if they can't fucking read, that's their problem.
And VeriSign can hardly help it if a certain OS manufacturer decides to have its browser do a whole bunch of unnecessary CRL checks which cause every single copy of Explorer to pick *today* to dowload an updated CRL...
It's unbelievable that Verisign...could let their Root Certificate Authority expire, then force its users to [import] the new certificate.
Well, Verisign didn't have much choice in the matter, since all certificates are required to have an expiration date. Every other trusted CA certificate, including Verisign's replacement, is going to expire at some point, potentially causing similar problems (most likely not on the same scale though, as Verisign has become the defacto standard root CA).
I really don't see the relation to the bogus Microsoft code signing certs, as that was a failure by Verisign to confirm the identity of the requestor, whereas the current issue is a matter of the inevitable expiration of a signing certificate. This is not a problem with Verisign's practices or implementation; it's a problem with PKI itself.
Every other trusted CA certificate, including Verisign's replacement, is going to expire at some point, potentially causing similar problems (most likely not on the same scale though, as Verisign has become the defacto standard root CA).
Certificate expiry is not the issue. As you have correctly stated, every certificate will expire. It's how the expiry is handled that is the issue. In this case it was handled poorly. The average end-user doesn't know anything about online security more than, "Is the lock on my browser open or closed?"
You've really hit on the core of my comment with the section I've bolded above. Verisign knows its status and the role it plays in Internet trust and secure transactions. Thousands of users were probably affected by this as some of the stories in this thread allude to. How much did that cost? I suppose that Verisign can be unrepentant when it has a de facto monopoly. It doesn't absolve the IT admins who should have done their jobs better, but Verisign is hardly blameless in this.
As mentioned above, the CRL issue is what keyed me (no pun intended) to the code-signing incident. That was in fact a failure of Verisign's operational policies, procedures, and practices. A single point of failure derailed Verisign's certificates. That's a design flaw. PKI has its fair share of issues, but you can't chalk that one up exclusively to PKI.