6

I have the following configuration with Exchange Server 2010:

  • I have a self-signed certificate which is associated with all the services (POP, SMTP etc..) except IIS (which is associated with a certificate issued by Verisign and it works perfectly on the webmail).
  • When I visit the webmail (https://webmail.example.org/owa), it works perfectly.
  • All Outlook clients are configured to use the server's local name (like DOMAIN.SERVER, because they're on the same LAN) and not the domain with which the webmail is associated.

The problem is:

When users connect to the Exchange Server (using local LAN) though Outlook 2010, this warning is shown (in italian):

Outlook certificate mismatch error

Translation: it says that the certificate is issued by an authorized provider (VeriSign in this case), the date is valid BUT there's a name mismatch (the name written on the certificate doesn't correspond to the server's name).

If I press the "Show certificate" button (the last one in the picture above), the certificate associated with IIS is shown: how can it be possible? I mean, it should only be used when connecting through Webmail.

Is there a way to avoid using an SSL certificate in local LAN but only for webmail?

Thank you

UPDATE

This warning didn't show with Exchange 2003: we are using the same certificates.

4

Your certificate is for webmail.example.org. If you're connecting to your Exchange server via server.domain, then the name will not match the common name in the certificate, thus the error.

You either need a certificate that includes both names or you always have to use the external name (even when on the LAN).

To make sure your clients use the external connector for your Exchange services, here are a few commands that may help:

  • EXCHANGE-SERVER is the hostname of your Exchange server
  • exchange-server.yourdomain.com is the externally visible name of your Exchange server

Commands

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

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

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

Set-WebServicesVirtualDirectory -identity "EXCHANGE-SERVER\EWS (Default Web Site)" -externalurl https://exchange-server.yourdomain.com/EWS/Exchange.asmx -BasicAuthentication:$True -InternalUrl https://exchange.haseke.de/EWS/Exchange.asmx
4
  • But this error didn't occur with Exchange 2003: the certificates were the same. The was a self-signed certificate and an authority-signed certificate for Webmail. Is there a way to disable this warning on Outlook or to disable the usage of certificates internally on the LAN? – Umar Jamil Jun 18 '14 at 11:08
  • 2
    Exchange 2010 don't support internal/external zones when it comes to the SSL certificates. It's only bound to the services. This answer is as correct as it will get. – xstnc Jun 18 '14 at 11:41
  • @UmarJamil I added some commands which I pulled from our documentation. We used those for our own installations. I hope they help. – Der Hochstapler Jun 18 '14 at 13:03
  • Not sure if it matters, but: "...then the name will not match the common name..." - putting a DNS name in the Common Name (CN) is deprecated by both the IETF and CA/B. DNS names go in the SubjectAltName (SAN). Use CN for a friendly org name like "Example Widgets". – jww Jun 21 '14 at 9:16
1

Start configuring exchange server without .local internal network access Exchange services compulsory requires SSL certificate. Old practice configuration add .local names itself.

Recently I renewed my exchange server ssl from ssl2buy. I heard interesting news from there that CA/Browser from announced new guide that no CA can issue ssl certificates for hostname (NetBIOS names) and .local domain names later Oct 2014. All currently issued ssl for .local names support should expire before Oct 2015. Also Microsoft will add this change in next update.

I checked with Digicert, GeoTrust and Comodo. All said same. So I changed my server configuration and removed .local instances. If I don't change this now, have to do next year, but change is for sure.

More interesting is my previous exchange ssl from digicert was for $250+ and this new comodo exchange ssl is just for $45. Both works good and I don't see any issue.

You can try it there https://www.ssl2buy.com/comodo-multi-domain-ssl.php

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.