Ex2K7 - Certificate errors for internal clients using Outlook 2007

  • Thread starter Adam
  • Start date Views 2,339
Status
Not open for further replies.
A

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
 
J

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" <Adam> wrote in message

news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> 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
>
 
A

Adam

Re: Ex2K7 - Certificate errors for internal clients using Outlook

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

"John Oliver, Jr. [MVP]" wrote:


> 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" <Adam> wrote in message
> news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > 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
> >
 
A

Adam

Re: Ex2K7 - Certificate errors for internal clients using Outlook

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?

"Adam" wrote:


> 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

> "John Oliver, Jr. [MVP]" wrote:
>
> > 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" <Adam> wrote in message
> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > > 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
> > >
 
J

John Oliver, Jr. [MVP]

Re: Ex2K7 - Certificate errors for internal clients using Outlook

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" <Adam> wrote in message

news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> 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?

> "Adam" wrote:
>
> > 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
>

>> "John Oliver, Jr. [MVP]" wrote:
> >
> > > 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" <Adam> wrote in message
> > > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > > > 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
> > > >
 
A

Adam

Re: Ex2K7 - Certificate errors for internal clients using Outlook

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 Oliver, Jr. [MVP]" wrote:


> 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" <Adam> wrote in message
> news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> > 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?
> > "Adam" wrote:
> >
> >> 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
> >
> >> "John Oliver, Jr. [MVP]" wrote:
> >
> >> > 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" <Adam> wrote in message
> >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> >> > > 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
> >> > >
 
A

Adam

Re: Ex2K7 - Certificate errors for internal clients using Outlook

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.

Adam

"John Oliver, Jr. [MVP]" wrote:


> 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" <Adam> wrote in message
> news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> > 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?
> > "Adam" wrote:
> >
> >> 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
> >
> >> "John Oliver, Jr. [MVP]" wrote:
> >
> >> > 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" <Adam> wrote in message
> >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> >> > > 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
> >> > >
 
J

John Oliver, Jr. [MVP]

Re: Ex2K7 - Certificate errors for internal clients using Outlook

Your welcome!

John Oliver, Jr

MCSE, MCT, CCNA

Exchange MVP 2009

Microsoft Certified Partner

"Adam" <Adam> wrote in message

news:2B77208D-5379-47E5-A9E7-5600425C4B81@microsoft.com...
> 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.
> Adam

> "John Oliver, Jr. [MVP]" wrote:
>
> > 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" <Adam> wrote in message
> > news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> > > 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?
> >> > "Adam" wrote:
> >> >> 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
> > >
>> >> "John Oliver, Jr. [MVP]" wrote:
> > >
>> >> > 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" <Adam> wrote in message
> > >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > >> > > 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
> > >> > >
 
Status
Not open for further replies.
Top