Potential Bug: IE 7 and SSL certificate handling.

Discussion in 'Security Software' started by Commerce, Oct 4, 2007.

  1. Commerce

    Commerce Guest

    NOTE: A version of this was also posted yesterday in IE 7 forum.
    Unfortunately I received no useful responses, so thought this might be an
    alternative place, as it regards SSL (thus security) in IE 7. Sorry for the
    crosspost, but I think it is a problem that should be resolved (or at least

    Description of Potential Bug:
    MS IE 7.0 Fails to act properly in dealing with SSL wildcard certificates in
    certain situations. A wildcard SSL certificate should be valid for both
    subdomain.domain.tld as well as www.subdomain.domain.tld - such processing
    for wildcard certificates probably should be valid for any valid DNS
    creatable sub domain (e.g., www.foo.bar.domain.tld ) of a valid domain name
    (e.g., domain.tld) for which the wildcard certificate was created.

    Obviously, care should be used in handling what constitutes a valid domain
    (e.g., *.tld should probably never be valid for a wildcard certificate issued
    for a top level domain or issues in certain country code naming scenarios),
    but those issues extend beyond the scope of this report.

    Problem Scenario:
    After successfully installing a wildcard SSL cert for a domain (e.g.,
    *.domain.tld ) for both an IIS 5.0 (Windows 2000) platform and an IIS 6.0
    (Windows 2003) platform, IE 7.0 fails to treat the wildcards SSL certificate
    as being valid for both www.subdomain.domain.tld and subdomain.domain.tld
    names. Instead it only accepts the subdomain.domain.tld variant as
    acceptable. In this particular scenario, the domain happens to be a two
    letter .com name.

    Suggestion of Potential Bug:
    This problem does not occur in other browsers (e.g., FireFox, Opera), where
    those browsers accept both the subdomain.domain.tld and
    www.subdomain.domain.tld variant as acceptable for the SSL certificate. As
    such, in both of the abovementioned browsers, the replication actions
    suggested below work as expected.

    Replication Actions:
    For a domain using a wildcard secure ssl certificate (e.g., *.domain.tld )
    successfully installed on a late model IIS server -

    When accessing foo.domain.tld as https://foo.domain.tld in IE 7.0 - normal
    access as expected to a page with SSL enabled.

    When accessing www.foo.domain.tld as https://www.foo.domain.tld in IE 7.0 -
    an error occurs indicating that the certificate is invalid for the domain.
    Expected results would be a working https page result with secure SSL
    engaged, based upon both the results from other browsers and definition
    expectations for a wildcard SSL certificate.
    Commerce, Oct 4, 2007
    1. Advertisements

  2. Commerce

    Alun Jones Guest

    Not a bug - this is the way that the HTTPS protocol is supposed to work, and
    those other browsers are being unsecure by allowing wildcards to work in
    that way. Here's the quote from RFC 2818 (HTTP over TLS):

    "Matching is performed using the matching rules specified by
    [RFC2459]. If more than one identity of a given type is present in
    the certificate (e.g., more than one dNSName name, a match in any one
    of the set is considered acceptable.) Names may contain the wildcard
    character * which is considered to match any single domain name
    component or component fragment. E.g., *.a.com matches foo.a.com but
    not bar.foo.a.com. f*.com matches foo.com but not bar.com."

    So, there you have it - "*.a.com matches foo.a.com, but not bar.foo.a.com" -
    you're asking Microsoft to break the standards for the trifling reason that
    everyone else does it wrong. Not cool. Report the bugs in those other
    browsers, and see if they fix them.

    Alun Jones, Oct 4, 2007
    1. Advertisements

  3. Commerce

    Commerce Guest


    Great answer and although not what I had hoped would be the case, I thank
    you for it. Based upon your cite, clearly, IE 7 follows the standard
    properly and the others do not. My conclusion was wrong.

    Arguably, however, the RFC 2818 standard should be modified, at least to the
    degree that it acknowledges the predating defacto standard for web site
    access over http, which has historically been the use of a www subdomain
    (albeit that is in http, but then https is just a secure layer upon which
    http rides, so it is not all that outrageous to consider).

    My feeling is that wildcard subdomains for HTTPS should at least be extended
    such that a.sld.tld should reasonably also cover www.a.sld.tld. I suppose
    the other browser companies felt that way too and thus "bent" the standard a
    bit to accommodate that historic convention. Perhaps these other companies
    would consider it a "standards extension" to their products.

    While strictly speaking, ignoring standards is a no - no (or as you say,
    "not cool"), in this case, I think that it is understandable. I do not think
    that such an action would compromise security, because the basic underlying
    settings that make wildcarding possible are addressed within DNS and at the
    secure host header level on the server.

    Again, thank you for your clear answer. I already adjusted the site to
    accommodate what I considered an IE 7 "bug", so the issue will not be
    problematic here (though a bit inconvenient). Now I suppose that I am happy
    to find that my "fix" follows the intended standard after all. So, I guess
    if the other browsers need to "downgrade" their "standards extension", it
    will not cause any issues around here.

    My sincere apologies to the community for raising what appears to be a false


    Commerce, Oct 4, 2007
  4. Commerce

    Alun Jones Guest

    Sure, it makes sense when you couch it as "domain.example.com" vs
    "www.domain.example.com", which are clearly, to you and me, "the same site".

    What if I couch it as "*.example.com" gives you access to
    "private.internal.example.com" as well as "public.example.com"?

    No, if you want to handle domain.example.com and www.domain.example.com, the
    solution is very simple. Register a wildcard for *.example.com, and redirect
    www.domain.example.com to domain.example.com. Then all your https links will
    go to the one FQDN.

    I would suggest that rather than trying to get Microsoft to refrain from
    following the standards in the midst of a number of people who would rather
    they followed standards more closely, find out why the standard was written
    the way it was (Eric Rescorla has been known to respond in an informative
    manner to those who ask polite questions), and then go ask the other vendors
    why they aren't following standards.


    Alun Jones, Oct 4, 2007
  5. Commerce

    Commerce Guest


    Once again, a reasonable answer, thank you.

    Not to be argumentative, but having a wildcard that allows both
    "private.internal.example.com" as well as "public.example.com", per your
    example, does not really seem a problem. Since the domain holder presumably
    has control over their DNS (after all, if they don't any wildcard cert is
    subject to abuse) as well as their web host server (again, kind of important
    to install the SSL cert), then this should not be an issue if you think about

    Generally, you would want to set up host header for SSL on the server to get
    it to respond to a particular request (e.g.,
    "xxx.xxx.xxx.xxx:443:www.sub.domain.tld", although you can certainly set it
    up to respond to all SSL requests via setting a ":443:") or set of requests
    to a given site on your web server, so no biggie at the server level
    (presumably the domain / cert holder has control over the server they install
    the cert on and avoids sharing with the private key information included,
    which would kind of defeat the whole purpose of having the SSL cert).

    In my particular case, I rather don't want to have the fix you suggested, as
    I would prefer the flexibility to keep the machine holding the root sub
    domain (sub.domain.tld) seperate from the machine handing the www requests
    for a sub domain (www.sub.domain.tld).

    Further, I did a bit more research on the RFC you mentioned in your first
    response (RFC 2818). Checking the RFC 2459 that Mr. Rescorla quotes from
    (BTW, really enjoyed his domain name - made me smile), I found this:
    " For URIs, the constraint applies to the host part of the name. The
    constraint may specify a host or a domain. Examples would be
    "foo.bar.com"; and ".xyz.com". When the the constraint begins with
    a period, it may be expanded with one or more subdomains. That is,
    the constraint ".xyz.com" is satisfied by both abc.xyz.com and
    abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied
    by "xyz.com". When the constraint does not begin with a period, it
    specifies a host. " - Page 35 RFC 2459
    and this:
    " DNS name restrictions are expressed as foo.bar.com. Any subdomain
    satisfies the name constraint. For example, www.foo.bar.com would
    satisfy the constraint but bigfoo.bar.com would not." - Same page RFC 2459

    These quote from RFC 2459 suggest that what I am looking for is at least
    reasonable. Specifically, if you take the quote - 'That is, the constraint
    ".xyz.com" is satisfied by both abc.xyz.com and abc.def.xyz.com' - and plug
    in www.abc.xyz.com for abc.def.xyz.com, then you have pretty much exactly
    what I am looking for and what IE 7 does not seem to do.

    So, perhaps the jury is still out on if this is an IE 7 bug or not after

    Arguably, given what I have found in RFC 2459, it is reasonable to believe
    that the other browser companies may be interpreting exactly what was said in
    RFC 2818, namely, '"Matching is performed using the matching rules specified
    by [RFC2459].".

    Following RFC 2459's rules per RFC 2818, you get back to the source of my
    original concern and post.

    I appreciate your willingness to discuss this reasonably.


    Commerce, Oct 7, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.