New HTTPS web site and certificate installation

23 Jun 2006 6:34 PM

instrument_programmer

While I am a very experienced developer I am new to the whole IIS secure
server stuff. We had created a locally generated "test" cerrificate and
installed it and it works with that. But we wanted to expose this outside
our firewall with a real certificate. We have an ISA server acting as our
firewall. It is the only system that has an external IP address. We have
multiple sub domains (i.e. www.foo.com, yyy.foo.com) that our external DNS
points to this one server. On the ISA server I have web publishing rules and
destination sets to redirect www.foo.com and yyy.foo.com to our internal IIS
server at www.internal.com and yyy.internal.com. They are redirected to
different port numbers to insure no clashes on the ports (both http and SSL).
I recently purchased (from Thawte) certificates for www.foo.com and
yyy.foo.com. I installed those on www.internal.com and yyy.internal.com and
tried to turn on SSL. It does not work. I get a message that the
certificate is still the "old" locally generated certificate.
So some questions:
1) How do I get rid of the old locally generated certificate (all traces)
2) Will the newly purchased certificates (which were issued against the
www.foo.com and yyy.foo.com domains) work when installed onto the behind the
firewall www.internal.com and yyy.internal.com server? Or will I have to
purchase new certificates with the "internal" domain FQDN??
3) Why is this all so dang hard? ;-)
Thanks

25 Jun 2006 1:58 AM

David Wang [Msft]

1. Please describe how you "installed" your new certificate onto IIS and
make the website use that new certificate.
2. The newly purchased certificates should work with how you are
configuring. Remember, the client has no idea whether ISA or the internal
server answered the request. It just knows that some certificate comes back
with a certain name. If you make the internal server identify itself as
www.foo.com in the certificate and the client thinks it went to www.foo.com
(but forwarded to the internal server), it's still ok (if it wasn't, then
SSL would never get past the first network hop). If you make the internal
server identify itself as "internal domain FQDN" then obviously the client
is going to complain because it does not match where it think it went to.
3. It's only as hard as you make it. ;-)

It's just about getting the right .cer files installed (for test and
self-signed it is more work because you often have to take care of the
infrastructure; commercial certs should just install and work), and then
make one SSL Binding change for the website and poof SSL works.

FYI: the bulk of your post is actually explaining your network routing
complexity and not IIS Security or SSL Complexity... ;-)

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Show quoteHide quote

"instrument_programmer" <instrumentprogram***@discussions.microsoft.com>
wrote in message news:15EC6287-B692-4138-9EBC-DB05394901CA@microsoft.com...
> While I am a very experienced developer I am new to the whole IIS secure
> server stuff. We had created a locally generated "test" cerrificate and
> installed it and it works with that. But we wanted to expose this outside
> our firewall with a real certificate. We have an ISA server acting as our
> firewall. It is the only system that has an external IP address. We have
> multiple sub domains (i.e. www.foo.com, yyy.foo.com) that our external DNS
> points to this one server. On the ISA server I have web publishing rules
> and
> destination sets to redirect www.foo.com and yyy.foo.com to our internal
> IIS
> server at www.internal.com and yyy.internal.com. They are redirected to
> different port numbers to insure no clashes on the ports (both http and
> SSL).
> I recently purchased (from Thawte) certificates for www.foo.com and
> yyy.foo.com. I installed those on www.internal.com and yyy.internal.com
> and
> tried to turn on SSL. It does not work. I get a message that the
> certificate is still the "old" locally generated certificate.
> So some questions:
> 1) How do I get rid of the old locally generated certificate (all traces)
> 2) Will the newly purchased certificates (which were issued against the
> www.foo.com and yyy.foo.com domains) work when installed onto the behind
> the
> firewall www.internal.com and yyy.internal.com server? Or will I have to
> purchase new certificates with the "internal" domain FQDN??
> 3) Why is this all so dang hard? ;-)
> Thanks

25 Jun 2006 1:34 PM

instrument_programmer

David, thanks for the quick response.
1) Opened the "Internet Services Manager", Selected the server, right
clicked the web sites (www.internal.com, etc.) select properties, select
directory security, select Server Certificate, used wizard to select file
that Thawte sent us. Is there something else I need to do to remove the
generic test domain cert "*.internal.com"?
2) That is good to know - I think I understand the mechanism now given your
reply. The servers on our end don't read the certificate - that is just sent
back to the client and the client web browser reads and verifies the
certificate. So why is our generic test domain certificate "*.internal.com"
being sent back to the client?
3) I am trying hard to make this easy! ;-)

Show quoteHide quote

"David Wang [Msft]" wrote:

> 1. Please describe how you "installed" your new certificate onto IIS and
> make the website use that new certificate.
> 2. The newly purchased certificates should work with how you are
> configuring. Remember, the client has no idea whether ISA or the internal
> server answered the request. It just knows that some certificate comes back
> with a certain name. If you make the internal server identify itself as
> www.foo.com in the certificate and the client thinks it went to www.foo.com
> (but forwarded to the internal server), it's still ok (if it wasn't, then
> SSL would never get past the first network hop). If you make the internal
> server identify itself as "internal domain FQDN" then obviously the client
> is going to complain because it does not match where it think it went to.
> 3. It's only as hard as you make it. ;-)
>
> It's just about getting the right .cer files installed (for test and
> self-signed it is more work because you often have to take care of the
> infrastructure; commercial certs should just install and work), and then
> make one SSL Binding change for the website and poof SSL works.
>
> FYI: the bulk of your post is actually explaining your network routing
> complexity and not IIS Security or SSL Complexity... ;-)
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //