-1

Unfortunately i am no expert in the field of DNS, exchange and stuff so i am struggling with a problem. So please forgive me if it is obvious for someone else. I tried to research myself but i just couldn't figure it out.

For a client i had to move a domain to a new hoster, and they have a separate hoster for their exchange server and mail. So when the domain was moved, i setup the correct mx entries as they were in the old dns config. Everything was working, but for outlook, which issued a security warning on autodiscover (the name on the certificate is invalid or does not comply with the name of the website).

The question is why? What have i missed? As far as i can tell the old website did not have any ssl certificates. The DNS entries are the same, but reflecting the new host and their nameservers.

  1. Do i need to configure something (forwarding or whatever) especially for autodisover.XXX.com?
  2. Is it a problem, that there is no wildcard certificate for the domain so autodiscover might not be covered?

I hope you can help me somehow.

patman
  • 99
  • Provide the true names involved without obfuscation. – Patrick Mevzek Dec 04 '17 at 16:53
  • why is that important? It is only a security risk discussing real names with server configuration... – patman Dec 04 '17 at 16:59
  • 1
    Depends if you want quick and specific help or if you want a lot of wild guesses and back and forth discussions. You decide.... And since your website, emails and domains are public I fail to see what security you gain by obfuscating them. – Patrick Mevzek Dec 04 '17 at 17:11

1 Answers1

0

Number one reason for this is that the URL https://example.com/Autodiscover/Autodiscover.xml works. That is often the case with web hosts who have setup one of the leading control panels with the default options. It attempts to use autodiscover for its own purpose. You need to get the host to turn it off for that domain - it can be done but a lot of support at web hosts will not have a clue.

Looking at the certificate that is presented will usually give you an indication of whether that is the case or not.

If it is your own SSL certificate that is being presented though then it will be something else - probably missing Autodiscover entries. Autodiscover operates on a fixed number of URLs, which Outlook will move through. WIth Exchange 2010 and higher Autodiscover cannot really be ignored, so you need to ensure that you have a valid entry in place.

Running the domain and a test account through the Microsoft test site will often tell you where the issue is. https://testconnectivity.microsoft.com/

Sembee
  • 2,884
  • 1
  • 8
  • 11
  • Do i understand this correctly: my .htaccess for the domain would intercept the autodiscover url, because i have a single entrypoint. This would cause a problem, right? And if so, what should the URL be doing? – patman Dec 05 '17 at 15:07
  • And if i understand correctly it also tries autodiscover.example.com subdomain. So could a subdomain forwarding help? – patman Dec 05 '17 at 16:10
  • Subdomain forwarding will not help unless you have Autodiscover.example.com in the SSL certificate. A wildcard in the domain can also cause problems. Test it - browse to the address and see what happens. – Sembee Dec 05 '17 at 21:49
  • Yes i did. It's the CMS error page as expected. The question was what the subdomain should be doing. I guess the exchange server would provide autodiscover, so it should probably redirect there? – patman Dec 06 '17 at 10:17
  • Ideally you do not want any CMS error page - that is the cause of the problems. You want a standard 404 message - anything else isn't seen by Outlook as a failure and cause it to continue on. CMS systems are the biggest pain when it comes to getting Autodiscover to work (after Microsoft's poor decision to try the root of the domain first). – Sembee Dec 07 '17 at 19:08
  • Okay thank yout very much. So some .htaccess like RedirectMatch 404 ^Autodiscover/Autodiscover.xml$ should work. – patman Dec 09 '17 at 15:10
  • No idea. Never tried that method. – Sembee Dec 12 '17 at 13:29