I got a blank page. Hooray for badly designed Javascript-only sites!

If you replace the name of the site by some random string you always get that "please try again later".
https://seal.verisign.com/splash?form_file=fdf/splash.fdf&lang=en&dn=www.mkjhsdmfghmksgh.com

Not very serious work from Verisign here.

Also when they publicize than user trust so much more EV than ordinary certificates, that means that EV will become sooner or later a major target for pirates. Until those pirates succeed to destroy that trust.

I get no phishing/malware warning with Firefox 3 Beta 5. Is this correct?

jmdesp: Indeed; it uses the referrer to check, I believe.

EV may well become a target; but getting an EV cert as a phisher is no easy feat. Read the spec. If you find flaws in it, let us know. :-)

bugging: It seems no-one has yet submitted this site to the appropriate phishing lists.

I do not honestly believe that SSL-certificate verification effectively serves any useful purpose for the overwhelming majority of users. Things like DNS spoofing simply do not occur to ordinary people. If typing www.example.com into the browser's address bar brings them to the site, then the site is www.example.com by definition. If further verification is needed, you maybe retype the address and see if it still brings you to the same site.

Frankly, just getting most people to realize that the From: field in an email message can be spoofed is an uphill battle.

I'm not saying that sites shouldn't have SSL certificates, but I don't think that the exact wording of the unverified-cert error message is going to matter all that much in practice. It should probably be better, yeah, but nonetheless, either way, people who understand what it means for a certificate to not belong to the site that is presenting it are going to understand what might be going on, and people who don't aren't.

The number of false alarms also does not help. The overwhelming majority of certificate mismatches are because a server has more than one FQDN and doesn't have a separate cert for each one. Personally I think one cert ought to be able to cover multiple FQDNs for the same server, which might help with that somewhat, though people would still add more domains, especially subdomains, after the issuance. Maybe there could even be a wildcard provision (so that a cert could be good for example.com, *.example.com, example.net, *.example.net, example.org, and *.example.org), but that creates problems of its own. (citibank.example.com is good enough for at least 10% of users to think it's a Citibank website, for instance -- although, example.com had to pay money to get that cert, and it can presumably be revoked, probably without refund, if they abuse it in that manner. Still, it's an important consideration.)

Also, the overwhelming majority of expired-cert warnings are because the user's computer clock is off by n years due to a dead RTC battery on an old motherboard. If the browser is going to be checking dated items for expieration, shouldn't it check to see what the time *really* is? (Granted, how to check that in a manner that can't be subverted is perhaps a non-trivial problem.)

Even without the false alarms, though, you can still only effectively alert people to problems that they're willing to consider as a possibility.