4
MAPI Auto Discover SSL warning
Question asked by Chris Danks - 6/9/2020 at 1:50 AM
Unanswered
HI

we host our DNS & Website on Linux but point all the DNS records like autodiscover to the hostname of our smartermail server.

In SM on domains > mydomain > hostname is set to the SM server name which has SSL.

When I open outlook I get this warning:


is there somewhere I can set outlook to use the SM Server hostname and not autodiscover.DOMAIN ?

We've got thousands of domains over all of our SM servers and they all work the same way.

if not.. is their a tool we can use to create free SSLs for autodiscover. ALL_DOMAINS_IN_SM that auto renew too and bind to IIS?

10 Replies

Reply to Thread
1
echoDreamz Replied
we wrote a c# app to handle creating all the required ssl cents and bindings for all our domains, but the auto discovery stuff in SM needs to be more flexible in allowing us to specify an override host name per protocol. 
0
Nathan Replied
Configuring an SRV record rather than an 'autodiscover' CNAME seems to yield better results, albeit Outlook complains once due to a redirect but it causes less alarm to users than the certificate error. 
0
Douglas Foster Replied
Certificate technology is pretty generic, it appears that you do not have the right certificate configuration.   I don't see any way that this is a SmarterMail problem.

Basic certificate logic is that the DNS name used to make a connection must match a name on the certificate presented by the server.   This match proves that you are connected to the intended server, and that your session was not hijacked in transit.

Consequently, autodiscover.yourdomain needs to be a SAN on your server certificate.   If you create a unique host name for each client, you need autodiscover.clientdomain and actualhost.clientdomain included on the certificate.  As far as I know, you can have an essentially unlimited number of Server Alternate Name (SAN) entries on a certificate (for a price).   I have certainly seen certificates with a very long list of entries.   If you are using the freebie Let's Encrypt certificate, your options may be more limited.  

You can also use wildcard certificates to make the host portion unimportant.  As far as I know, a wildcard can only be the primary entry, not a SAN, so you can only have one wildcard domain on a certificate.

0
Tim DeMeza Replied
We only have a few domains, but I would prefer to have everyone using a single domain for configuration.  Is that even possible?

For example:

DomainA
DomainB
DomainC
DomainD

Everyone can use www.domainA.com for webmail. 

Everyone can manually configure IMAP etc to use mail.domainA.com.  

So why can't autodiscover do the same thing for IMAP?  If it can be done, can someone please explain it?

Thank you!
0
Douglas Foster Replied
mail.domainA.com is a different name than www.domaina.com, so both names need to be on the certificate.  But you do not need to use two different names when only one server is involved.    The DNS name is used to generate an IP address, and the name-to-ip process is the same regardless of the protocol being used.  But if you have already configured users with multiple host names, it may be easier to pay for a certificate with extra SANS than to annoy your users.

As an aside, I would avoid using the www prefix for the web interface, as most domains want to use that name as a public-facing home page for the domain.  But you may have just been using that as an example.

If you have an incoming gateway (a server sitting in front of SmarterMail), then you will need a unique name for each server and a certificate for each host name (or a wildcard certificate).   For example, mx.domaina.com could be your incoming gateway server, and webmail.domaina.com could be your SmarterMail server.  But it sounds like you have a single-server configuration.

1
Nathan Replied
In a service provide scenario the goal is to not have to manage multiple certificates or SAN certificates but to have a mechanism that autodiscovers using the correct/underlying server name. SRV records seem like the easiest way of achieving this as the server name to discover against can be specified but due to the implementation within Outlook it appears this will flag a 'redirect' which disrupts the automated nature of discovery.
0
Larry Duran Replied
Employee Post
Hey all,

Here are a couple of links you may find helpful on how Outlook performs it's autodiscover lookups.


Right now in SmarterMail, we have web request handlers that listen for autodiscover requests regardless of what domain name they come from.  So if your SmarterMail server is configured to receive requests from domainA.com and domainB.com, then we will handle autodiscover requests that have either domain.  I think this is part of the problem that you are reporting because in Outlook you will setup a profile for user@domainA.com and Outlook will use the domain of user@domainA.com to start autodiscover lookups.  Since our handlers are not restrictive, we'll return an autodiscover response with domainA.com for that user.

If we wanted to limit these requests to the main SmarterMail domain, or at least have it configurable, then that would require changes on our part.  I think if you properly have your SRV records setup and SmarterMail only honored autodiscover requests based on those records, then this should point us in the right direction that you are asking for.

Since we don't have support for this today I'll have to mark it as a feature request that will probably span across all protocols with autodiscover.
Larry Duran Software Developer SmarterTools Inc. www.smartertools.com
4
echoDreamz Replied
Our biggest request is to allow overriding of each protocols hostname. Since MAPI, EWS and EAS can all easily use mail.customerdomain and protocols that cannot really have per host certificates like SMTP, POP, IMAP, XMPP, we use mail.ourhostname for those.

I know it's on the board, but it would be a big help for our environment.
0
Chris Danks Replied
I second the above comment from @echoDreamz
0
Chris Replied
My testing today shows that having just the SRV record works. 

The problem with having both the A or CNAME for autodiscover.customerdomain.com AND an SRV record pointing to mail.yourserver.com, is that the autodiscover.customerdomain.com takes priority over the SRV record.

Therefore requires that autodiscover.customerdomain.com matches the SSL certificate. In other words, you would need to add autodiscover.customerdomain.com for each of your customers on the certificate. They do have multi-domain certificates available for this.

You can remove the A / CNAME for autodiscover.customerdomain.com and have just the SRV record only.

Per Nathan Y's reply above, Outlook only nags you the first time you setup an email account in it. 

Reply to Thread