0

Here is the scenario. Exchange server runs on a lan. Clients interact with the server via ActiveSync over HTTPs connections served by IIS. IIS is using a cert with SANs that are appropriate for the local domain. An example would be *.corpdomain.com. I'm attempting to allow access to the server via TailScale (Wireguard) to an iOS client. The issue that arises is that when a connection is established via the Wireguard tunnel, the client device fails the connection due to a mismatch in the server name being contacted and the SANs available on the cert. When using the Wireguard tunnel, the connection request will either be made to the machine name or the on tunnel ip address. That causes the desired routing of the connection. The question becomes, how to handle the mismatch between the requested server name and the SANs on the cert. It seems like the only option is to add either the Machine name or the machine IP being used in the connection request to the list of SANs on the cert is the only option. That doesn't seem right though. Would a CA approve a SAN that is not a FQDN? I woudln't think so. As for the IP, I have no guarantee that is static. It doesn't seem wise to have that added either. Is there some other mechanisim in IIS that is able to serve a separate cert for a common site based on the SNI? I'm unsure how to best solve the cert problem here.

Digital ink
  • 490
  • 10
  • 22

1 Answers1

0

The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange.

What the official document said like below: enter image description here

So you could try adding the host name to your certificate.

joyceshen
  • 89
  • 3
  • When I considered that, the first thought that came to mind is a hostname without being a FQDN could be problematic. I've created certs with that setup privately but I've never asked a public CA to do that. Even if they would include a SAN that isn't a FQDN, would that be secure? If I lost control of the cert, could it be used for impersonation somehow if it had a SAN that isn't a FQDN? Those are the questions that cased me to be hesitant about that course of action. – Digital ink May 26 '22 at 16:21
  • What's your host name looks like? – joyceshen May 30 '22 at 06:47