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.
ASKER
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
Setting that value would have done nothing to resolve Autodiscover issues.
The one that resolves the Autodiscover problems is the set-clientaccessserver -AutodiscoverServiceIntern
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.
The one that resolves the Autodiscover problems is the set-clientaccessserver -AutodiscoverServiceIntern
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.
ASKER
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.
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.
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.
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.
ASKER
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.
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.
ASKER
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.
owa authentication through the servername/ecp is set to negotiate with the box check for SSL offloading.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hello,
That was the last thing that needed to be done. It was set to autodiscover.domain.on.ca/
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.
That was the last thing that needed to be done. It was set to autodiscover.domain.on.ca/
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.
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.
a. It resolves internally to the Exchange server
b. It is on the SSL certificate
Simon.
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.