AutoSSL, Autodisovery issues

[vikins]

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.

 

[cPanelMichael]

Hello @vikins,

Ticket 7943177 was closed without a resolution due to a lack of response from the submitter. Could you open a new ticket so we can take a closer look at an affected system/domain? You can post the ticket number here and we will update this thread with the outcome.

Thank you.

 

[vikins]

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?

 

[cPanelMichael]

Hello,

A support ticket would allow us to review a specific domain name experiencing the issue and more quickly identify if this is a defect in the product, or if there's some configuration setting related to the issue you are facing. There's no charge to open a support ticket, and we're happy to update this thread with the outcome if you post the ticket number here.

Thank you.

 

[WorkinOnIt]

What was the outcome? I also have a user that has Remote Mail Exchanger set in DNS profile as they are using Outlook 365 remote mail. The "autodiscover.domain.com" is preventing the re-issue of a SSL renewal.

2:18:06 PM WARN AutoSSL will defer the renewal of “domain.com”’s certificate because 1 domain (autodiscover.domain.com) that the current certificate secures failed DCV. If AutoSSL renewed the certificate now, that domain would lose SSL coverage. AutoSSL will defer “domain.com”’s certificate renewal until 4/13/18, 12:00 AM UTC (3 days before expiry) or until all of “domain.com”’s currently secured domains pass DCV. at bin/autossl_check.pl line 537, <DATA> line 1.

 

[cPanelMichael]

Hello @WorkinOnIt,

If you are pointing the autodiscover subdomain to a remote host, then AutoSSL will not be able to issue a certificate for it. If that's the case, you will need to exclude the autodiscover subdomain using the SSL TLS Status option in cPanel:

SSL TLS Status - Version 70 Documentation - cPanel Documentation

Let us know if that helps.

Thank you.

 

[WorkinOnIt]

@cPanelMichael - that was a helpful link.

I am not sure why autodiscover was missing from the domain's DNS file.

I simply added it to the DNS zone file and all is now well. However, I note in future, I can also achieve this by logging into the user's cpanel account and following the instructions on the link you provided.

Thanks again.

 

[cPanelMichael]

I am not sure why autodiscover was missing from the domain's DNS file.

I simply added it to the DNS zone file and all is now well.

Hello,

I'm glad to see it's now working. Note that we do have a case in cPanel & WHM version 70 that should fix instances of missing proxy subdomains:

Fixed case CPANEL-17258: Do a one time check for missing proxy subdomains

Thank you.