Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why doesn't Mozilla (Firefox) like the Microsoft OCA web site?

Why doesn't Mozilla (Firefox) like the Microsoft OCA web site?

  • Comments 27

In my previous post about OCA, the comments thread has a long discussion started by Shannon J Hager about Mozilla’s behavior when you attempt to access https://winqual.microsoft.com.  If you attempt to access this web site using Firefox (or other Mozilla variants), you get the following dialog box:

Which is weird, because of course the web site works just fine in IE.  No big deal, right – Microsoft’s well known for sleazing the rules for it’s own products, so obviously this is Microsoft’s fault – they probably did something like hard coding in trust to the Microsoft issuing CA.  But I was kinda surprised at this, so I spent a bit of time checking it out...

The way that SSL certificate verification is supposed to work is that if the issuer of a certificate isn’t trusted, then the code validating the certificate is supposed to check the parent of the issuer to see if IT is trusted.  If the parent of the issuer isn’t trusted, it’s supposed to check the grandparent of the issuer, and so forth until you find the root certificate authority (CA).

The issuing CA of the certificate on the winqual web site is the “Microsoft Secure Server Authority”, it’s not surprising Mozilla doesn’t trust that one.  The parent of the issuing CA is the “Microsoft Internet Authority”, again, no surprise that Mozilla doesn’t trust it.

But the grandparent of the issuing CA is the “GTE CyberTrust Root”.  This is a well known CA, and Mozilla should be trusting it.  And what do you know, Mozilla DOES claim to trust that root CA:

Well, Cesar Eduardo Barros actually went and checked using openssl to see why the CA isn’t trusted.  He tried:

$ openssl s_client -connect winqual.microsoft.com:443 -showcerts

depth=0 /C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
issuer=/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority
---
No client certificate CA names sent
---
SSL handshake has read 1444 bytes and written 324 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
Start Time: [...]
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
DONE

Decoding the certificate it gave me above (openssl x509 -text) I get the same information Mozilla gives me and a bit more, but no copy of the issuer. The only suspicious thing in there is:

Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/mscorp/msssa1(1).crt
CA Issuers - URI:http://corppki/aia/msssa1(1).crt

Getting that URI gives me a blank HTML page with a 0.1 second redirect to itself. (The CRL one seems valid, however.)

So I was confused, why wasn’t openSSL able to verify the certificate?  So I started asking the security PM’s here at Microsoft what was up.  One of the things he told me was that Microsoft doesn’t hard code ANY intermediate certificates in our browser.  Instead, our browser relies on the referral information in the certificate to chase down the CA hierarchy.

So why can’t Mozilla do the same thing?  Is there something wrong with our certificates that’s preventing this from working?  I kept on pestering and the PM’s kept on digging.  Eventually I got email from someone indicating “IE is chasing 48.2 AIA”.

Well, this isn’t very helpful to me, so I asked the security PM in question to explain it in English.  Apparently the root cause of the problem is that IE is following the Authority Information Access 48.2 OID (1.3.6.1.5.5.7.48.2) to find the parent of the certificate, while Mozilla isn’t.

Inside the Microsoft certificate is the following:

And if you go to http://www.microsoft.com/pki/mscorp/msssa1(1).crt you’ll find the parent CA for the certificate on the winqual web site.  So now it’s off to figure out if the IE behavior is according to standard, or if it’s another case of Microsoft ignoring web standards in favor of proprietary extensions.

A few minutes of googling discovers that the AIA 48.2 field is also known as the id-ad-caIssuers OID.  The authoritative reference for this OID is RFC2459 (the RFC that defines the x.509 certificate infrastructure).  It describes this field as:

 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to the CA that
issued the certificate containing this extension. The referenced CA Issuers description is intended to aid certificate users in
the selection of a certification path that terminates at a point trusted by the certificate user.

In other words, IE is correctly chasing the AIA 48.2 references in the certificate to find the root issuing CA of the certificate. Since it didn’t have direct knowledge of the issuing CA, it correctly looked at the AIA 48.2 field of the certificate for the winqual web site and chased the AIA 48.2 references to the root CA.  It appears that Mozilla (and OpenSSL and GnuSSL) apparently don’t follow this link, which is why they pop up the untrusted certificate dialog.

Issue solved.  Now all someone has to do is to file bugs against Mozilla and OpenSSL to get them to fix their certificate validation logicJ.

Btw, I want to give HUGE kudo’s to Cesar Eduardo Barros for tirelessly trying to figure this out, and to Michael Howard and the lead program manager for NT security for helping me figure this out.  If you look at the info from the certificate that Cesar posted above, he correctly caught the AIA 48.2 fields inside the CA, it was a huge step in the right direction, all that remained was to figure out what it really meant.

Edit: Fixed picture links.

Edit2: Fixed line wrapping of reference from RFC2459.

  • That was some detective work, and a very educational blog entry.
  • Did you file a bug (http://bugzilla.mozilla.org) against FireFox for this?
  • Jarrod: Nope, feel free :) Feel free to use my post as a reference in the bug, but as a Microsoft employee I'm not allowed to contribute to open source projects.
  • Reported as http://bugzilla.mozilla.org/show_bug.cgi?id=245609

    Let's see what they will say about it.

    Now I have to find the bug reporting addresses for OpenSSL and PSM, check Konqueror (probably uses OpenSSL, but not sure), etc...

    By the way, why wasn't this noticed before? It must be a pretty uncommon thing to have an intermediate CA which is not already trusted by the browser, and not send the whole chain on SSL connections.
  • Is there a possibility of infinite loop/hack attack if a the parent CA is the same as the child CA in a spoofed certificate?
  • I'd hope that the validation logic would check for circular CA's, if not it's a bug in the CA validation logic. Now this gets tricky given the number of ways you can form a URL, but...
  • I think I can see why the Mozilla developers didn't implement it that way. That part of the RFC seems ambiguous to me, and it isn't very clear that what lies at the end of the URI is a certificate. It could be interpreted as a place to put the URI of a webpage explaining where to get the certificate, for instance ("description"?).

    A X.509 language lawyer would be really useful right now.
  • Cesar, OpenSSL currently do not support any external (http or ldap) certificate storage (STORE mb would be introduced in 0.9.8), so it cannot access AIA for automatic download of certificate
  • Wow, MS employees aren't allowed to contribute to open-source projects?

    Just out of curiosity, do you have any more details about this? Can't find much with Google...
  • Microsoft (and IBM and undoubtedly other software houses that make their money by proprietary software) prevents it's developers from contributing (or even looking at the code for) to open source software projects.

    IANAL, but AFAIK, the problem is that some code or techniques from the open source code might be incorporated into our proprietary code. If that code is GPL'ed, that might force us to open source the entire component that contains the infringing code.

    Since the GPL has never been litigated, there is no case law that exists that would render guidance as to the liabilities involved, so Microsoft's (and IBM's) legal department prohibit Microsoft employees from participating in open source projects.

    It's not just Microsoft. Any IBM employees that contribute to open source projects are prohibited from participating in their proprietary codebases and vice versa. The same is true for their people who work with Oracle - they're prohibited from working on DB2.


  • It's not true that the GPL has never been litigated.

    (These links should be safe for MS employees, as long as you don't go any deeper in these sites ;-)

    http://www.netfilter.org/news/2004-04-15-sitecom-gpl.html (press release)
    http://lwn.net/Articles/80734/ (lwn article)
    http://gnumonks.org/~laforge/weblog/linux/gpl-violations/ (weblog)
  • This issue reminds me of one I dealt with about 6 years ago. Someone was complaining about Outlook's lack of support for internet standards and as evidence, pointed to a case whereby if you replied to a certain message from pine to Outlook, Outlook wouldn't show the reply, only the original. I dug into it and found out that the problem was on pine's side, it was sending multipart/alternative with text/plain and text/html, but it was only modifying the text/plain and the text/html still had the original message in it - so the two body parts were different and thus it wasn't really multipart/alternative. It turned out it was a known bug with that version of pine that had already been fixed too.
  • You can add Opera 7.5 to the list, it can't access the certificate eithor.
Page 1 of 2 (27 items) 12