Windows Server 2012 R2
IIS 8.5
DNN 7.4 (DotNetNuke)
letsencrypt-win-simple
Heya everyone
I have multiple sites running from our self managed Azure VPS using the DNN website CMS.
We have recently installed and started using the letsencrypt-win-simple installer for providing Lets Encrypt SSL Certs to some of our sites and this has gone very smoothly and is by and large working very well, thanks to everyone involved!
The issue is that some sites don’t currently don’t want/need to have an SSL cert for a variety of reasons. no problem you say, just leave them and carry on, well this is what I thought too however it appears that this is causing an issue with autodiscover for office 365 on sites that don’t have SSL certs. This comes to light when autodiscover is looking initially for an answer at https://domain.com:443/Autodiscover/Autodiscover.xml when the site has no cert. instead it is showing the cert of another domain ( I guess by using a revers IP look up?
Site1.com (has Cert, this appears to be what ever domain I have most recently installed a cert for) Site2.com (no Cert)
Short term solution here is to install a cert for Site2.com but that doesn’t really fix the issue and I’m sure will continue to rear it head as there are many domain sites hosted on my server and I am sure there will be more domains/issues coming to light.
While I don’t know how to solve this, I can say that your web server is probably returning a default cert in this case (when asked for a cert for a site for which it doesn’t have one). For most purposes, web server developers have usually considered this behavior “better than nothing” and so it may not be particularly easy to turn off (nor is it easy to say what kinds of “turning it off” would make Office 365 happy).
If you control the whole hosting environment, a fallback option would be to host all of the HTTPS-aware sites on one IP address, and all of the HTTP-only sites on another IP address. In this case Office 365 won’t even be able to begin attempting to make an HTTPS connection because the connection will fail at the TCP layer—which is presumably the behavior that you used to see before you started rolling out certificates. When both are hosted from the same IP address, the client can at least try to begin the TCP connection on port 443 and then the TLS negotiation, whereas you would probably prefer for it to fail earlier, since it’s not going to end up getting a cert that it can accept.
unfortunately splitting the sites up into their respective https / http groupings just isn’t an option (moving and splitting off DNN sites is an absolute nightmare! Structurally they are technically all one website sharing one Datatbase and are one site in IIS).
I think you may be on the right track when you talk about a default cert… but am not sure on the solution.
I should also mention that I can navigate to any one of my none secure sites in a browser via https://www.domainnamehere.com and see the SSl error and the SSL cert for Site1.com
Potentially this will have more far reaching issues than just for outlook discover and I’m sure I can’t be the first person to have had this issue, yet my Google Fu has failed me.
The way the server decides which certificate to show is via Server Name Indication (SNI).
The common behavior of web servers today is to show a matching certificate if one is available, and a default or “fallback” certificate if no matching certificate is available. So if a client asks via SNI to talk to example.com, the server will respond with a certificate that includes example.com if it knows of one, and otherwise it will respond with a default certificate (which might not include example.com).
Perhaps the behavior you want in this case is for the server to simply disconnect, dropping the connection, if it doesn’t find a matching certificate. However, I don’t know offhand how to request this behavior in any web server.
My guess is that people who encountered this particular problem before have either endured it (maybe misunderstanding the underlying cause), got certificates for the missing sites, or moved the HTTP sites to a separate IP address. But maybe you could also ask on an Office 365 forum?
I am now having the same issue. So far I’ve tested 7 of our clients on shared IP webhosting accounts. Autodiscover tests pass for all 7 clients at testexchangeconnectivity.com. However, when trying to setup accounts on Android and iPhone, it fails to pull Autodiscover settings from the mail host. Instead, the iPhone and Android mail clients both attempt to setup mail accounts to domainname.com. This creates a certificate mismatch because the shared SSL certificate used on the shared IP doesn’t match the actual domainname.com address. We are at a standstill with this, as we have several clients affected and have made sure all pass the exchangeconnectivitytest.com tests. What has changed that has broken this for most of our clients?
Interesting that you haven't had an issues with this previously, we new to Letsencrypt and SSL in general so was assuming this was an inherent problem with SSL on shared IP. assuming that there have been no chnages to your server setup I would then have to wonder if the underlying issue has always been there and we are only aware of it now due to a change in the way in which Outlook 365 is handling auto-discover?