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.
Self-signed certificates are fine for Joe-Hobby website, but when you're about to enter a credit card number online it's assuring to see that the SSL cert is signed by a real organization and not "l33t_d00d@hotmail.com"
Trolling is a art,
saying that your certificate is expired or not yet valid...except that it is...you need to go here.
On one of our customers' systems (IIS). Turns out they had already installed the new Verisign intermediate certificate but had not removed the old one. IIS happily used the old one...
Lesson: if the certificate expired yesterday, remove it from IIS and then reboot the thing.
Ceci n'est pas une signature
Well, not the Oracle database directly... But Oracle sent out a memo that certain Oracle products (Oracle Wallet Manager, in particular) would simply cease to function properly until the user upgraded their Verisign certificate(s).
I can't find ANY info on Oracle's website about this, though. The memo was sent to Oracle Premium Support customers but I don't know if the info has been generally distributed.
Woops!
I have installed and still occasionally play the dos version of Duke Nukem(and of course doom) on an XP machine. I just had to change the compatibility mode on the executable. Compatibility mode is the only reason I upgraded to XP from 2000.
I received the following email yesterday: Oracle Corporation has been notified by Sun that the set of VeriSign Class 2 and Class 3 Certificates used in Oracle products will be expiring on January 7, 2004. Please review MetaLink Doc 260332.1: Expiration of VeriSign Class 2/Class 3 Certificates on Jan 7,2004 for detail information.
I use Instant SSL cheap, good service and I haven't seen any compatibility issues.
Thawte - cheaper than Verisign, much easier to work with them, and will work fine in any 4.0+ browser.
Because of the crl problems, Explorer has been acting slowly doing some seemingly unrelated activities. Copying or right-clicking on folders often is followed by a several second hang. To workaround, deselect "Check for publisher's certificate revocation" under the Advanced setting for IE (even though it is not IE running, that's where the setting should be changed). After this, no more Explorer hangs. Hope this helps someone. If you know why Explorer is checking crls for anything when doing a copy operation on files, please post.
There's software out there so anyone can sign a certificate. Who needs the suits at Verisign?
Because a cert signed by you is useful for nothing more than "This conversation is encrypted, and I say I'm me." A cert signed by a Verisign translates to "This conversation is encrypted, and Verisign says I'm me."
What good is that? Well, not much among geeks, we don't trust Verisign further than we can throw them, but we're depending on them to keep this silly DNS thing going. However, web browsers are set with a default list of trusted "Certificate Authorites" who are allowed to sign certificates. Companies who are on those lists can sign a certificate that'll work without errors, anybody else's certificate will prompt a message indicating that the name's right, the time's valid, but the issuing authority isn't on the list of authorities you trust. (You can manually add a new authority if you want... but try convincing users to do that!)
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.
To get Word and Excel to start working again:
Open Nortons Control Panel - this might take
a few minutes while it is broken but it
will come up eventually. Under the Miscellaneous
Section of Anti Virus, deselect the Enable Office
Plug-in.
That will not fix any general slowness in Norton,
but it will allow you to read your Word/Excel
documents.
Uh, Thawte is owned by Verisign, smart guy...
But they are a lot cheaper for some reason... Go figure...
Very nice of them to.. I don't know.. let someone know before today. We spent a ton of staff time this morning trying to figure out why we could connect to our servers but not the payment engines via ssl. 4 hours later we figured it out.
= fs alert%2F57436n dors/exp-gsid-s sl.html
Couple of nice links.
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc
http://www.verisign.com/support/ve
Just three more hours seapeople and you can finally take me away from this crappy God Damned planet full of hippies
If you have enabled "Make this directory available off-line" in W2K or later, Windows will try to access the crl server whenever you delete a file... thus adding to the self-DDOS.
Depending on how you have your server configured, it either means you are accepting revoked certificates, or are UNABLE to accept ANY certificates.
The default for some web servers is that if the CRL is unavailable, it will reject ALL presented certs.
I'm guessing that this Denial of Service effect is largely due to the known scalability problems with X.509 CRLs. In a mature Public Key Infrastructure (PKI), about 1 in 6 certificates is revoked. A CRL is around 20-30 bytes in length for every revoked certificate.
That means that if you've issued 250,000 certificates, you can expect to have a CRL of about 1MB.
This aggregate information isn't bad for some back-end processing, but when a lot of clients try to grab the CRL, you can quickly saturate even a high-end 100Mbps hosted server farm.
Virtually every serious large-scale PKI (including VeriSign and Microsoft) is moving to OCSP to replace CRLs since each client will retrieve ~1kB per status request rather than a full 1MB CRL.
There is a file in the JDK called cacerts.
(find . -name cacerts is your friend), this contains the certificates Java uses when initiating ssl connections.
As of yesterday Sun was still shipping java with the expired 3a certificate.
The way to include the new 3a certificate is to use the keytool command.
The format is somthing like: keytool -v -keystore cacerts -import newcert.pem
The default password for java's cacerts file is "changeit"
VC
ps how many geek points do i get for fixing this last week?
Official GOD FAQ.
Free six-month certificates - these really work, at least for recent versions of IE. I have one installed on the SSL server in my garage. Issued by some good people in Barcelona.
IPSCA
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
Except for the fact that Verisign owns Thawte.
Self-certificates are worthless except when distributed through an existing secure channel. Without a proper certificate, all I know is I'm encrypting the session key with someone's public key, but I don't know whose it is. I might as well send the contents in the clear.
beTRUSTed, which recently purchased Baltimore's CyberTrust and OmniRoot businesses. I used Baltimore's certs all the time to avoid VeriSign.
Digital Signature Trust, a subsidiary of Identrus. I've used their TrustID certs to avoid giving money to VeriSign as well.
Both of the above certificate authorities have their roots in the most current IE and Netscape/Mozilla browsers. Digital Signature Trust does a lot of stuff with banks (being owned by Identrus, which was created by a bunch of banks).
I haven't tried them personally
I have, and we are now actually a reseller for them (although we only "resell" it to the people we host). ChainedSSL (Equifax in Astroturf) has been working hard to switch us over to their certificates. They're trying to spread a bunch of FUD because the InstantSSL certificates have a root that is owned by Baltimore, which has just been bought out. But InstantSSL has much better browser compatibility (something like 99% of all browsers vs. Equifax's 95%).
They generally have very fast turn around, usually you can get the certificates that day if you have your documents in order.
The nice thing is that once you're a reseller, you become responsible for the the validity of the seller, which means that certificates are issued as soon as you submit them.
Karma: Chevy Kavalierma.
I suppose I should have linked. Here is a link:
n load/pages/US-N95.html
http://securityresponse.symantec.com/avcenter/dow
falcontx
It is easier and less detectable to sniff a connection than it is to intercept and modify all data flowing over the connection. Thus a self signed cert is better than nothing, but it does indeed have obvious security failings.
I work at a CNC machine shop and the app that sends programs to the machine broke today because of that. I would have never heard about it if it wasn't for my brother in law, who works for a company running the same application.
The fix was as follows: Open Internet Options, click Advanced tab. Under Security turn off both Check for Server Certificate Revocation and Check for Publisher Certificate Revocation. I think this fix should work for other apps that are affected by the same problem...Thought I'd pass it along.
On a side note, it's pretty scary that this has happened to begin with. What I had to go though was pretty minor since the problem was on one machine, but what about an entire enterprise with an app installed on 1000's of computers that were broken because of this? Because of all this ridiculous "signed app" nonsense, not only are you down, but through proxy Microsoft made you dependant on one of the biggest bastardized companies I know...Verisign. Don't expect this problem to fix itself in a timely manner.
If this is a sign of things to come, Palladium will bring Hell on earth.
-R
A certificate is so named, because the signer has CERTIFIED the holder to be trustworthy.
...] so if one of them says he's confirmed Joe Bloggs' identity, that's good enough for me; (full trust)
You'd think so, wouldn't you? Unfortunately for the sanity of anyone using a certificate architecture, you're wrong.
The certificates issued by Verisign and other Certifying Authorities are more "proof of ID" than anything else; the CA makes no assertions about the trustworthiness of the owner, they just assert that the public encryption key you've just been sent belongs to the same people who own the server you're connecting to.
A typical CA certificate as used in SSL, translated into English:
"We hereby certify that the following RSA key [...] belongs to the owner of shopping.example.com. Signed, Verisign."
When your browser connects to https://shopping.example.com, the server sends you its certificate, and the browser checks Verisign's signature on that certificate. If the server proceeds to steal your credit card number, subscribe you to undesirable mailing lists, etc., that's between you and example.com; it's only Verisign's fault if it turns out they issued a wrong certificate.
PGP uses the same principle: when you sign someone else's key, the statement you're "signing" is something like this:
"The following public encryption key [...] belongs to Joe Bloggs ; I have met Joe and verified the photo on his passport. Signed, pclminion."
GnuPG (and probably PGP) never talks about certificates, only about signatures.
If that certificate is later used to commit a felony, say, credit card fraud, then YOU could be held legally liable, because YOU CERTIFIED that this guy was trustworthy. You were negligent in failing to find out that he wasn't.
The only way you could be held responsible is if it turns out that you were so sloppy about checking Joe Bloggs' ID that you were actually negligent; (i.e. didn't check it at all, or accepted an obviously fake form of ID, or something); in most jurisdictions digital signatures aren't legally binding anyway.
Anyway, this is what the trust mechanism in PGP is for.
[Digression: You can build up a "web of trust" by saying things like:
- I trust [... some people
- these other people: [...] I don't trust so much, but if three different people all say they've confirmed Joe's identity, I'll believe that they're not all conspiring against me, so that's OK too; (partial trust)
- everyone else either I don't know, or I know but don't trust, so I'll ignore what they say when I make my decisions.
(These trust values are a private decision, there's no reason to reveal them to the world.)
end digression]
If you incorrectly sign someone's key, and a third party gets hurt as a result, you could easily argue that it's that third party's fault for trusting your opinion.
Incidentally, you can emulate the "certifying authority" model in PGP by giving full trust to Verisign, Thawte et al, and no trust to anyone else. This is a painfully limiting model compared with the full web of trust, though; to me it looks as though the whole mechanism was designed to make money for certifying authorities.
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.
This is not true, at least for Verisign resellers, like Trustwise in the UK. I renewed two global certs 5 months ago and was not told.
That's not such a big shock... As somebody else pointed out, root certs NEED an expirey date. What throws me is that Verisign seems to be acting like this broadsided them. How many million people using their certs, and crl.verisign.com resolves to two IP addresses??? I figure that they've got enough money coming in off of this business that they should have been able to afford to put a machine on a good number of major networks out there. I mean, aren't things like this why people are supposedly paying them $150+ a pop for certs?
The other thing to do to aleviate this problem would have been in software design. If software is designed to go automagically looking for replacement certs, it should be designed to go on a random date before the cert expires.. That way the network hit would have been distributed over the few months instead of over the last few hours.
Free Software: Like love, it grows best when given away.