SSL Cert (Mismatch) Using the wrong Certificate
Hi I am having an issue with connecting through the autodiscovery. I have the autodiscover setup correctly per the whitepapers that I have read.. I am running into a problem where it is taking the ssl certificate of my webserver and not using the certificate of the exchange server. Below is how I have it setup....I have the external URL for autodiscover as HTTPS://exchange.domain.com/autodiscover/autodiscover.xmlI have the SSL installed on the Exchange server as exchange.domain.comOn a separate server I have my webserver hosting all of the domains... I have a shared SSL installed on that server called ssl.domain.comOn the Webserver, I have an autodiscover website created with bindings to autodiscover.domain.comThis site then redirects to HTTPS://exchange.domain.com/autodiscover/autodiscover.xml.When I remotely connect to the server I get a redirect statement and I ok it. Then I get an SSL certificate popup stating that there is a mismatch. When I go to the details , I see that it is pulling the ssl.domain.com certificate! How can it do this? I have never installed that cert on the CAS and I have the autodiscover site redirecting to the proper server.Any suggestions would be great.Thanks
September 21st, 2009 9:16pm

Do you have a DNS entry for exchange.domain.com URL pointing to CAS server? Michael
Free Windows Admin Tool Kit Click here and download it now
September 22nd, 2009 2:41am

Please run the below Tool and see where it is failing https://www.testexchangeconnectivity.com/ Vinod |CCNA|MCSE 2003 +Messaging|MCTS|ITIL V3|
September 22nd, 2009 1:52pm

On the Webserver, I have an autodiscover website created with bindings to autodiscover.domain.comIf theAutodiscover website has a certificate associated to it, than the webserver certificate will be shown.Check the certificate bindings to exchange.domain.com....Read th article below which can help you out to configure Autodiscover correctly....The article is for a different issue but the procedure to configure certificates is the same..http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/
Free Windows Admin Tool Kit Click here and download it now
September 22nd, 2009 5:27pm

You do not set the ExternalURL for Autodiscover. You configure the AutodiscoverServiceInternalURI for domain joined users who have access to Active Directory by using the Set-ClientAccessServer cmdlet. For non-domain joined clients as well as clients external to the network who do not have direct AD access will use https://primarysmtpdomain.com/autodiscover/autodiscover.xml and if that fails, it will use https://autodiscover.primarysmtpdomain.com/autodiscover/autodiscover.xml. Most people will use the autodiscover.primarysmtpdomain.com and add that to their certificate. You will also want to have the FQDN used for AutodiscoverServiceInternalURI on your certificate. In addition to the article Hari linked to, I also wrote another article which goes much more in depth on Autodiscover, DNS, and Certificates. You can see that here: http://www.shudnow.net/2008/11/18/autodiscover-dns-certificates-and-what-you-need-to-know/MVP | MCITP: Enterprise Messaging Administrator | MCTS: OCS + Voice Specialization | http://www.shudnow.net
September 23rd, 2009 6:24am

Hi,The external URL for autodiscover cannot be configured. By default, it uses the two predefined URL: Https://domain.com/autodiscover or https://autodiscover.domain.com/autodiscover. If that failed, it will try HTTP redirect, next try DNS SRV record.Thus, the sslo.domain.com should be used for the external clients. That's default behaviour.If you plan to do the HTTP redirect, please ensure the connection for autodiscover.domain.com should be HTTP rather than SSL. To achieve this, we need to make the autodiscover webiste without SSL, and set the redirect to the https://exchange.domain.com/The below article is for your reference: (Method 2: Http Referral)http://msexchangeteam.com/archive/2007/04/30/438249.aspxThanksAllen
Free Windows Admin Tool Kit Click here and download it now
September 23rd, 2009 1:42pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics