Eliminate certificate warning when users access Outlook/Exchange 2010 on split domain setup

32,821

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
Share:
32,821

Related videos on Youtube

tacos_tacos_tacos
Author by

tacos_tacos_tacos

Updated on September 18, 2022

Comments

  • tacos_tacos_tacos
    tacos_tacos_tacos almost 2 years

    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

    • ravi yarlagadda
      ravi yarlagadda over 12 years
      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?
    • tacos_tacos_tacos
      tacos_tacos_tacos over 12 years
      This info has been added in the edit
    • ravi yarlagadda
      ravi yarlagadda over 12 years
      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.
    • tacos_tacos_tacos
      tacos_tacos_tacos over 12 years
      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?
    • ravi yarlagadda
      ravi yarlagadda over 12 years
      That would work if all of the clients connecting to the exchange0 name would trust that certificate.
    • tacos_tacos_tacos
      tacos_tacos_tacos over 12 years
      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
    • ravi yarlagadda
      ravi yarlagadda over 12 years
      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
    • tacos_tacos_tacos
      tacos_tacos_tacos over 12 years
      Should I be doing this on "Default Web Site"? Is this safe to do?
    • ravi yarlagadda
      ravi yarlagadda over 12 years
      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.
    • tacos_tacos_tacos
      tacos_tacos_tacos over 12 years
      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
  • gravyface
    gravyface over 12 years
    Are StartSSL free certificates trusted by all major browsers?
  • MadBoy
    MadBoy over 12 years
    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 startssl.com without warning it should be fairly safe ;-)
  • Spence
    Spence over 12 years
    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.
  • gravyface
    gravyface over 12 years
    Just did. FireFox complains about it. Chrome appears to be ok, but then says unverified issuer under the certificate details.
  • gravyface
    gravyface over 12 years
    Ahhh, Good call
  • MadBoy
    MadBoy over 12 years
    I use it in FireFox 11 and IE and it's fine.