IIS Bindings SAN for Exchange

I’m using Server 2012r2 with MS Exchange and am having a problem but I’ll first describe the setup.

IIS starts off with a site called Default Web Site and, when you install Exchange, a number of subdirectories are created within that site for Exchange functionality like Autodiscover, Outlook Web Access, etc.

Since these are virtual subdirectories rather than separate websites, you need a SAN certificate for Exchange functionality -at a minimum autodiscover.yoursite.com but also perhaps owa.yoursite.com depending on how your server is setup.

I was able to create a SAN certificate simply by creating a port 80 http binding in the Default Web Site for whatever I wanted in the SAN name, e.g. bind autodiscover.yoursite.com to port 80 and, using Let’s Encrypt WinSimple, I can get a SAN certificate that includes autodiscover.yoursite.com bound to port 443.

This is all great except Exchange won’t work with multiple bindings to the same port in a website, meaning I have to go into my Default Web Site, create a bunch of subdirectory bindings, run Let’s Encrypt WinSimple, then go into my website and delete every port 80 and port 443 binding except for one of each because otherwise Exchange throws a million errors.

So my two questions: 1, is there some other way to go about creating the SAN certificate with my Exchange setup other than what I’ve been doing (creating the port 80 bindings then later deleting them)? And 2, am I going to have to do this every 90 days when the certificate expires or is making then deleting those bindings a one-time thing and my SAN certificate will renew just fine without them?

Thanks.

You could use a DNS challenge, if your DNS provider has a suitable API to make it automatic.

You would need to renew it every 90 days ( to essentially prove ownership)

Unfortunately my DNS provider is having problems with their API keys and don’t anticipate a quick fix. Is there a way to do the DNS challenge using the DNS on my Windows Server? Alternatively, is there a way to do the http challenge on IIS without the need to create bindings for subdirectories? Because otherwise I’m stuck with a tedious manual method that’s going to break my Exchange server for a bit every 3 months which doesn’t seem like a great solution either right? Thanks.

If you make your Windows server be the Authoritative DNS server for your domain, yes. Personally I like to separate out the DNS and server - but you could use an alternative such as the free cloudflare DNS service

Not that I'm aware of - although someone more familiar with that windows server may have an idea / option.

My personal preference is the DNS method, which I've found works really well, easy to automate, and hasn't given me any issues.

hi mobamoba

i usually create a .acme-challenges directory for each site (iis site not binding).

That means i dont have to rebind and the authentications will work.

Could you be more specific? You’re saying under Default Web Site with a subdirectory Autodiscover you then create a subdirectory of Autodiscover called .well-known and that allows you to get a SAN with autodiscover.yoursite.com?

nope i create a directory at the root.

below is an example.

mobamoba,

have you been able to get this working ?

I have been having similar issues, but have tried both the win-simple and ACME-POSH to no avail.

I would be interested in collaborating with you to try and sort this out once and for all, so others who follow can get it running quickly and easily…

please let me know if you got it sorted or just gave up and bought a SAN CERT.

Thanks
JD

I did get this working but not in any way remotely “pretty” - but it works. I used Lone Coder’s Let’s Encrypt Winsimple with the --san flag (the wiki at his/her site has pretty detailed instructions). To make it work, I used two websites within IIS.

The first was Default Web Site with all the Exchange stuff and everything else under it. There, I bound two sites; my server name to port 80 (you may not need this but my Exchange Management Console threw a million errors unless my server name - e.g. server2012.domain.com - was bound to port 80); I bound port 443 to my actual external domain name.

The second site had everything I actually wanted to bind (since, as I mentioned, I was forced by Exchange to bind my internal server name to port 80 on my Default Web Site and therefore couldn’t bind my actual external domain name to port 80 there), e.g. www.mydomain.com, autodiscover.domain.com remote.domain.com, owa.domain.com, etc. I bound each of those to port 80. Because this was a fake site used for nothing other than ACME challenge to those subdomains it didn’t matter that a bunch of sites were bound to port 80.

Within both sites, I also had to go to Directory Browsing and enable it because the ACME challenge failed otherwise, though that may not be true for you.

Anyway that all worked. Like I said, not pretty, and I knock wood Windows Server at some point gets the same attention as Certbot gives to Linux because, really, this is a painful mess in the end and only doable because my organization is tiny. I can’t imagine a valid use case for Let’s Encrypt within an actual mid-size to large organization or one without a dedicated IP department because the complexities of Exchange and all the additional components of Windows Server (like remote access for example or RDP gateways) are so deeply intertwined with IIS and Let’s Encrypt really seems almost exclusively designed for “modular” systems like Apache and Nginx where your web server is over here and all of the applications, directories, subdomains, and aliases are kind of “slaves” that that main server. Not so with IIS and, thus, difficult with Let’s Encrypt.

Hopefully this will work for you.

Sounds like you have a small business server ? not just pure exchange, by your comments about RDP and the remote.domain.com that you mentioned.

I was able to get a certificate with win-simple, but only the testing certificate … once I went to the live certificate (ie took out the -testing commandline), no certificate was made, the authentication just timed out on all the SAN domains. everything works fine in testing, but nothing once testing is stopped …

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.