Ex2K7 - Certificate errors for internal clients using Outlook 2007

[Adam]

This may be a bit long winded so my apologies in advance!
We have a rather sticky problem with certificates on our new Exchange 2007
Client Access server set up. We are currently in the process of trying to
migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to the new
Ex2K7 server and they are all getting certificate errors when Outlook 2007
starts up on domain joined machines (internal clients). The error states that
the site name that Outlook is looking for is different from what is on the
cert. And it is correct. Here is the whole sorry saga of our certificate
tragedy:
We are a school in the UK. We have a publicly registered domain name that
ends with .sch.uk. Our internal/private AD domain name is nearly identical to
our public domain name and also ends in .sch.uk (don’t ask, this was before
my time) and looks very much like a public domain name. Because of this, we
were unable to find a single commercial certificate provider that would
include our internal FQDNs to any UCC certificate we wanted. In the end, we
ended up purchasing a Digicert UCC cert that had only our external FQDNs for
the CAS server and autodiscover services. We tried to work around this
problem by enabling both our commercial cert as well as the default MS cert
that ships with Ex2K7 which we added all of our internal FQDNs to. The hope
was that the external clients would be able to use the commercial cert, while
the internal clients would be able to use the default simple cert. This
seemed to work for a brief time, but after a few weeks, Outlook 2K7 on the
internal clients began ignoring the internal certificate and started using
the commercial cert which, of course, didn't have any of the internal
information on it and hence they started getting the certificate error on
startup. After much wrestling with this issue, we made the decision to
register our internal domain name so that we could provide Digicert with a
"whois" for it and they would then be happy to add our internal FQDNs to our
commercial cert and we could decommission the MS default cert. However, I
then spoke to Nominet and was told that we could NOT register our internal
domain name because it has the .sch.uk suffix and since we already have one
.sch.uk domain name registered, we can't register another one.
We've been given two options by certificate providers, domain name
registrants and Nominet alike:
1. Rename our external domain name so that it is the same as our internal
domain name
2. Rename our internal domain name to use a suffix like .int or .local
Neither of these options is even slightly appealing to us so we are
desperately trying to find a work-around.
I am now aware that having two active certificates running on the same CAS
server is not supported. Is it possible to have two CAS servers in the same
organisation and to force internal clients to use a specific one for
autodiscover? If so, we could set the two up and just have the Digicert
commercial cert on one for external access and have the MS default cert
enabled on the other for internal access.
Any other thoughts or ideas would be greatly appreciated. Many thanks,
Adam

[John Oliver, Jr. [MVP]]

Is the internal URL WebServices Virtual Directory pointing to your external
registered domain that is included with the SAN Cert?

Get-WebServicesVirtualDirectory | FL

--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner

"Adam" <Ad...@discussions.microsoft.com> wrote in message
news:9C2006F1-B82A-4D6A...@microsoft.com...

[Adam]

John,
No, the internal URL for the WebServices directory contains the internal
FQDN of our client access server.

As a side note, I've been able to stop the security warnings regarding the
site name mismatch on internal Outlook clients by running the
"set-clientaccessserver" command to change the servicebindinginformation
attribute of the SCP object so that it matches what is listed on our UC
certificate which is the external FQDN of our CAS server. However, because
all of the internal URLs still list the internal FQDN of our client access
server, the autodiscover service fails on internal Outlook 2007 clients. This
doesn't seem to be having any negative impact on their functionality as of
yet but it isn't ideal. According to MS KB article 940726, in order to change
these internal URLs so that they match the external FQDN of the CAS server,
we'd need to add a host record for that external FQDN to our DNS that
resolves to the internal IP address of the CAS server. The only way I can
think of achieving this is via a spilt DNS configuration which simply
wouldn't work in our environment. I may just try testing this by changing
those internal URLs to match our external FQDN and see of the DNS host record
is really necessary. Thanks for you time and do let me know if you have any
other thoughts on this.
Adam

[Adam]

Would it be possible to set up separate URLs for exteral and internal access?
In other words, have a set of internal URLs for external access that have the
external FQDNs and another set for internal access that contain the CAS
server's internal FQDNs?

[John Oliver, Jr. [MVP]]

You would be better served to keep them the same. You would not need a
split DNS to achieve this, you can create a Forward Lookup Zone in DNS to
match your internal/external url, mail.sch.uk for example. Create Host
record of the internal IP of your Exchange Server. Now test internally from
command prompt that mail.shc.uk resolves to this IP. No need for split DNS
if you follow this route.

--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner

"Adam" <Ad...@discussions.microsoft.com> wrote in message

news:7652B225-F7D8-4609...@microsoft.com...

[Adam]

John,
That sounds very sensible and oddly enough, another colleague of mine was
just discussing something very similar to that yesterday. I will talk it over
with the team and see if they'll agree to let me test this. If they do and if
this resolves the issue, I'll post it here.Thanks again for your time,

[Adam]

John,
Your solution was spot on. I created a new forward lookup zone in DNS for
our external domain name, then populated it with a single host record for our
external CAS server name and resolved it to the internal IP address of the
CAS server. Tested that I could ping it...all good. I then changed all of the
relevant internal URLs to match the external FQDN on our UC cert (i.e. -
https://ourserver.ourexternaldomain.sch.uk/autodiscover/autodiscover.xml).
Then tested that I could get to that address in a browser...was asked for my
credentials, put them in and got the expected web page result. Finally,
tested autodiscover on Outlook and we are golden! Thanks so much for your
help.

[John Oliver, Jr. [MVP]]

Your welcome!

--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner

"Adam" <Ad...@discussions.microsoft.com> wrote in message

news:2B77208D-5379-47E5...@microsoft.com...