Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Right, I want to issue a certificate for web mail access to exchange, so I've created a request for mail.domain.com (no other domains).

I've then completed the certificate request and imported it and issued the 'IIS' service to the new cert, all other services are still assigned against the locally assigned cert.

However, when I open Outlook I get: enter image description here

Which Outlook is seeing the certificate issued to CN: mail.domain.com but locally the server is known as exchangeserver.local, so hence the names do not match. I've tried adding autodiscovery and the local name to the cert but makes no difference, what am I missing???

share|improve this question
1  
Why not just buy a UC cert from a trusted 3rd party CA? Entrust, VeriSign, Comodo, etc. are all great places to buy a UC which is tailored for things like Exchange. If you need help let me know. –  Brad Bouchard Apr 25 at 14:37
add comment

4 Answers 4

Changing the internal server names, as suggested by MichelZ, is one option, but personally, I find it easier to add a bunch of names to the SAN (Subject Alternative Names) field in the certificate to be a lot easier.

The corporate Exchange server I manage, for example, has 17 SANs on the certificate - so there are 18 names the users can use to access the mail server without generating a certificate error.

Either way, make sure your certificate is loaded in both IIS and Exchange, though.

share|improve this answer
    
The problem with this is that public CA's do not take just ANY name namymore... you can't just add your internal domains to the SAN list anymore. Please refer to: digicert.com/internal-names.htm So the "wise" thing is to do it "right" :) –  MichelZ Apr 25 at 16:37
    
@MichelZ Hard to be sure, but it sounds like he's doing a self-signed or internal CA certificate. But yes, to get a public CA cert anymore, you need your Exchange server to be off that .local (etc) tld crap that you never should have been on to begin with. :) –  HopelessN00b Apr 25 at 16:40
    
As he has a cert for mail.domain.com, I highly suspect that he has a public CA, and not an internal one. –  MichelZ Apr 25 at 16:41
    
@MichelZ Fair point. Then again, we have a cert for mail.domain.com that's from our internal CA (cries), so either way is possible. In fact, a lot of companies I've worked with don't even want users accessing webmail from non-company devices (concern about data leakage and such), so not having a publicly trusted SSL cert for the mail server is not a problem at all. –  HopelessN00b Apr 25 at 16:43
1  
@MichelZ No, but financial sector companies are one group, as are defense contractors, or really any company with serious intellectual property concerns, such as software development firms and startups. And then, of course, there are the overly-concerned-for-no-good-reason weenies who think security is a thing or a tickbox, and don't want people downloading all their emails to their home PC, but evidently have never seen a USB flash drive. <sigh> Guess which type I work with the most. –  HopelessN00b Apr 25 at 16:50
show 1 more comment

You need to change your "internal URL's" to the external names, and ideally change the DNS of the external names to your internal server IP on your internal DNS

Set-WebServicesVirtualDirectory -Identity "EXCH-1\EWS (Default Web Site)" -InternalURL https://mail.domain.com/EWS/Exchange.asmx -BasicAuthentication:$true
Set-OabVirtualDirectory -Identity "EXCH-1\OAB (Default Web Site)" -InternalUrl https://mail.domain.com/OAB
Set-ActiveSyncVirtualDirectory -Identity "EXCH-1\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"
Enable-OutlookAnywhere -Server EXCH-1 -ExternalHostname mail.domain.com -ClientAuthenticationMethod Basic -SSLOffloading:$false

Have a read here for more details

share|improve this answer
add comment

An Exchange certificate may need various SANs (Subject Alternate Names) depending on the names the server is going to be accessed with; typically, for a single-server setup, this requires at least three SANs:

  • mail.domain.com - your server's external hostname
  • servername.domain.local - your server's internal hostname
  • autodiscover.domain.com - autodiscover for your SMTP domain

Your situation can be quite different, though, depending on your server configuration; the internal and external DNS names can be made identical, and autodiscover might not be needed.

In short: if your server is going to be accessed using a name that is not included in the certificate SANs, you will get that error.

share|improve this answer
    
The problem with this is that public CA's do not take just ANY name namymore... you can't just add your internal domains to the SAN list anymore. Please refer to: digicert.com/internal-names.htm So the "wise" thing is to do it "right" :) –  MichelZ Apr 25 at 16:39
    
I don't know how this internal domain is configured, it could very well use a public name. Anyway, depending on the DNS and firewall infrastructure, he might not be able to use identical names for internal and external URLs. –  Massimo Apr 25 at 19:14
    
you're always able to do that somehow, even if it means distributing a hosts file to all clients ;) and he implies that the internal domain is *.local (it even says so on the screenshot) –  MichelZ Apr 25 at 19:16
    
I mentioned a typical default setup, which is likely the one the OP is running; I also said there are many possible configurations. Either way, the main point remains: the certificate has to include all the possible names the server is going to be called with. –  Massimo Apr 25 at 19:29
add comment

While MichelZ's answer is the proper one (and I would urge you to do it regardless) I can understand if you may have some hesitation doing this in a production exchange environment during business hours. For a quick temporary fix until you can implement the proper one you can try looking for the _autodiscover srv record in your internal domain forward lookup zone _tcp container. If it does not appear create a new srv record named "_autodiscover" proctocol: _tcp priority: 0 weight: 0 port number: 443 and use your external name for the host offering (make sure you have an A or CNAME record created already.) For this to work all affected clients will need to clear their DNS cache but it should stop the warning pop-ups until you get the time to do Michel's answer.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.