Edit: How about we change the title here to "How a 'Catch-22' Revealed Behavioral Differences in Web Browsers".  I have add some updates at the bottom of the story based on feedback from some of our users and further research into SSL validation.

============================

We received a submission yesterday from a user who was complaining about a Catch-22 that Microsoft had set up.  Microsoft Security Advisory (917077) addresses a vulnerability in Internet Explorer and how it handles HTML objects.  The workaround is to change the security setting for ActiveScripting, to either disable it completely or to set it to prompt the user before running each script.  On the advisory's web page, there is a link to this feedback page. The potential issue here is that the feedback page is using ActiveScripting.  Oops  ;-)

Now its not actually that bad for two reasons.  First, if you have changed your ActiveScripting setting to "Prompt", you can enable the scripts for this page.  Second, even if you have disabled ActiveScripting or choose to not allow it for this page, you will see the error message about needing JavaScript for this page and a link to a page with a non-JavaScript form and you will be redirected to the non-JavaScript page.  So while this may be a little annoying, its not a total show stopper.

So after figuring this out in Internet Explorer, I decided to try viewing the page in Firefox.  Pulled up the page and whoops, I got a popup about an error with the SSL certificate verification.



That's odd. It came up ok in Internet Explorer. Let's click on 'Examine Certificate...' and take a look at the details.  Hmm, this certificate is signed by the 'Microsoft Secure Server Authority'.  I bet we don't know who they are.



Let's go click on Tools->Options..., Advanced, View Certificates, Authorities and see what is there.
Nope, don't see any entries for Microsoft certificate authorities.



Let's go back to Internet Explorer and take a look at the certificate information.  Click on the yellow lock icon and we see that the certificate was issued by the 'Microsoft Secure Server Authority'.  Click on the 'Certification Path' tab



So now we see that this certificate was issued by the 'Microsoft Secure Server Authority' which in turn is trusted by the 'Microsoft Internet Authority' which in turn is trusted by a GTE Root CA.



Ok, now let's go look at Internet Explorer's built-in certificates.  Click on Tools->Internet Options..., Content, Certificates..., Intermediate Certification Authorities.  Ah hah!!  Here we see both the 'Microsoft Internet Authority' and the 'Microsoft Secure Server Authority' CA certificates.



So why is this bad?  Microsoft is using an internal CA to issue the SSL certificate for their web site.  Only folks using Internet Explorer to view the page will not get complaints about the certificate.  Anyone using any other browser will get an alert.

Now since this page deals with security (specifically web browser) security, it is counterproductive to the mindset we are trying to train people to have to use an SSL certificate that they can't verify.  If folks just think to them self "Hey this came from Microsoft's security folks, it should be ok" it sets up reinforcement of ignoring SSL certificate errors.

The solution is for Microsoft to either use a certificate from a publicly trusted CA or to have their CA certificates included in other browsers.  Since there are so many alternative browsers, using a publicly trusted CA is probably the best option.

You can export the Microsoft CA certificates from Internet Explorer and import them into Firefox (or another browser) and then you will not see the popup about the server's SSL certificate not being verified.

Update 1:

We received an email from Cesar pointing us to a blog entry here from June 2004 that talks about this issue on another Microsoft web site.  Apparently RFC2459 defines how the Authority Information Access (AIA) 48.2 id-ad-caIssuers OID can be used to included a URL reference where to retrieve information about the certificate.  Internet Explorer uses this information to retrieve the intermediate CA certificates needed to verify the host-specific certifcate.

I happened to have a brand-new laptop here with Windows XP that had not been connected to the network.  I checked it's certificate store and did not see the two intermediate Microsoft certificates.  I then connected to the network and went to the same SSL page on Microsoft's site.  Then I checked the certificate store again and found the two intermediate Microsoft CA certificates were now installed.

So according to the above RFC, Internet Explorer is following a document that is on the Standards Track.  Other browsers such as Mozilla have chosen not to implement this option due to some ambiguity in the RFC.  You can see more discussion about this here in the Bugzilla entry created on this topic. 

It is not clear as to what can be provided through this reference URL and so the Mozilla developers have chosen not to implement it. Apparently Opera, Safari and Konqueror also ignore the AIA data included in a server certificate.