AutoSSL, Autodisovery issues

What was the outcome of support request 7943177 from this closed thread:
AutoSSL and Autodiscovery

This is still a real issue in January 2018.

Customers who use Office 365 and AutoSSL cause issues on the server. Their Outlook (and some others like Skype) clients keep hammering at https://example.com/autodiscover/autodiscover.xml and other autodiscover URL's. I've seen them with different capitalization as well [URL='https://example.com/AutoDiscover/autodiscover.xml and as both POST and GET.

Sometimes the log entries are in the standard domain logs, but I also find entries like the following in /usr/local/apache/domlogs/proxy-subdomains-vhost.localhost:

"GET /autodiscover/autodiscover.xml HTTP/1.1" 302 - "-" "Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7190; Pro)"

One of the main issues is that AutoSSL can't install a cert for the autodiscover.domain.com subdomain because (for Office 365 and others) that is a CNAME to another host. So the AutoSSL verification file can't be retrieved.

Several things need to happen. The httpd.conf ScriptAliasMatch entries need to account for the word "autodiscover" in a case-insensitive way, or to find all uses in the wild and account for them.

For example:

https://example.com/AutoDiscover/autodiscover.xml (Doesn't work, loads a standard 404 page, should be same as the following)
https://example.com/autodiscover/autodiscover.xml (works)

Next, when the above URL doesn't work (or some version of Outlook or other client chooses to check the autodiscover subdomain before the naked domain) you run into the SSL issue.

Autodiscover pecking order:
enterpriseit.co/microsoft-exchange/outlook-autodiscover-order/

If the above article is correct, an SSL cert for the autodiscover subdomain SHOULDN'T be needed because it should try without the autodiscover subdomain first and succeed. But if it doesn't succeed or it tries the subdomain first (and in some cases that seems to be what is happening) it moves on to the autodiscover.domain.com subdomain and fails because it's connecting with https on port 443 and that will fail because AutoSSL wasn't able to verify it and install that subdomain in the cert (see above).

But what seems to be really standing out is that when https://autodiscover.example.com is accessed, without a valid cert because of the issues mentioned above, the server hangs. It does come back with a "This site can’t be reached autodiscover.domain.com refused to connect." eventually if accessed via a browser as a test, but the browser continues to churn and say "connecting" for some reason for a long time after the error message appears.

And it is creating a ton of TIME_WAIT connections on the server on port 443. These eventually invoke a block by csf because they look like a slowloris attack. And with the new csf and the MESSENGER features, port 8887 then gets slammed with all the connections that had been going to 443. If you don't know the csf MESSENGER feature is a way to allow legit customers to unblock themselves in some cases via a custom web page and recaptcha. But it seems that special page is sent even if the connecting client isn't a browser.

QUESTION: If autodiscover.domain.com is a CNAME to autodiscover.outlook.com do you really need an SSL cert for autodiscover.domain.com? Doesn't the request go to autodiscover.outlook.com immediately? Need help understanding this part.

So, I still haven't pinpointed everything that is happening, but some input would be greatly appreciated.

 

I can submit a ticket, but this is less of a specific issue that needs to be solved immediately and more of an issue that could use some discussion. Is there somebody willing to discuss this issue a little?