locked
The name on the security certificate is invalid ... local Outlook client error after removing invalid fqdn certificate - Exchange 2010 RRS feed

  • Question

  • Previously we had an external certificate with a .local SAN in it.  As those are no longer valid, we purchased a new certificate without only the public, external SAN names in it.  I have reconfigured Exchange 2010 as stated in several articles online, such as https://support.microsoft.com/en-us/kb/940726.  I have created the public domain space in my local DNS and created mail and autodiscover records pointing to my local Exchange server IP.  I have checked several times and although things are working fine externally, internally I continue to get the Outlook certificate error.

    When I run a Test E-mail Autoconfiguration, the URLs all look fine, but I do note the Server: entry is still listed as the local server -- I'm not clear if that is correct. Regardless, I believe something in autodiscover is not working correctly and client is getting annoyed.

    Monday, November 2, 2015 7:24 AM

Answers

  • You need to look in ADSIEDIT in the location that I have specified.

    If that shows the correct information, then the behaviour you are seeing is not something I have ever seen before and you need to either engage a consultant to take a look or call Microsoft support. Everything that you have done is correct, so either there are huge problems with the domain, or something is getting in the way.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Wednesday, November 4, 2015 5:41 PM

All replies

  • The server name in the Autodiscover response is fine.
    You need to check you have covered all of the URLs.

    http://semb.ee/hostnames2010

    Make sure that after changing the host names you run iisreset and then go through the log in the test tool. Verify the DNS resolves correctly and the correct results are coming back - specifically that Autodiscover is being found via the SCP record and not via DNS.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Monday, November 2, 2015 11:15 AM
  • Hello Simon. Thank you for your response. I went step by step through your link and everything looks good. I did the IIS Reset.  When I run the test tool the log shows that it is finding autodiscover through SCP.  In the log, however, I do see that all the URLs show https://server.localdomain.local/autodiscover/autodiscover.xml   On the Results tab the addresses show externally, but in the log they show internally. Is that correct?


    Monday, November 2, 2015 12:10 PM
  • You haven't changed all of the entries.
    The fact that it is still using a .local URL is the cause of the certificate prompt.

    You have missed the URL on set-clientaccessserver

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Monday, November 2, 2015 12:34 PM
  • I agree that is exactly what it looks like to me as well.  I assure you I have tried the set-clientaccessserver command several times without error.  I have found articles stating success with slightly different URLs so I tried the one in your example and also the one shown below it.  After each I Recycled the MSExchangeAutodiscoverAppPool and did an IISReset.  My results don't change however. I can' figure what I'm missing.  It still is seeing the local servername.

    Which one is correct and do you see an error in my syntax?

    Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mail.mydomain.com/autodiscover/autodiscover.xml

    Set-ClientAccessServer localservername -AutoDiscoverServiceInternalUri https://autodiscover.mydomain.com/Autodiscover/Autodiscover.xml

    Monday, November 2, 2015 1:33 PM
  • Both of those examples are correct, as long as the host name resolves correctly internally.

    Do you have more than one server?

    Could be a sign of poor replication, if you have multiple domain controllers. The entry is published to the domain, therefore if the domain controllers are not replicating correctly then that could mean that the incorrect information is still returned to the client.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Monday, November 2, 2015 4:50 PM
  • A great thought.  It's a small network with only one Exchange Server, but yes there two ADCs.  I can't see any issues.  The repadmin /showrepl is error free on both servers.  The MS AD Replication Status Tool shows no errors. DNS looks good to me... perhaps I've set something wrong in the public zone?  I just don't see what is forcing Outlook to look at the local servername...
    Monday, November 2, 2015 7:56 PM
  • Outlook doesn't look at the internal name. It queries the domain for the value to look at, therefore the name is in the domain.

    Check on both domain controllers for the value of serviceBindingInformation in the following location:

    CN=SERVERNAME,CN=Autodiscover,CN=Protocols,CN=SERVERNAME,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ORGNAME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=co,DC=uk

    replacing the relevant parts (DC, CN etc) as you step through adsiedit.

    Remember usual caveats about adsiedit, there is no undo.

    Another option would be to try changing the name to something completely bogus, then check in the above location to see if the change is being written or not.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Monday, November 2, 2015 8:03 PM
  • Hello Simon. 

    Thank you again for your continued advice.  Unfortunately I had difficulty finding the relevant area in ADSIEdit as I'm in it so rarely.  I instead used Active Directory Sites and Services and believe i was able to find the same information. When I drill down on both ADCs to the Autodiscover\Servername properties I can see that the serviceBindingInformation is set to what I entered in my last powershell command.  I can verify that it does update on both ADCs when I run the Set-ClientAccessServer command (I think that is what you were wanting to verify). Stubbornly, Outlook is still finding the local servername attribute...

    Monday, November 2, 2015 9:21 PM
  • That is very bizarre.

    Check to see if there has been a manual override in the registry that is being applied to the clients.

    http://blogs.technet.com/b/kristinw/archive/2013/04/19/controlling-outlook-autodiscover-behavior.aspx

    If possible, I would test with a clean client (needs to be domain joined).

    AD Sites and Services should be the same information. There is more about the SCP here:

    http://blogs.msdn.com/b/douggowans/archive/2007/06/28/serviceconnectionpoints.aspx

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    • Proposed as answer by Allen_WangJFModerator Tuesday, November 3, 2015 2:14 AM
    • Unproposed as answer by MrSeanK Tuesday, November 3, 2015 2:31 PM
    Monday, November 2, 2015 10:59 PM
  • I was pretty sure there was no registry modification going on, but I did check. Nothing there.  I don't have a new workstation, but I have verified on two domain workstations and a remote desktop server and also by creating a new Outlook profile.  I found a good article here which repeats what I've already done, but I notice in his screenshot that when he runs the Test E-mail Autoconfiguration tool, his results tab shows a public Exchange server whereas mine shows the local server name. 

    http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/exchange-autodiscover.html

    Can you confirm that the results tab should be showing my public facing name?  Regardless, I thought the serviceConnectionPoint record should be pointing this correctly as I've already corrected that.  For good measure I restarted both DCs and the Exchange Server just to make sure something wasn't sticking... no change.

    Tuesday, November 3, 2015 2:31 PM
  • Everywhere in the results tab should be the name as matching your SSL certificate, EXCEPT for the server name itself, which will be the server's real name, or the CAS array name (if set).

    The important bit for dealing with this problem is SCP address, which is triggering your prompt.

    I have never seen Outlook return the wrong name when the correct name is set within Exchange and verified through the domain as well. The lookup should be live.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Tuesday, November 3, 2015 3:59 PM
  • Hi,

    As above mentioned, Outlook client will use SCP to query Autodiscover information from AD firstly.

    For your question and result of Test E-mail AutoConfiguration, Outlook use https://server.localdomain.local/autodiscover/autodiscover.xml to connect to AD and succeed. It indicate that the value of AutodiscoverServiceInternalURI remain point to .local rather than new public domain space.

    Please run below command to check: Get-ClientAccessServer | FL Identity,*URI*, if it not correct, run Set-ClientAccessServer to modify.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Allen Wang
    TechNet Community Support

    Wednesday, November 4, 2015 2:19 AM
    Moderator
  • Hello.  When I browse to https://server.localdomain.local/autodiscover/autodiscover.xml from a domain PC it warns me that there is a problem with the security certificate.  It also prompts me for domain credentials and after I enter them it gives me the autodiscover.xml.

    When I run the Get-ClientAccessServer | FL Identity,*URI* it returns:  https://mail.publicdomain.com/autodiscover/autodiscover.xml  which I believe to be the correct result.  The Identity is my local server name.  As mentioned in the thread above, I have run the Set-ClientAccessServer command several times and it changes the SCP, yet my clients continue to look internally.

    Wednesday, November 4, 2015 1:15 PM
  • You need to look in ADSIEDIT in the location that I have specified.

    If that shows the correct information, then the behaviour you are seeing is not something I have ever seen before and you need to either engage a consultant to take a look or call Microsoft support. Everything that you have done is correct, so either there are huge problems with the domain, or something is getting in the way.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Wednesday, November 4, 2015 5:41 PM