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...
Oskar Emil
  • 177
  • 2
  • 11
  • 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. – David Schwartz May 22 '15 at 07: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 – Oskar Emil May 22 '15 at 11:00
  • Checked the SSL certificate. Everything is OK. – Oskar Emil May 22 '15 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 '15 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. – Oskar Emil May 22 '15 at 14:19
  • If the clients have `mx.example.local` in their server connection settings, you have to replace the hostname their. AFAIK the clients don't update their settings regularly with Auto Discover. – sebix May 22 '15 at 17:39
  • If Auto Discover is correct then the account should not reference the internal address when it is recreated. – Oskar Emil May 22 '15 at 18:37
  • Does your Cert only have the CN with the wildcard? I've had issues with some clients where I had to have the domain in the CN also in the SAN (duplicated) along with any actual other names. – Tyler Szabo May 22 '15 at 22:48
  • Yes. The certificate is issued to *.example.no. The internal name should not be exposed through SAN, it is bad practice and all commercial issuers have stopped doing that. – Oskar Emil May 23 '15 at 18:30

2 Answers2

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
Falcon Momot
  • 25,244
  • 15
  • 63
  • 92
Stephen F
  • 293
  • 1
  • 8
  • I do not have it set ATM – Oskar Emil May 26 '15 at 07:33
  • I haven't come across that. However, I will check the [instructions from DigiCert on this site](https://www.digicert.com/internal-domain-name-tool.htm) and post the result here. – Oskar Emil May 27 '15 at 07: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 '15 at 15:21
  • Thank you. Meanwhile, I'm looking into getting DNS to resolve the external name from the internal IP address. – Oskar Emil May 30 '15 at 18:56
  • See UPDATE 150709 in OP. How is your case with MS going ? – Oskar Emil Jul 09 '15 at 08:56
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.

Konstantinos Xanthopoulos
  • 165
  • 4
  • 15
  • 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: https://www.digicert.com/internal-names.htm – Oskar Emil May 26 '15 at 07:10
  • 1
    The way to adapt to it is to stop using bogon TLDs. – Falcon Momot Jan 09 '16 at 09:19