1

Our Exchange server has been running with an internally signed certificate for a while. Today I bought a trusted SSL certificate (wilcard) and installed on the server.

The certificate is issued to *.example.no and gives no security exceptions when I access the web interface at https://mail.example.no/owa from the web browser.

Now, when I open Outlook I get this certificate validation error. I've tried all the standard solutions provided, which mostly involved setting the external url as the internal url.

  • Internal FQDN: mx.example.local
  • External FQDN: mail.example.no
  • Error message: There is a problem with the proxy server's security certificate. The name on the security certificate is invalid or does not match the name of the target site mx.example.local. Outlook is unable to connect to the proxy server. (Error Code 10)

What I did:

Set-WebServicesVirtualDirectory –Identity ‘mx\EWS (Default Web Site)’ –ExternalUrl https://mail.example.no/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "mx\EWS (Default Web Site)" –InternalUrl https://mail.example.no/EWS/Exchange.asmx

Set-OABVirtualDirectory -Identity “mx\OAB (Default Web Site)” -InternalURL https://mail.example.no/OAB

Set-ActiveSyncVirtualDirectory -Identity “mx\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.example.no/Microsoft-Server-Activesync

Set-ClientAccessServer -Identity mx -AutodiscoverServiceInternalUri https://mail.example.no/autodiscover/autodiscover.xml

The result:

[PS] C:\>Get-WebServicesVirtualDirectory | Select InternalUrl, BasicAuthentication, ExternalUrl, Identity | Format-List

InternalUrl         : https://mail.example.no/ews/exchange.asmx
BasicAuthentication : True
ExternalUrl         : https://mail.example.no/ews/exchange.asmx
Identity            : mx\EWS (Default Web Site)

[PS] C:\>Get-OabVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/oab
ExternalUrl : https://mail.example.no/OAB
Identity    : mx\OAB (Default Web Site)

[PS] C:\>Get-ActiveSyncVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
ExternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
Identity    : mx\Microsoft-Server-ActiveSync (Default Web Site)

[PS] C:\>Get-ClientAccessServer | Select Fqdn, AutoDiscoverServiceInternalUri, Identity | Format-List

Fqdn                           : mx.example.local
AutoDiscoverServiceInternalUri : https://mail.example.no/autodiscover/autodiscover.xml
Identity                       : mx

After that I have

  • Recycled the IIS Application pool MSExchangeAutoDiscoverAppPool (that did not make the message go away so I ...)
  • Restarted the entire mail server (that did not make the message go away either so I ...)
  • Went into Control Panel -> Mail -> Email Accounts and chose Repair on my account (since I am making this post you might have guessed that this had no effect either)
  • Flushed DNS of the client computer (in case the autodiscover URL was ignored)
  • Repaired the email account once again
  • Tried to edit the account and put the public FQDN, mail.example.no, as server address
  • EDIT: Tried to delete and recreate the account. Deleted the entire mail profile, %AppData%\Local\Outlook and %AppData%\Local\Outlook folders. Still no success.

I am running out of ideas now... every site I have visited on the web suggests that I do what I just did and the result is expected to be just as my result....

UPDATE: One of my users cannot even log in with Outloook from their workstation. The account is OK (mail on mobile phone and web client works) but Outlook keeps repeating the password prompt and will not exit Offline mode.

UPDATE: Did a SSL check on Digicert website to see if the certificate is installed OK. The server passed all checks, only thing I was warned about was the use of SSL 3.0 protocol: Protocol Support TLS 1.1, TLS 1.0, SSL 3.0. SSL 3.0 is an outdated protocol version with known vulnerabilities.

UPDATE 150709:

Disclaimer: No real internal IP addresses were harmed making this update

  • I set up a new Forward Lookup Zone in DNS, mail.example.no with one blank (A) record pointing to 192.168.1.1, the hypothetical IP address of the mail server
  • In the Reverse Lookup Zone for 192.168.1.in-adds.arpa I have e (PTR) record named 192.168.1.1 pointing to mail.example.no
  • Downloaded DigiCert® Internal Name Tool for Microsoft Exchange
  • Ran the tool, the addresses were mostly correct but OWAVirtualDirectory ECPVirtualDirectory was still referring to mx.example.local so I changed them to mail.example.no

nslookup output looks promising:

D:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

D:\>nslookup mail.example.no
Server:  dc1.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1


D:\>nslookup 192.168.1.1
Server:  dc.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1

Outlook does not.....

Small test:

  1. Went to Account Settings -> More Settings -> Connection -> Exchange Proxy Settings.
  2. Changed the connection URL to https://mail.example.no
  3. Changed the allowed principal name to msstd:*.example.no
  4. Restarted Outlook. The Certificate error does not pop up now but I notice that I am not connected...
  5. Account Settings once more, this time I chose automatic Repair
  6. Restarted Outlook
  7. Now, if I go back to Exchange Proxy settings the internal URL has returned...
9
  • Use one of the many SSL checking sites to make sure you sent all appropriate intermediary certificates. You're not seeing the error I'd expect with this problem, but I always suggest checking it first. May 22, 2015 at 7:16
  • Isn't my problem that the target site identifies itself as mx.example.local ? I thought the changes above should make the target site identity itself as mail.example.no May 22, 2015 at 11:00
  • Checked the SSL certificate. Everything is OK. May 22, 2015 at 11:03
  • If the clients are connecting to mx.example.local, and the certificate doesn't contain that name, your changing the server configuration won't fix it. It says on the last command output you've pasted, FQDN : mx.example.local
    – Jenny D
    May 22, 2015 at 11:07
  • I know, and that is the problem. I am trying to update the configuration so the auto discover used by clients connect to mail.example.no, not mx.example.local. May 22, 2015 at 14:19

2 Answers 2

1

The certificate from the 3rd party issuer will need to have your internal FQDN as a Subject Alternative Name in order to be able to work with your local Autodiscover that LAN users using Outlook are trying to reach as the certificate sits on your IIS or Exchange.

Otherwise the users will be prompted for "SSL Certificate Name Mismatch" and on some instances they will be prompted to type their passwords again and again.

2
  • 1
    That is not possible from november 1 this year. There is a change coming to all public CA. Might as well adapt to that right away: digicert.com/internal-names.htm May 26, 2015 at 7:10
  • 1
    The way to adapt to it is to stop using bogon TLDs. Jan 9, 2016 at 9:19
1

I'm battling this exact issue. I dont have enough points to just comment.

But I'm curious, do you have the EXCH outlook provider CertPrincipalName set?

Get-OutlookProvider

It is typical with wildcard certs to need to set the EXPR provider. But I'm finding I may also need to set the EXCH provider for RPC clients.

Set-OutlookProvider EXCH -CertPrincipalName msstd:*.domain.com
5
  • I do not have it set ATM May 26, 2015 at 7:33
  • I haven't come across that. However, I will check the instructions from DigiCert on this site and post the result here. May 27, 2015 at 7:08
  • I've got a case open with MS for my issue. It sounds very similar to your. I'll let you know the result. But so far, MS has confirmed that the virtual directories are correct and don't know why clients are popping this warning....
    – Stephen F
    May 28, 2015 at 15:21
  • Thank you. Meanwhile, I'm looking into getting DNS to resolve the external name from the internal IP address. May 30, 2015 at 18:56
  • See UPDATE 150709 in OP. How is your case with MS going ? Jul 9, 2015 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .