• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 439
  • Last Modified:

Exchange 2013 SSL Errors

I have installed a new certificate for remote.contoso.on.ca which is the URL for owa. I am trying to avoid using internal names on the SSL certificate and have created the appropriate DNS settings. It seems as though everything is setup correctly. There is conflicting services with the certificates. I do not want to have any services associated with the self signed certs. They keep getting a certificate error internally that keeps prompting with an internal server name. The virtual directories etc are all setup with the remote.contoso.on.ca which should allow them to connect. Is there a way to take the services off the SSL certificates. I have also checked the SSL bindings and it seems to be good but they still get issues.
0
JMRSoftware
Asked:
JMRSoftware
  • 5
  • 5
  • 3
3 Solutions
 
Simon Butler (Sembee)ConsultantCommented:
You can't avoid the use of self signed SSL certificates, because of the way Exchange 2013 moves the internal data.
Therefore if you have changed the bindings in IIS manager then you may have broken some functionality. As long as you have set the bindings correctly in ECP and have adjusted the URLs within Exchange to match, then you should be fine.
Don't try to eliminate the self signed certificates, because you can't.

Simon.
0
 
JMRSoftwareAuthor Commented:
Thanks for your response,

Alright, I have installed the certificate and everything is working correctly externally. I can even browse internally to the correct URL and it is using SSL. For some reason even though I made sure all of the VirtualSettings were setup correctly to use the same as external it still does not work. I have setup split DNS as well and it works correctly but still gives me a certificate error on the outlook client as if it is trying to connect via the internal name.
0
 
jrhelgesonCommented:
You'll want to run the following powershell commands - after replacing the "CAS-Server-Name" and of course your "remote.contoso.on.ca" url with the public URL.
Enable-OutlookAnywhere -Server "CAS-Server-Name" -ExternalHostname 'remote.contoso.on.ca' -DefaultAuthenticationMethod 'Basic' -SSLOffloading $false
Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -ExternalURL 'https://remote.contoso.on.ca/autodiscover' -InternalURL 'https://remote.contoso.on.ca/autodiscover' -BasicAuthentication $true
Set-OABVirtualDirectory -Identity "CAS-Server-Name\OAB (Default Web Site)" -ExternalUrl "https://remote.contoso.on.ca/OAB" -BasicAuthentication $true -RequireSSL $true 
Set-OABVirtualDirectory -Identity "CAS-Server-Name\OAB (Default Web Site)" -InternalUrl "https://remote.contoso.on.ca/OAB" -BasicAuthentication $true -RequireSSL $true
Set-WebServicesVirtualDirectory -Identity "CAS-Server-Name\EWS (Default Web Site)" -BasicAuthentication $true -ExternalUrl https://remote.contoso.on.ca/EWS/exchange.asmx 
Set-WebServicesVirtualDirectory -Identity "CAS-Server-Name\EWS (Default Web Site)" -BasicAuthentication $true -InternalUrl https://remote.contoso.on.ca/EWS/exchange.asmx
Set-ClientAccessServer -Identity "CAS-Server-Name" -AutodiscoverServiceInternalUri https://remote.contoso.on.ca/autodiscover/autodiscover.xml

Open in new window

Now, if you still have internal autodiscover issues after that, then I'd need to know the actual error message.
0
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
Simon Butler (Sembee)ConsultantCommented:
This line is wrong:

Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -ExternalURL 'https://remote.contoso.on.ca/autodiscover' -InternalURL 'https://remote.contoso.on.ca/autodiscover' -BasicAuthentication $true

The Autodiscover virtual directory should not have a URL value set on it. It isn't used by Exchange and can actually cause problems. The default values (null) should be left.

Simon.
0
 
jrhelgesonCommented:
Simon: Why is that? Can you provide examples of what problems it causes? You have quite a presence here on EE, and I respect your opinion and input.

I've built these scripts on the many dozens of implementations I've done, and have also used them repeatedly to resolve autodiscover issues on dozens more.
0
 
Simon Butler (Sembee)ConsultantCommented:
Setting that value would have done nothing to resolve Autodiscover issues.
The one that resolves the Autodiscover problems is the set-clientaccessserver -AutodiscoverServiceInternalURI line because that is what the client use internally. Externally the clients use hard coded addresses, which you cannot change.

The reason that changing the Autodiscover virtual directory causes problems is usually because people change other things. The Autodiscover virtual directory should be left in its default state - if it has been changed then it should be reset. Trying to "correct" its configuration causes more problems which are usually resolved elsewhere, and even after resolving them elsewhere they continue to be a problem because of the modifications made to Autodiscover VD (cycle of problems).

Simon.
0
 
JMRSoftwareAuthor Commented:
Hello,

Thanks for all the responses. It seems after checking through power shell that what was setup for the virtual directories did not match what was being used by exchange. I set everything up as needed and now have an authentication issue. It seems as though it wants to set the clients to anonymous and is prompting for passwords from the users who are connecting internally. I have setup a name and included on the SSL cert the servername.contoso.on.ca (Internal Reference) and the remote.contoso.on.ca will be the external reference. saw an article saying to turn the authentication to NTLM because there was a previously known issue with this.
0
 
jrhelgesonCommented:
Do you have a certificate that has all the names you are trying to use in there?
If not, take my advice and use the external URL for both internal and external auth.
Run the commands I provided for you. If you still have issues after running them, let me know what the actual error message is, then we can help.

If you don't share what the actual error message is, we cannot help you.
0
 
JMRSoftwareAuthor Commented:
Thanks for the responses.

I have a cert with all the names I am currently using on it yes. They get no cert issues now. The issue was I setup servername.domain.on.ca for internal ref and remote.domain.on.ca for external access. I walked through all of the powershell commands to check the settings. Everything was correct. When the outlook client would connect it would get a prompt for a username/password (using servername.domain.on.ca) The proxy settings had negotiate for authentication. I then manually switched to remote.domain.on.ca and kept the rest of the settings and it never asked for a password.

I took the recommendation above to just use the external name with split dns as it had the best results testing. so I went through and changed all internal references to remote.domain.on.ca I have restarted IIS and rebooted the server. I have checked all the settings via powershell. For some reason the outlook clients are still getting the old servername.domain.on.ca and it is still asking for a PW. If I go and change it to remote again and restart outlook it connects. Is there a reason the autodiscover settings are not populating the correct settings ? I am going to go through again and check.
0
 
JMRSoftwareAuthor Commented:
It seems as though, it is always coming under "more settings" > "Security" as Anonymous Athentication with encryption un-checked..... I go down and put it to negotiate it works after restarting outlook. Still with servername.domain.on.ca. After a bit it disconnected restart outlook and it goes back to anonymous.

owa authentication through the servername/ecp is set to negotiate with the box check for SSL offloading.
0
 
Simon Butler (Sembee)ConsultantCommented:
Do an Autodiscover test.
http://semb.ee/adt

See what URLs are being returned by Autodiscover - you may have missed one.
The common one is this:

get-clientaccessserver | select identity, autodiscoverserviceinternaluri


Simon.
0
 
JMRSoftwareAuthor Commented:
Hello,

That was the last thing that needed to be done. It was set to autodiscover.domain.on.ca/auto...

Restarted IIS

Everything is working correctly. I am assuming that I could have also kept in the way I had before if that was changed to servername.domain.on.ca instead of remote.domain.on.ca

Thanks for your help.
0
 
Simon Butler (Sembee)ConsultantCommented:
You can put any host name that you like on there, as long as

a. It resolves internally to the Exchange server
b. It is on the SSL certificate

Simon.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

  • 5
  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now