Multiple Certificates... age old problem or not with solution?

Hello,

I basically have a queston that 'google'ing' presented nothing too
assuring.

We basically have a few websites, 3 to be exact that all have public
published DNS names (same ip, different subdomain) and currently under
1 certificate. The problem faced is obviously that the name of the cert
is for one of the subdomain names. Can we use 3 diff INTERNAL ip
addresses or must they be external and create certs for these sites and
be good to go using multiple certs for these 2 other sites?

Similar scenario as this old thread I found here:
http://groups.google.com/group/microsoft.public.inetserver.i is.security/browse_frm/thread/133b335841392a2b/826f4e2937388 f6c?lnk=st&q=multiple+certificates+iis&rnum=4#826f4e2937388f 6c

Thanks in advance .. I would try this myself, but I dont really have
the time so I figured i'd ask before giving it a shot..

Thanks again!

GNY

Re: Multiple Certificates... age old problem or not with solution?

GNY wrote on 10 Jan 2007 03:55:23 -0800:

> Hello,
>
> I basically have a queston that 'google'ing' presented nothing too
> assuring.
>
> We basically have a few websites, 3 to be exact that all have public
> published DNS names (same ip, different subdomain) and currently under
> 1 certificate. The problem faced is obviously that the name of the cert
> is for one of the subdomain names. Can we use 3 diff INTERNAL ip
> addresses or must they be external and create certs for these sites and
> be good to go using multiple certs for these 2 other sites?

If you really do mean that only the subdomain is different (eg.
site1.domain.com, site2.domain.com, site3.domain.com) then you could use a
Wildcard Certificate - you would get one for *.domain.com, and it would work
for all three sites on the same IP+port combination as the same certificate
is used for all sites for SSL/TLS, and then the actual site is delivered
using the Hostname header after the connection has been established.
However, not all browsers support this, although most of the popular ones
do.

Each IP+port combination must be unique for IIS (except in the case of
Wildcard Certificates). The reason for them needing to be unique is that the
HTTPS handshaking is done before the Hostname header is passed, and so the
only way for IIS to identify which certificate to use is from the IP and
port combination. If the wrong certificate is sent, then either the browser
pops up a warning dialog that the certificate doesn't match the hostname, or
in the case of IE7 throws up a page with details on and a (Not recommended)
next to the "Continue to this website" option - for a business site this
will normally mean that the majority of your potential customers will just
go elsewhere.

You can have all 3 sites on one IP, just using different ports, but this
would require the port numbers to be included in URLs for those sites that
are not on the default HTTPS port of 443. Eg. you could use https://www.site1.com
, https://www.site2.com:444 , and https://www.site3.com:445 with each on
the same IP address.

If you need all 3 to work on port 443, each with it's own certificate, the
only solution is use 3 public IP addresses.

Dan

Re: Multiple Certificates... age old problem or not with solution?

Daniel,

Thanks for the reply. So we wouldnt want to do the seperate ports, so
unique IPs or the wildcard certs are the options to devise.

Few more things..

* Would these IPs need to be internally different or should they be
externally different IPs or both?

* The incompatible browsers? Which would they be considering that our
www is hosted elsewhere so I dont worry about that. The sites that are
in question are more or less internal sites, but one is a sharepoint
and the other is webmail.

Thanks again ..

GNY

Daniel Crichton wrote:
> GNY wrote on 10 Jan 2007 03:55:23 -0800:
>
> > Hello,
> >
> > I basically have a queston that 'google'ing' presented nothing too
> > assuring.
> >
> > We basically have a few websites, 3 to be exact that all have public
> > published DNS names (same ip, different subdomain) and currently under
> > 1 certificate. The problem faced is obviously that the name of the cert
> > is for one of the subdomain names. Can we use 3 diff INTERNAL ip
> > addresses or must they be external and create certs for these sites and
> > be good to go using multiple certs for these 2 other sites?
>
> If you really do mean that only the subdomain is different (eg.
> site1.domain.com, site2.domain.com, site3.domain.com) then you could use a
> Wildcard Certificate - you would get one for *.domain.com, and it would work
> for all three sites on the same IP+port combination as the same certificate
> is used for all sites for SSL/TLS, and then the actual site is delivered
> using the Hostname header after the connection has been established.
> However, not all browsers support this, although most of the popular ones
> do.
>
> Each IP+port combination must be unique for IIS (except in the case of
> Wildcard Certificates). The reason for them needing to be unique is that the
> HTTPS handshaking is done before the Hostname header is passed, and so the
> only way for IIS to identify which certificate to use is from the IP and
> port combination. If the wrong certificate is sent, then either the browser
> pops up a warning dialog that the certificate doesn't match the hostname, or
> in the case of IE7 throws up a page with details on and a (Not recommended)
> next to the "Continue to this website" option - for a business site this
> will normally mean that the majority of your potential customers will just
> go elsewhere.
>
> You can have all 3 sites on one IP, just using different ports, but this
> would require the port numbers to be included in URLs for those sites that
> are not on the default HTTPS port of 443. Eg. you could use https://www.site1.com
> , https://www.site2.com:444 , and https://www.site3.com:445 with each on
> the same IP address.
>
> If you need all 3 to work on port 443, each with it's own certificate, the
> only solution is use 3 public IP addresses.
>
> Dan

Re: Multiple Certificates... age old problem or not with solution?

GNY wrote on 10 Jan 2007 04:52:52 -0800:

> Daniel,
>
> Thanks for the reply. So we wouldnt want to do the seperate ports, so
> unique IPs or the wildcard certs are the options to devise.
>
> Few more things..
>
> * Would these IPs need to be internally different or should they be
> externally different IPs or both?

If you only had one external address, how would your equipment that is doing
NAT translation work out which internal IP to send it to? You could get away
with a single IP on the IIS server, and have your NAT doing some sort of
reverse SSL proxy so it deals with what to do with the connection (so each
public IP+port443 is translated to the single internal IIS IP+unique port by
the proxy, and it handles determining which to use), but as you didn't
mention that you use a reverse proxy I assume you don't have one and the
connections are coming direct via NAT (eg firewall, router) one a 1-to-1
translation basis, so you'll need multiple IPs both internally and
externally. Adding a reverse proxy will unnecessarily complicate things, and
unless you have run out of internal IP addresses I wouldn't consider it.

> * The incompatible browsers? Which would they be considering that our
> www is hosted elsewhere so I dont worry about that. The sites that are
> in question are more or less internal sites, but one is a sharepoint
> and the other is webmail.

So long as your users are on IE6 or higher, or Mozilla/Firefox, or Opera, I
think you'll be fine. I've read about warnings on IE5.0 on Windows 2000 if
a Wildcard cert is used, although apparently some versions of IE4 did
support them (but not officially), apparently IE5.01 was the first version
of IE that did handle them correctly.

According to RapidSSL, the following browsers are supported for wildcards:

IE 5.01+
Netscape 4.71+
AOL 5+
Mozilla 1+
Opera 5+
Firefox 1+
Safari 1+

Dan

Re: Multiple Certificates... age old problem or not with solution?

Dan,

Thanks alot .. I think I have enough to make a decision going forward.
I do have enough internal and external addresses to use and set static
routes to, so i guess thats the way to go..

GNY

Daniel Crichton wrote:
> GNY wrote on 10 Jan 2007 04:52:52 -0800:
>
> > Daniel,
> >
> > Thanks for the reply. So we wouldnt want to do the seperate ports, so
> > unique IPs or the wildcard certs are the options to devise.
> >
> > Few more things..
> >
> > * Would these IPs need to be internally different or should they be
> > externally different IPs or both?
>
> If you only had one external address, how would your equipment that is doing
> NAT translation work out which internal IP to send it to? You could get away
> with a single IP on the IIS server, and have your NAT doing some sort of
> reverse SSL proxy so it deals with what to do with the connection (so each
> public IP+port443 is translated to the single internal IIS IP+unique port by
> the proxy, and it handles determining which to use), but as you didn't
> mention that you use a reverse proxy I assume you don't have one and the
> connections are coming direct via NAT (eg firewall, router) one a 1-to-1
> translation basis, so you'll need multiple IPs both internally and
> externally. Adding a reverse proxy will unnecessarily complicate things, and
> unless you have run out of internal IP addresses I wouldn't consider it.
>
> > * The incompatible browsers? Which would they be considering that our
> > www is hosted elsewhere so I dont worry about that. The sites that are
> > in question are more or less internal sites, but one is a sharepoint
> > and the other is webmail.
>
> So long as your users are on IE6 or higher, or Mozilla/Firefox, or Opera, I
> think you'll be fine. I've read about warnings on IE5.0 on Windows 2000 if
> a Wildcard cert is used, although apparently some versions of IE4 did
> support them (but not officially), apparently IE5.01 was the first version
> of IE that did handle them correctly.
>
> According to RapidSSL, the following browsers are supported for wildcards:
>
> IE 5.01+
> Netscape 4.71+
> AOL 5+
> Mozilla 1+
> Opera 5+
> Firefox 1+
> Safari 1+
>
> Dan