The name on the security certificate is invalid or does not match the name on the site

Get -WebServicesVirtualDirectory |fl indentity, internalurl, externalurl
Is the External Url only used from internal access to external? For example Outlook using it on a client computer on the LAN. While external traffic only uses the 3rd party cert the DNS where AutoDiscovery is configured points to? Trying to understand how this works with the External Url blank.

My understanding is both directories should be set to https://remote.clientsdomain.com 

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

Run this and restart IIS?

The external address is the address that is resolved.  So with no external address assigned you will not be able to resolve to it.
Make sure that the address that is resolved matches what is in the Cert. Normally you want to purchase a trusted third party SAN cert to address multiple domain names.  Your server has an internal address that is pointed to exchange.domainname.local and your Cert does not have this address in the Cert.

If you click on the View Certificate you will see the chain and it probably is Exchange.domainame.com

If you change the internal URL address to Exchange.domainame.com and make sure you can resolve this address internally you will most likely be fine.  You may have to create a DNS zone for domainname.com and add a A-Record of a CNAME for this address.

What version of exchange is this? you can get a publicly signed SSL certificate for ales that ten dollars these days?
Outlook Error “The name of the security certificate is invalid or does not match the name of the site.”


Pete

If you click on the View Certificate you will see the chain and it probably is Exchange.domainame.com

it's failing exchange.clientdomain.local not .com (note - image in original post)

Normally you want to purchase a trusted third party SAN cert to address multiple domain names.  Your server has an internal address that is pointed to exchange.domainname.local and your Cert does not have this address in the Cert.

A UCC\SAN cert was purchased and installed which allows up to 5 names and only three are used. If I rekey the cert and add exchange.clientdomain.local and/or exchange.clientdomain.com will it disconnect mobile devices that are already connected and these users get a failed cert error? Is it the best resolution? If so there are not that many mobile users.

My understanding is exchange.clientdomain.local wasn't necessary for LAN devices to resolve since it's internal to the LAN.

I don't mind rekeying the cert if it's not going to disconnect or give a cert error to current mobile users. Will make the change if its the best option and needs to be done.

Is there a way to create a self-signed cert since this is .local and/or use DNS on the server? You mentioned create a CNAME and Host A record.

its very unlikely you can add your internal domain to the SSL cert as this practice was ceased several years ago. Very few CAs will allow you to do this and insist all domains on the SSL cert are backed up by public DNS records.

Just amend your internal addresses as advised and it works as designed.

Pete may just rekey the current cert, was hoping not to break current mobile devices. If they don't disconnect or give a cert error then will do this now. Since the failing cert name is exchange.clientdomain.local do I add this or exchange.clientdomain.com or both. This part is throwing me, the .local I wasn't aware needed to be added to the cert. I've installed certs on other servers and not added the .local and they worked.

Steve, setting up the internal DNS now. Is the 2010 article ok for a 2016 Exchange server? I'm assuming so because all the powershell commands work so far for the following.

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

I tested the get- commands for the internal DNS configuration and assuming set- will work if get- is pulling up information. There's been several warnings in powershell for years some of the commands are changing. Cert errors become a nightmare when they get halfway installed / configured and trying to avoid this. I'm probably too cautious when it comes to certs.

Didn't answer this prior, exchange 2016.

Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceInternalUri https://remote.clientdomain.com/autodiscover/autodiscover.xml is not working. The get- command remains empty. Any ideas?

No indication why the above commands are not working. Tested for the sake of it and the external cert from go daddy with invalid name or name does not match error looking for exchange.clientdomain.local.

Just amend your internal addresses as advised and it works as designed.

Steve any ideas?

.local is no longer allowed  to be added to SAN certs.
Your best course of action is to change both the internal and external address to be exchange.domain.com and use your public cert that you have for the server.

I did this already.

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl https://remote.clientdomain.com/EWS/Exchange.asmx -BasicAuthentication:$true

The DNS settings I configured above are now routing logons to exchange outside and Outlook won't launch new profiles. Assuming this is due to the DNS changes made and the Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceInternalUri https://remote.clientdomain.com/autodiscover/autodiscover.xml not working.

Good news current Outlook users just get the annoying cert error. Bad news no new profiles can be added to Outlook. I'm assuming deleting the remote.clientdomain.com forward lookup zone will resolve this.

Am I correct thinking if Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceInternalUri https://remote.clientdomain.com/autodiscover/autodiscover.xml changes then this should all be resolved? Or should I not focus on this step failing and back out of the DNS configuration route.

You may have to create a DNS zone for domainname.com and add a A-Record of a CNAME for this address.

yo_bee do you mind clarifying. I configured the zone but haven't made any records, only the default records were created.

First thing is that your Active Directory domain relies heavily on DNS and when you create your first Domain Controller it will also create your DNS zone for domain.local if that is what you call the domain.  When you join computers to your domain they will register with the DNS server under the domain.local.  Now you want to have some control of what IP's are registered with other domains (i.e. exchange.domain.com) so you need to create a new zone that has domain.com.  Once this is created you can added a new A-Record for exchange.domain.com and put the internal IP-Address of that server in to the record.  Once this is done you should ping it from command prompt and see if it resolves that correct internal IP.  You should already have a public DNS record for this same A-Record that points to your public IP issued by your ISP.

Going back up a few responses, the reason your set-clientaccessserver seemed not to work is you checked it with a completely wrong attribute. There is no such attribute as autodiscoveryserviceurl. It is autodiscoverserviceinternaluri. The correct command to see what is set for your SCP is get-clientaccessserver <servername> | select autodiscoverserviceinternaluri. You will need to run this command for each of your servers running CAS. It should be the same result for all servers running CAS
  the scp listed is what outlook used internally. You need to be sure your internal clients can resolve the address returned to either your exchange server or the Exchange VIP on your load balancer.
  Lastly, you need to make sure this FQDN is listed on your certificate as a SAN name. If you are using a Wildcard cert, it may work. I had no luck with them in the past and use UC certs for exchange exclusively.

Outlook anywhere or Outlook client show Security Alert or certificate error , you need to read this article before:

http://www.shudnow.net/2013/07/26/outlook-certificate-error-and-autodiscover-domain-com-not-working/?fbclid=IwAR2sKW9nZSABZvbHdpyy2emDVdtJPGKmz2yoPqFWvOjMPcQJ9UBAWshcIU0



Use the Set-ClientAccessService cmdlet to modify settings that are associated with the Client Access server role.

https://docs.microsoft.com/en-us/powershell/module/exchange/client-access-servers/set-clientaccessservice?view=exchange-ps

Sorry for not responding, caught up on other stuff.

Is the 2010 article ok for a 2016 Exchange server?

yes but bets to use the right one now we know which Exch version you're on:
http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2016/

Basically, you should set the internal & external URls to use the external domain so they work with your SSL cert.
E.G
Old:
   External: mail.company.com/<various Exchange URLs>
   Internal: server.internalDomain.local/<various Exchange URLs>
Becomes
   External: mail.company.com/<various Exchange URLs>
   internal: mail.company.com/<various Exchange URLs>

to prevent unnecessary traffic going out over your routers, you should also create an internal DNS entry (or zone, depending on your setup) to direct mail.company.com to your Exchanges internal IP.

I did everything the thread requested and for whatever reason continued to have issues. I was pressed for time so I opened a live session here and the problem was resolved. I would like to mention the tech that helped me during the live session but can't find this setting in EE, would someone please point it to me.

Thank you.

do you still need help?

No the problem was resolved after I paid an EE for live support and for the life of me I can't remember who it was. I also can't find the transaction in EE and why I'm asking how to go about finding this information.

Do you know what it was?

Thank you for everyone that helped on this. Was a combination of reading older information and somehow combined with missing information on the Exchange server. Maybe going to fast and simply overlooking details. We found an internal URL incorrectly configured and had to make an additional DNS entry. As mentioned I also had an EE tech take a look and this is the work that was performed. Sorry for the delay it's been a busy month. Thanks again for all the help.