2

I have an internally-hosted Exchange 2010 Server with an internal domain, EXCHANGE0.COMPANY.COM.

I have configured all users to access Outlook (even internally) using Outlook-over-HTTP. To do so I have set up a client access certificate for the externally-facing domain mail.company.com.

The problem is that whenever users open Outlook they are promptly greeted by certificate warnings of the mismatch between mail.company.com and EXCHANGE0.COMPANY.COM. I would like to eliminate these warnings and I feel there is a way to do so either through DNS or through Exchange. I am just not sure what to do.

AutoDiscover is configured using the SRV method if that matters at all.

EDIT: Configuration on clients looks as follows

Exchange Server: EXCHANGE0.COMPANY.COM Connect using Outlook Anywhere (HTTP): on fast and slow connections, connect to mail.company.com and only trust msstd:mail.company.com

Name on certificate is mail.company.com, but Outlook was expecting EXCHANGE0.COMPANY.COM

tacos_tacos_tacos
  • 3,220
  • 16
  • 58
  • 97
  • Can you clarify what the configuration looks like? Are the outlook clients configured to point to `mail.company.com` or `exchange0.company.com`? And what name is on the certificate? – Shane Madden Dec 16 '11 at 16:35
  • This info has been added in the edit – tacos_tacos_tacos Dec 16 '11 at 16:37
  • Is it issued from an internal certificate authority where you could easily issue a new certificate with a subject alternate name? If not, then you may need to look at using a different IP address with an SSL listener with its own certificate - one IP for each name. – Shane Madden Dec 16 '11 at 16:56
  • The `mail.company.com` certificate is issued externally. I would like to avoid purchasing an additional SSL certificate... But maybe I need to issue one from within the domain? – tacos_tacos_tacos Dec 16 '11 at 17:01
  • That would work if all of the clients connecting to the `exchange0` name would trust that certificate. – Shane Madden Dec 16 '11 at 17:03
  • Yes, but some clients connect remotely without first going through VPN... Plus I wouldn't know how to configure the certificate to install. I mean, is there a certificate type that maps one domain to another? The certificate they are expecting to see is EXCHANGE0 and what they are seeing instead is `mail.company.com` which is issued externally by GoDaddy – tacos_tacos_tacos Dec 16 '11 at 17:04
  • Essentially you'll be creating a new, independent internal certificate for clients that are hitting the `exchange0` name, which will be attached to an SSL listener in IIS on a completely different IP address For instance, if your current setup is both DNS names pointing to an IP address of `10.0.1.50`, and that IP has an SSL listener with a cert for `mail.company.com`, what you'll be doing is to add a new IP and a new cert and adjust DNS so that `DNS: mail.company.com -> 10.0.1.50 -> cert: mail.company.com` and `DNS: exchange0.company.com -> 10.0.1.51 -> cert: exchange0.company.com` – Shane Madden Dec 16 '11 at 17:10
  • Should I be doing this on "Default Web Site"? Is this safe to do? – tacos_tacos_tacos Dec 16 '11 at 17:13
  • Assuming that your Exchange stuff is in the Default Web Site (as is the default), than yeah. Don't mess with the existing binding (aside from changing it to just the specific IP instead of all IPs), and add a new HTTPS binding against the new IP address with the new internal certificate. – Shane Madden Dec 16 '11 at 17:15
  • I've done this and it appears to somewhat help because the warning appears less frequently, but it does not disappear entirely. I think it comes back after a while because Windows automatically adds an entry for both IPs to the internal DNS – tacos_tacos_tacos Dec 29 '11 at 00:24

6 Answers6

4

You can take care of this problem by setting the InternalURL attributes for the various Exchange components to match your external name (mail.company.com). Once you've done that you can create a DNS record (probably a CNAME for "mail.company.com" to "exchange0.company.com"-- it sounds like you named your AD domain the same as your real Internet domain name) so that clients can connect to "mail.company.com" and get directed to the Exchange Server computer.

The "set" commands for each component you'll need to run are below. You can use the "Get-" versions of these commands to see how they're set now.

Set-ActiveSyncVirtualDirectory -InternalURL
Set-AutodiscoverVirtualDirectory -InternalURL
Set-ClientAccessServer -AutodiscoverServiceInternalUri
Set-ECPVirtualDirectory -InternalURL
Set-OABVirtualDirectory -InternalURL
Set-OWAVirtualDirectory -InternalURL
Set-WebservicesVirtualDirectory -InternalURL
Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
0

If i understand correctly you want to reconfigure your exchange services to work under one domain (even internally) using this KB940726 or this link (both covering the same thing). The error is consistent for Exchange 2007/2010 server. Otherwise you will need a SAN certificate (or a wildcard certificate) to cover more then one domain under same certificate (which is costy).

Also if you're low on money or supporting small company I would recommend that you use autodiscover.domain.com as your main domain for everything (even for your outlook clients to connect to, owa etc). It may seem inconvenient but this will save you costs on certificates that require to cover more then one domain (SAN certificates). I found this to be the most cost-effective solution for my small time customers who don't nessecary wanna pay 100-1000$ yearly just to get certificate that can handle multiple domains under one ip/port.

And to finish this up you can get free (real free!) SSL certificates from StartSSL renewed yearly without any charge. Only revocation is not free but as long as you generate certs correctly and don't loose keys you should be safe.

MadBoy
  • 3,703
  • 13
  • 61
  • 93
  • Are StartSSL free certificates trusted by all major browsers? – gravyface Dec 29 '11 at 00:40
  • Yes. I use it for 4 of my clients and never had a problem with them (except old nokia phones). Try for yourself.. if you can enter their site https://www.startssl.com/ without warning it should be fairly safe ;-) – MadBoy Dec 29 '11 at 00:41
  • Just did. FireFox complains about it. Chrome appears to be ok, but then says unverified issuer under the certificate details. – gravyface Dec 29 '11 at 01:48
  • I use it in FireFox 11 and IE and it's fine. – MadBoy Dec 29 '11 at 09:17
0

I had this problem the other day at a client where I (at the time) couldn't figure out how to get NAT reflection working, so that users accessing mail.example.com in Outlook 2010 (which apparently adds Outlook over HTTP by default) were getting redirected to the internal interface on the firewall (which had a self-signed somefirewall.local certificate).

I solved the problem by setting up split DNS: I created a Zone for example.com in Active Directory DNS (and added all the appropriate records and sub-domains such as A, CNAMEs, MX, TXT, etc.) and made sure that mail.example.com resolved to the Exchange Server's internal IP address. Worked without issue, but it's a pain to have to remember to keep both Zones (real and internal) up-to-date if there's no trust/automated method of doing so.

EDIT

This should work for you if you create a zone for mail.company.com and create an A record for (parent) to resolve to your internal Exchange server because if the mail.company.com certificate is installed on Exchange, it should be valid/trusted.

gravyface
  • 13,947
  • 16
  • 65
  • 100
  • 2
    Create your split zone as "mail.company.com" not "company.com". In the "mail.company.com" zone add a blank "A" record referring to the IP address of the Exchange Server computer. Then you don't have to keep the rest of the "company.com" records in sync. Pain relieved. – Evan Anderson Dec 29 '11 at 01:26
  • Ahhh, Good call – gravyface Dec 29 '11 at 01:50
0

To remedy this issue, you will need to a new certificate! Why is that? Because you'll need the certificate subject to match both mail.company.com, exchange0.company.com and preferably autodiscover.company.com also.

A workaround would be to use a wildcard certificate for all services (*.company.com)

Mathias R. Jessen
  • 24,907
  • 4
  • 62
  • 95
0

I fixed mine with these 4 commands (change server names/web URLs as needed)

Set-ClientAccessServer -Identity EXCHANGE-SERVER -AutoDiscoverServiceInternalUri https://exchange-server.example.com/Autodiscover/Autodiscover.xml

Enable-OutlookAnywhere -Server EXCHANGE-SERVER -ExternalHostname "exchange-server.example.com" -DefaultAuthenticationMethod "Basic" -SSLOffloading:$False

Set-OABVirtualDirectory -identity "EXCHANGE-SERVER\OAB (Default Web Site)" -externalurl https://exchange-server.example.com/OAB -RequireSSL:$true -InternalUrl https://exchange-server.example.com/OAB

Set-WebServicesVirtualDirectory -identity "EXCHANGE-SERVER\EWS (Default Web Site)" -externalurl https://exchange-server.example.com/EWS/Exchange.asmx -BasicAuthentication:$True -InternalUrl https://exchange-server.example.com/EWS/Exchange.asmx

I restared IIS after for good measure.

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
Samuel Lincoln
  • 1
0

Fixed the odd security alert via switching to Offline Mode in Outlook and back to Work Online. The alert was popping up one minute after opening Outlook. Name on certficate was not matching name of connection. All webservices, oab, ecp, autodiscover, activesync, owa, um were set properly.

cashew
  • 1