Potential Bug: IE 7 and SSL certificate handling.

[Commerce]

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
answered).

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.

 

[Alun Jones]

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.
~~~~

"Commerce" <Commerce@discussions.microsoft.com> wrote in message
news:F1042725-B190-415A-9097-2BF2357D2A52@microsoft.com...
> 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
> answered).
>
> 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]

Alun,

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
alarm.

-Commerce

"Alun Jones" wrote:

> 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.
> ~~~~
>
> "Commerce" <Commerce@discussions.microsoft.com> wrote in message
> news:F1042725-B190-415A-9097-2BF2357D2A52@microsoft.com...
> > 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
> > answered).
> >
> > 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.
> >
>
>
>

 

[Alun Jones]

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.
~~~~

"Commerce" <Commerce@discussions.microsoft.com> wrote in message
news:1D307E10-1DD0-48C5-B0C7-4A14D3A883E3@microsoft.com...
> Alun,
>
> 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
> alarm.
>
> -Commerce
>
> "Alun Jones" wrote:
>
>> 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.
>> ~~~~
>>
>> "Commerce" <Commerce@discussions.microsoft.com> wrote in message
>> news:F1042725-B190-415A-9097-2BF2357D2A52@microsoft.com...
>> > 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
>> > answered).
>> >
>> > 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]

Alun,

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
it.

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
all.

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

"Alun Jones" wrote:

> 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.
> ~~~~
>
> "Commerce" <Commerce@discussions.microsoft.com> wrote in message
> news:1D307E10-1DD0-48C5-B0C7-4A14D3A883E3@microsoft.com...
> > Alun,
> >
> > 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
> > alarm.
> >
> > -Commerce
> >
> > "Alun Jones" wrote:
> >
> >> 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.
> >> ~~~~
> >>
> >> "Commerce" <Commerce@discussions.microsoft.com> wrote in message
> >> news:F1042725-B190-415A-9097-2BF2357D2A52@microsoft.com...
> >> > 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
> >> > answered).
> >> >
> >> > 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.
> >> >
> >>
> >>
> >>
>
>
>