There have been a number of attacks aimed at SSL Certificates demonstrated at the recent Black Hat event in Las Vegas. VeriSign have confirmed that non of the certificates issued within the VeriSign group are susceptibale to these attacks. This includes RapidSSL , thawte and Geotrust.

This was confirmed on Tim Callans SSL Blog. I have pasted the relevent excerpts below

Use of null Characters

The focus of this presentation was various ways to use null characters to fool browsers and other pieces of relying software into believing a certificate has been issued to a different domain than the one to which is was actually issued. The idea is that the attack would give the online criminal the ability to put up a certificate on what appears to be the exact same domain name as the targeted site. sslstrip accomplishes this feat through a Man-in-the-Middle attack and uses the null-character certificate to create its false certificates on the fly.

I'm pleased to say that none of VeriSign's SSL Certificates on any brand allow null characters, meaning that you can't use any of our certificates in the attack detailed today. While the fundamental problem needs to be solved by the client software that trusts these certificates, we still prefer not to be contributing to the problem. And until these problems are solved at the source, EV SSL is a great interim solution. The detailed attack will not work against EV SSL (as agreed by Mr. Marlinspike during the Q and A session after his talk), which means that sites have the power to defend themselves against null character attacks and in fact all attacks using sslstrip.

MD2 No Longer Secure

Kaminsky covered several topics which had SSL as a common theme. Interestingly, he also revealed his own work with null characters, which was very similar to Marlinspike's. In addition, Kaminsky talked about pre-image attacks against MD2, which he expects to be viable this calendar year. He reports that MD2 is not trusted or soon to not be trusted on these applications and platforms: Firefox, OpenSSL, Red Hat, Opera, Apple, Microsoft, Google, and VeriSign. Here I can be more specific. As of May 2009, VeriSign is issuing its SSL Certificates on all brands using SHA-1.

Leading Zeros

Kaminsky also described a "leading zero attack," by which a certificate can fool client software by essentially attaching an invisible zero to the first hex character in the certificate. Again, I'm happy to tell you that VeriSign won't issue SSL Certificates with leading zeros on any of our brands.

There has been some recent coverage about a security flaw in EV SSL certificates. I think it is worth pointing out the facts (as I see them) of this "flaw". 
 
Firstly there is no security flaw in Extended Validation SSL Certificates. The certificates still function correctly.
 
This flaw is actually a "Man in the middle" attack. It is a fairly common type of attack which has been known for some time. However to be able to attempt the attack there are a number of requirements the attacker needs to fulfil. They must have an existing certificate (this can be a simple domain validated certificate). They must also be able to poison the users DNS records. 
 
The attack is supposed to work by the main domain presenting the EV enabled green address bar for the main site and then the attacker loading iframe content within the website which is secured by a non EV certificate. The iframe content would be controlled by the attacker but the green address bar would still be shown. 
 
To complete the attack the attacker needs to do a number of steps: 
 
The attacker must find a website which utilises an iframe or some form of widget included from a different URL. For example the website https://www.servertastic.com could have an iframe login page loaded from www.mylogin.com (it doesn't this is just an example!)

The attacker would poison the DNS records to point www.mylogin.com to their own webserver. Doing so they could then collect your login data and other information they require. 
 
For this to work the attacker needs to secure the content loaded in the iframe with an SSL certificate so the browser still shows the green address bar from the main frame (www.servertastic.com). This is where I believe the attack does not work. 
 
The attacker would need to obtain a DV certificate for www.mylogin.com which they can not do because they do not own www.mylogin.com. Alternatively they could hijack www.mylogin.com and redirect it to www.attackersdomain.com which they do own and does have a certificate.

But they would still not be able to present a valid certificate for www.mylogin.com and therefore the browser will display a SSL warning error either "mismatched SSL domain", "mixed SSL and non-SSL content" or "redirect to a non-secure SSL warning". 
 
The attack could succeed if the attacker was able to inject code into the EV enabled website (which would make the flaw code based rather than SSL/browser based) or the end user had disabled all the SSL related warnings within their browser. Plus the user would have to be accessing the website via a poisoned DNS cache made possible by an open wi-fi hotspot for example. 
 
Therefore at the moment I do not believe this is a flaw in SSL or browsers. It is just hitting the headlines because it is in relation to EV certificates. If the end user just followed basic security practices such as not accessing unknown internet access points and not disabling the security settings in their browser then this attack should not be possible. 
 
I have not yet seen a demonstration of the "attack" and therefore I may not be understanding the process correctly. Therefore my views may 
be completely incorrect.