1

Recently replaced the SSL cert on our Exchange 2010 box with a new wildcard cert. Assigned services, reconfigured all URL's for external and internal access to be identical (previous cert was a SAN cert with .local domain names and since they are no longer available we are having to change this), setup split DNS so internal and external clients all use the same DNS name for access.

Everything works as expected, with the exception of Outlook clients receiving a mismatch certificate error... it appears the server is presenting the server.domain.local FQDN to the client and with the SSL being *.domain.com it doesn't match...

I have followed all guides/articles I found ensuring that all URL's are setup properly and all point to the same external DNS name. Autodiscover internally also works and passes (we do not have it setup to autodiscover externally but Outlook anywhere does function as it should when manually configured, this has been tested)

What has me perplexed with this issue is that newly created profiles/accounts do not have this issue so it seems to be more of an Outlook profile issue rather than a server issue. I can open Outlook and use my previously configured profile and I get the SSL mismatch error.. If I create a new Outlook profile and setup my account within it, there are no SSL errors at all.

Not certain if anyone has come across this before or not but any advice/help would be greatly appreciated... while rebuilding the Outlook profile does fix the issue, with 25 - 30 users that isn't exactly something I want to have to do.... It isn't something that should have to be done.... Thanks in advance for any response/assistance.

Clay

Edit -

My issue isn't quite like the referenced Outlook Security Alert question... but more so Like this one - Outlook/Exchange certificate errors after setting clientaccessserver, etc… properties... this one seems to be almost identical to my problem... sadly it has no answer though

Community
  • 1
Clay Powell
  • 21
  • 1
  • 1
  • 5
  • So to clarify you no longer have any ".local." domain? – Cameron Kerr May 07 '15 at 14:10
  • We do still have our local domain as a .local, I have just reconfigured all Exchange URL's to use our public .com and set up the split DNS internally so internal clients resolve the LAN IP of the public DNS name. EDIT - Also to to note, this is the same type of setup I have used for all of my clients in moving away from SAN certs with .local domain names, the only difference in this case is the use of a wildcard cert. with other clients the Cert has just been server.domain.com, in this instance it is *.domain.com. beyond that, the setup is the same and I've not run into this problem before. – Clay Powell May 07 '15 at 14:12
  • possible duplicate of [Outlook security alert - The name on the security certificate is invalid or does not match the name of the site](http://serverfault.com/questions/627870/outlook-security-alert-the-name-on-the-security-certificate-is-invalid-or-does) – David V May 07 '15 at 14:18
  • This isn't an issue with external users, only internal users and only when using an Outlook profile that was configured prior to the SSL Cert change.. newly created profiles do not give the mismatch error. We are intentionally not using autodiscover externally requiring users to actually know the information to make use of outlook anywhere or activesync. Externally, everything works, no errors whatsoever. – Clay Powell May 07 '15 at 14:24
  • So will internal and external clients be connecting to the same endpoint? If so, there is where your mismatch will be. You would need to have two interfaces (does Exchange call these 'listeners', I can't remember), one with the local cert, and one with the public. Because it is a public cert, you can't have a SAN cert with the .local name as well. – Cameron Kerr May 07 '15 at 14:34
  • Internal and External clients will all connect to the same server, using the same DNS name. I am well aware that there are no longer SAN certs with .local domain names available, hence the reason for this cert change. All URL's on the Exchange server are configured to use the public .com domain, NOT the internal .local. See my edit for a link to another topic/question which is nearly identical to my problem – Clay Powell May 07 '15 at 14:37
  • Could you please provide the results of "get-outlookprovider" ? – Vick Vega May 07 '15 at 15:00
  • All 3, Exch, Expr, and Web, have server and certprincipal name blank with 1 for TTL – Clay Powell May 07 '15 at 16:42
  • Run the following please: and As well, please provide results for: Get-ClientAccessServer | FT – Vick Vega May 07 '15 at 17:21
  • Get-ClientAccessServer | FT only results in the local server name, no domain suffix, .local or .com, just the server name. May I ask why the setting of the outlook provider? This isn't anything that I have to to do before and in comparison to other servers setup in similar fashion that work without issue the entries in their list match mine as well as the fact that newly configured Outlook profiles work just fine with no SSL error.... – Clay Powell May 07 '15 at 18:09
  • ok, that's your problem. I'll put the explanation on how to remediate the issue in the answer section as it would be easier from the formatting perspective, as well I strongly believe it will resolve your issue. – Vick Vega May 07 '15 at 19:02
  • Don't use triple point after the end of your every sentence. – peterh May 08 '15 at 04:50
  • I didn't come here seeking advice for grammar or sentence structure, but thank you... – Clay Powell May 08 '15 at 13:02

6 Answers6

2

Based on a comment you made above, I would like to provide you a clear picture as to what you need to validate in order to make the environment work properly. I'm going to cover all the aspects, so some things you probably already have working. 1. Make sure you have "RPC over HTTP" installed on the Exchange server and properly operating (corresponding event logs can be seen when server boots, for example.

Since you have replaced your SSL cert with wildcard one, you would need to decide how are you going to reference the Exchange server inside your internal network, for a sake of the example, let's make it mail.domain.com for the fqdn and mail for the netbios name.

Run the following CMD-lets to find and SET the correct information as for the virtual directories perspective:

Exchange Control Panel: Get-ecpVirtualDirectory -Server mail | Set-ecpVirtualDirectory -InternalURL https://mail.domain.com/ecp -ExternalURL https://mail.domain.com/ecp

Get-ECPVirtualDirectory -Server mail | Fl InternalURL,ExternalURL

Outlook Web App: Get-OwaVirtualDirectory -Server mail | Set-OwaVirtualDirectory -InternalURL https://mail.domain.com/owa -ExternalURL https://mail.domain.com/owa

Get-OWAVirtualDirectory -Server mail | Fl internalUrl,ExternalURL

EWS (Exchange Web Services): Get-WebservicesVirtualDirectory -Server mail | Set-WebservicesVirtualDirectory -InternalURL https://mail.domain.com/EWS/Exchange.asmx -ExternalURL https://mail.domain.com/EWS/Exchange.asmx

Get-WebservicesVirtualDirectory -Server mail |Fl internalURL,ExternalURL

Autodiscover: Set-ClientAccessServer mail -AutodiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml

Get-ClientAccessServer mail | Fl AutodiscoverServiceInternalUri

ActiveSync: Get-ActiveSyncVirtualDirectory -Server mail | Set-ActiveSyncVirtualDirectory -InternalURL https://mail.domain.com/Microsoft-Server-ActiveSync -ExternalURL https://mail.domain.com/Microsoft-Server-ActiveSync

Get-ActiveSyncVirtualDirectory -Server mail | Fl InternalURL,ExternalURL

Offline Address Book: Get-OABVirtualDirectory -Server mail | Set-OABVirtualDirectory -InternalUrl https://mail.domain.com/OAB -ExternalURL https://mail.domain.com/OAB

Get-OABVirtualDirectory -Server mail | Fl InternalURL,ExternalURL

OutlookAnywhere: Set-OutlookAnywhere -Identity mail\Rpc (Default Web Site)" -InternalHostname mail.domain.com -ExternalHostName mail.domain.com -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl:$True -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl:$True

Get-OutlookAnywhere -Identity mail\rpc (Default Web Site)" |fl InternalHostName,InternalClientAuthenticationMethod,InternalClientsRequiressl, ExternalHostName,ExternalClientAuthenticationMethod,ExternalClientsRequiressl

Perform iisreset /restart after the script above, remember to replace mail with the actual netbios name of the server and mail.domain.com with the actual fqdn of your Exchange server.

In regards to the Outlook provider see here: http://blogs.technet.com/b/exchange/archive/2008/09/29/3406352.aspx

Let me know if you have any questions.

Vick Vega
  • 2,398
  • 16
  • 22
  • I have already performed all of those steps. This isn't the first server I have configured with split DNS to use internal and external domain names being the same. The only difference between this one and previous ones is the wildcard cert, others have been single name certs. While not referencing them individually I did state in my original posting that I had configured all URLs for internal/external access I again mention that new Outlook profiles work fine without error, autodiscover is working as it should, and testing it results in all the proper URLs being presented. – Clay Powell May 07 '15 at 19:28
  • Please clarify at what exact point in time you get the cert error? Ideally, post screenshot. – Vick Vega Aug 04 '15 at 22:26
  • Pops up about 5 - 20 seconds after Outlook first opens and is good for the entire time Outlook stays open, but if you close/re-open it the box pops up again. [screenshot here](http://imgur.com/4AZgjGQ) – Clay Powell Aug 05 '15 at 13:37
  • Please provide output from: Get-ClientAccessArray | fl – Vick Vega Aug 05 '15 at 14:35
  • There is no output from that command, it is blank. This is a single server setup and is not utilizing the CAS Array. – Clay Powell Aug 05 '15 at 18:40
  • While having Outlook open, hold CTRL and right click on the Outlook icon in the task bar, choose **Test E-mail AutoConfiguration**, post results. – Vick Vega Aug 05 '15 at 19:22
2

I have come across same issue while doing migration to Exchange 2013 requiring to replace SSL cert on Exchange 2010 and configure OA to enable proxying through Exchange 2013. Solution to avoid cert pop ups on desktops was to import Outlook 2013 GPO template and enable GPO for Autodiscover to ExcludeLastKnownGoodUrl.

Outlook 2013's new feature to store last known good urls and order of processing connectivity when launched is the culprit :)

HBruijn
  • 72,524
  • 21
  • 127
  • 192
Azhar Pasha Syed
  • 36
  • 1
  • I will give this a shot and see if this helps, but I will mention that we use a mix of Outlook 2010 and 2013 clients.... and while not everyone has had this SSL pop up, it has been a mixture of the two clients that have received and has not strictly been limited to the 2013 clients. – Clay Powell Sep 10 '15 at 13:04
  • Well, kudos to you, this seems to have done the trick, thank you so much. – Clay Powell Sep 17 '15 at 13:20
1

We had the same issue after removing our local domain from our Exchange certs and went down the same troubleshooting path, Clay.

We found that the 'last known good' cache in Outlook 2013 was the culprit by turning this feature off via the registry for a couple affected PCs.

Then we realized the root cause was because we had left the old "local" record in dns. Outlook 2013 was looking to cache for the old autodiscover, and because it still existed despite not matching the cert, it was never going out to get the new address.

I know this is old but thought it may help someone else.

Leah
  • 11
  • 2
0

I know this is old but still relevant in 2020 with office 2016 and 2019, Exchange 2016 and 2019

After spending days on this issue, (re)setting internal and external URLs of exchange, SSL certificate rebuilds and complete workstation rebuilds I came across this post. Azhar Pasha Syed answered the question above (https://serverfault.com/a/721380/235674) witch pointed me in the right direction so I felt the need to comment and help others

My issue in the end was that the autodiscover server is cached in the users Outlook profile.

Here is a Microsoft link to the issue https://support.microsoft.com/en-gb/help/3073002/after-migration-to-office-365-outlook-doesn-t-connect-or-web-services

Fix with reg key on the local machine(s) for Outlook 2016, 2019 and 365

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
DWORD: ExcludeLastKnownGoodUrl
Value: 1

Or download and configure the Office Group Policy template for office 2016, 2019 and 365 from your server https://www.microsoft.com/en-us/download/details.aspx?id=49030

Dave M
  • 4,494
  • 21
  • 30
  • 30
Sparki
  • 143
  • 6
0

I just had the exact same issue as you are describing, down to the T.

Resolution was to disable Cached mode on the affected profiles. Open Outlook, close outlook. Re-enable cached mode and the issue went away.

I hope this saves others time :)

Jeff W.
  • 1
  • Tried that as well and did not work... On my profile (Outlook profile) I do not have cached mode even enabled at all and still get the same prompt. – Clay Powell Jun 26 '15 at 18:25
0

So I had the exact same issue after installing an SSL certificate into our local Exchange server for mail.company.com.

All Outlook clients on LAN started receiving "The name on the security certificate is invalid or does not match the name of the site", followed by a "Allow this website to configure user@company.com server settings? https://autodiscover.company.com/autodiscover/autodiscover.xml" prompt.

I ran through the DigiCert Exchange utility, generated a script, checked it, retrieved and backed up all existing configuration by using "Get-" and then executed the script in the Exchange Management Shell:

Set-ClientAccessServer -Identity "LocalServer" -AutodiscoverServiceInternalUri "https://mail.company.com/Autodiscover/Autodiscover.xml"

Set-OABVirtualDirectory -Identity "LocalServer\OAB (Default Web Site)" -InternalUrl "http://mail.company.com/OAB"

Set-WebServicesVirtualDirectory -Identity "LocalServer\EWS (Default Web Site)" -InternalUrl "https://mail.company.com/EWS/Exchange.asmx"

Set-ActiveSyncVirtualDirectory -Identity "LocalServer\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://mail.company.com/Microsoft-Server-ActiveSync"

Set-OWAVirtualDirectory -Identity "LocalServer\owa (Default Web Site)" -InternalUrl "https://mail.company.com/owa"

Set-ECPVirtualDirectory -Identity "LocalServer\ecp (Default Web Site)" -InternalUrl "https://mail.company.com/ecp"

This didn't solve the warning prompts on the clients after a ipconfig /flushdns, gpupdate /force, and a restart, so I then double checked some other items:

mail.company.com was registered in the SSL certificate - okay.

Local DNS server Alias entry mail.company.com to LocalServer.company.com - okay

Found a duplicate local DNS server Host LocalServer.company.com to 192.168.1.11 and to 192.168.1.60 - Deleted incorrect 2nd entry.

Found local DNS server Alias autodiscover.company.com to LocalServer.company.com - Deleted this entry, ipconfig /flushdns and close and open Outlook on clients and everything seemed to work!

What the Microsoft KB article https://support.microsoft.com/en-gb/kb/940726, and the DigiCert Exchange tool eluded to, is another setting which I have discovered subsequently which most likely would have addressed the AutoDiscover prompt correctly:

Set-AutodiscoverVirtualDirectory -Identity "LocalServer\Autodiscover (Default Web Site)" -InternalUrl "https://mail.company.com/autodiscover/autodiscover.xml"

Set-AutodiscoverVirtualDirectory -Identity "LocalServer\Autodiscover (Default Web Site)" -ExternalUrl "https://mail.company.com/autodiscover/autodiscover.xml"

Both of these entries are blank on my Exchange server, so will test populating them and feed back again.

EDIT: So I put in the InternalUrl for mail.company.com/autodiscover/autodiscover.xml, and when I checked the Outlook clients by CTRL+Right-click on Outlook tray icon, Test E-mail AutoConfiguration..., Test, Log, scroll down and find the line Autodiscover to, it has the new address in there and has a success status!

I have seen another article where they have added autodiscover.company.com into the SSL certificate as a solution, which would also solve the problem in this scenario, this however is a wasted resource in my circumstance as we have limited SSL certificates.

All working, now just to figure out connections from the outside, and routing through the firewall :)

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
Edward
  • 11
  • 3
  • My issue is slightly different in that it is only some of the clients... and even on clients that have the certificate error ( I am not getting the second allow this website to configure error you mention) all autodiscover tests pass when right clicking the the Outlook tray icon. DNS isn't an issue as we use a .local internal domain and a .com external but internal and external clients both use the public .com name via split DNS. Also to note our cert is a wildcard cert so it accepts everything at our .com domain. Our only resolution so far has been to create new Outlook profiles. – Clay Powell Jul 28 '15 at 18:23