(In reply to Ben Bucksch (:BenB) from comment #15)
This really looks like a misconfigured server. Can you please just fix this, and we can move on?
I admit this is a probably very rare constellation and I will probably also reconfigure my server, but actually I cannot see a real "misconfiguration" here.
I'd assume that wildcard DNS entries are not that uncommon, and AFAIK there's also no rule or convention which forbids a domain's default host to use HTTP Basic Authentication.
I've not dealt with Exchange AutoDiscover before, but read about it now at https://docs.microsoft.com/de-de/exchange/architecture/client-access/autodiscover?view=exchserver-2019 (no idea if it's an authorative description) and glanced at https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxdisco/d912502b-c0e2-41a1-8b0e-f714ba523e08 (which seems to be the discovery protocol spec) and https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxdscli/78530279-d042-4eb0-a1f4-03b18143cd19 (which seems to be the actual lookup protocol).
Concerning [:mkmelin] comment that the protocol would not expect / allow the http-redirect URL to query for username and password, the "[MS-OXDISCO] Autodiscover HTTP Service Protocol" document at least discourages serving config settings via http directly, and only using the http-URL to perform a 302 HTTP redirect to an https-URL. It does not strictly require it, though. (The wording is "SHOULD" and "SHOULDN'T", not "MUST".) It does not say anything about authentication, as far as I could see.
"[MS-OXDSCLI]: Autodiscover Publishing and Lookup Protocol" recommends the use via HTTPS and recommends the use of client authentication before serving config details, but does not strictly require either.
However, sending login credentials via unencrypted channels is probably no really good idea nowadays. (At least not before explictly asking. Which brings me to the question: Did the TB Exchange Wizard possibly send my mail username and password in plain text to my server in an attempt to authenticate?!? I really hope it didn't, and this would be a real security hole from my point of view...)
However, once you're redirected to the https-URL, a certificate name mismatch would make it immediately clear that the TB Exchange Wizard is on the wrong track. (And would need to react accordingly of course.)
The current UX is pretty bad, though, as such constellations (even though rare) can happen (as my case shows) and the TB Exchange Wizard does not give any indication concerning what went wrong or why it gets stuck.