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
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.
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.
It can be found here.
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
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.
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.
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.
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.